Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ASUSWRT platform doesn't accept ssh login with password anymore #2343

Closed
ardzeus opened this issue Jun 20, 2016 · 7 comments · Fixed by #2355
Closed

ASUSWRT platform doesn't accept ssh login with password anymore #2343

ardzeus opened this issue Jun 20, 2016 · 7 comments · Fixed by #2355

Comments

@ardzeus
Copy link
Contributor

ardzeus commented Jun 20, 2016

Home Assistant release (hass --version):
0.22.1

Python release (python3 --version):
3.5.1

Component/platform:
device_tracker/asuswrt

Description of problem:
ASUSWRT platform doesn't accept ssh login with password anymore. Same configuration worked with version 0.21 fine. Also SSH login from command line with same credentials works fine.

Expected:

Problem-relevant configuration.yaml entries and steps to reproduce:

device_tracker:
  platform: asuswrt
  host: 192.168.1.1
  protocol: ssh
  track_new_devices: no
  username: admin
  password: secretpassword

Traceback (if applicable):

16-06-20 20:08:01 ERROR (ThreadPool Worker 5) [homeassistant.components.device_tracker.asuswrt] Unexpected response from router: password refused

Additional info:

@fabaff
Copy link
Member

fabaff commented Jun 21, 2016

There was commit (1381984#diff-41bc1d46d2c173881ec4cbc34ed9f472) which introduced support for public key authentication. Could be related...@mtreinish perhaps you can help here.

@mtreinish
Copy link
Contributor

So I just gave it a try and I wasn't able to reproduce any issues with 0.22 using password auth, it worked fine for me. If you look at the patch which added public key auth support the actual login code path is the same, assuming you don't have a pub_key entry in the configuration.yaml so I'm not sure that's the problem.

That being said the specific error message in this case is coming from pexpect.pxssh directly: https://github.com/pexpect/pexpect/blob/master/pexpect/pxssh.py#L304-L310 when it gets the password prompt a second time on trying to login, pxssh assumes that's because of an incorrect password and raises an exception.

@ardzeus
Copy link
Contributor Author

ardzeus commented Jun 21, 2016

Actually there are three login attemps, not just one like pxssh should do. Could this be a dependency problem...

Log entries from the router:
Jun 21 20:08:24 dropbear[14210]: Child connection from 192.168.1.50:50628
Jun 21 20:08:24 dropbear[14210]: Bad password attempt for 'admin' from 192.168.1.50:50628
Jun 21 20:08:25 dropbear[14210]: Bad password attempt for 'admin' from 192.168.1.50:50628
Jun 21 20:08:25 dropbear[14210]: Bad password attempt for 'admin' from 192.168.1.50:50628
Jun 21 20:08:25 dropbear[14210]: Exit before auth (user 'admin', 3 fails): Exited normally

@linjef
Copy link
Contributor

linjef commented Jun 22, 2016

I am having the same problem, and do not believe it is a dependency problem.

For me, changing line 141 from

if self.pub_key:

to

if self.pub_key != 'None':

fixes the problem, but I do not have public key yet set up to test whether it breaks public key.

@mtreinish
Copy link
Contributor

Oh, yep I see the bug now. It's the str() cast on https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/device_tracker/asuswrt.py#L87 I forgot python is weird and casts None to "None". You can change the if too, the only case where that'd break is if someone passed in their public key file path as "None". I can push a patch for that to fix it, @linjef unless you want to handle it since you found the issue.

@linjef
Copy link
Contributor

linjef commented Jun 22, 2016

@mtreinish , please do push the patch for it; you're probably most set up for it right now :)

mtreinish added a commit to mtreinish/home-assistant that referenced this issue Jun 22, 2016
This commit fixes an issue with the use of None in default values
for the config get() calls in __init__() of AsusWrtDeviceScanner.
These values are cast as strings and when a NoneType is cast it
returns the string "None" this broke the check for the existence
of these fields. This commit fixes the issue by changing the default
value to be an empty string '' which will conform with the behavior
expected by the ssh login code.

Closes home-assistant#2343
balloob pushed a commit that referenced this issue Jun 23, 2016
This commit fixes an issue with the use of None in default values
for the config get() calls in __init__() of AsusWrtDeviceScanner.
These values are cast as strings and when a NoneType is cast it
returns the string "None" this broke the check for the existence
of these fields. This commit fixes the issue by changing the default
value to be an empty string '' which will conform with the behavior
expected by the ssh login code.

Closes #2343
@justyns
Copy link
Contributor

justyns commented Jun 29, 2016

I know I'm nitpicking, but shouldn't pub_key be named priv_key or preferably just ssh_key to avoid confusion?
Thanks for the patch though! I can confirm it fixed the original issue for me.

@home-assistant home-assistant locked and limited conversation to collaborators Mar 17, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants