Core: asuswrt still not working ssh using user/pass login 0.86.3

[vinmar1]

Hassio 0.86.3 64 bit on RPi3B+

Using user/pass login it still breaks asuswrt

Have not tried Telnet or setting up Private Key.

in my config...

asuswrt:
  host: 192.168.1.1
  username: myusername
  password: mypassword
  protocol: ssh
  port: 22

traceback

Error during setup of component asuswrt
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/homeassistant/setup.py", line 145, in _async_setup_component
    hass, processed_config)
  File "/usr/local/lib/python3.6/site-packages/homeassistant/components/asuswrt.py", line 61, in async_setup
    await api.connection.async_connect()
  File "/usr/local/lib/python3.6/site-packages/aioasuswrt/connection.py", line 66, in async_connect
    self._client = await asyncssh.connect(self._host, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/asyncssh/misc.py", line 182, in __await__
    return (yield from self._coro)
  File "/usr/local/lib/python3.6/site-packages/asyncssh/connection.py", line 5454, in connect
    conn, _ = yield from create_connection(None, host, port, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/asyncssh/connection.py", line 5110, in create_connection
    yield from auth_waiter
  File "/usr/local/lib/python3.6/site-packages/asyncssh/connection.py", line 627, in data_received
    while self._inpbuf and self._recv_handler():
  File "/usr/local/lib/python3.6/site-packages/asyncssh/connection.py", line 847, in _recv_packet
    processed = handler.process_packet(pkttype, seq, packet)
  File "/usr/local/lib/python3.6/site-packages/asyncssh/packet.py", line 215, in process_packet
    self._packet_handlers[pkttype](self, pkttype, pktid, packet)
  File "/usr/local/lib/python3.6/site-packages/asyncssh/connection.py", line 1414, in _process_kexinit
    self._kex = get_kex(self, kex_alg)
  File "/usr/local/lib/python3.6/site-packages/asyncssh/kex.py", line 122, in get_kex
    return handler(alg, conn, hash_alg, *args)
  File "/usr/local/lib/python3.6/site-packages/asyncssh/kex_ecdh.py", line 47, in __init__
    self._priv = ecdh_class(*args)
  File "/usr/local/lib/python3.6/site-packages/asyncssh/crypto/curve25519.py", line 31, in __init__
    self._priv_key = x25519.X25519PrivateKey.generate()
  File "/usr/local/lib/python3.6/site-packages/cryptography/hazmat/primitives/asymmetric/x25519.py", line 39, in generate
    _Reasons.UNSUPPORTED_EXCHANGE_ALGORITHM
cryptography.exceptions.UnsupportedAlgorithm: X25519 is not supported by this version of OpenSSL.

[vinmar1]

UPDATE:

I tried to setup a key for ssh but honestly don't know if I did it right so I will let someone else comment on if that works or not.

Good news is Telnet login now works for me on Asus RT-AC68P router so we'll see how that does.

[vinmar1]

Closed accidentally - issue persists

[Jc2k]

Note for any user struggling with this from another user (not a dev). You shouldn't see this with manual installations on Debian Stretch, Ubuntu 18.04 or Raspbian. It also shouldn't happen with the Docker image homeassistant/home-assistant. When installed on those platforms the cryptography library either uses its built-in and up to date openssl or the host one is new enough.

Other distros with old openssl versions are not so lucky. I know from my stuff that anything that uses Alpine Linux is likely to be affected. Alpine also uses a different libc to most linuxes so it can't use the openssl that cryptography bundles either. I think this applies to HASS.io images too but I don't use them.

For anyone new to this issue and seeing this ticket first - the pull request with the workaround is here. That PR needs including in a tag.

Alternatively its possible to install cryptography with a modern openssl too - there is a ticket which i've commented on here to do that for HASS.io.

[Jc2k]

@kennedyshead has also given a clue on how to get the fix early here:

https://github.com/home-assistant/home-assistant/issues/20361#issuecomment-457939597

But be careful not to do that and forget about it - you will need to undo this when the proper fix is released.

[rohankapoorcom]

Closing as the fix is merged and should be released with the next hotfix.

[glentakahashi]

@kennedyshead @rohankapoorcom this is still broken in 0.86.4 docker, still getting the same X25519 error for asuswrt

[kennedyshead]

It's an error in alpine linux. And a temporary patch has already been added to HASS (but not released) in version 1.1.20 off aioasuswrt

[mcdull]

Why the moderator always wanted to close the issue again and again, and the bug fix, workaround, patch, never actually released.

[k8gg]

Just to make sure we are all on the same page, could anyone who believes his/her asuswrt works just fine posts his/her config (in .yaml) here? Just so anyone who comes here can rule out configuration error.

By config I mean for both:

asuswrt:

and

- device_tracker:
  platform: asuswrt

I just updated to 0.86.4 (hass.io in docker in ubuntu server), and what was working under 0.85.1 is broken now.

[Jc2k]

@k8gg I don't use this component so can't answer your question directly, but I do use the library that is triggering this error in my own python projects outside of HASS so you might find this helpful?

• I believe hass.io in Docker uses Alpine Linux for the home assistant container part, so I'd fully expect you to have this error. Because of the age of openssl in Alpine 3.8 and the fact that its too non-standard to use manylinux1 python packages. The only workaround open to you is to downgrade your version of asyncssh inside the container to an older version, theres no config option that will help. I think the next release will do that? [TBC]. Hopefully hass.io will upgrade to Alpine 3.9 soon which will also fix this error without downgrading.

• And to find someone with it working, you'd want someone either running the homeassistant/home-assistant container manually (perhaps like this, or running Ubuntu/Debian/Raspbian without Docker, i.e. the virtualenv way. Both of these installation methods should work as they let homeassistant use the manylinux1 python package and have newer openssl versions so both installation methods work.

You can reproduce the error with 2 lines of python code in a python shell if anyone wants to try it out:

$ python
>>> from cryptography.hazmat.primitives.asymmetric import x25519
>>> x25519.X25519PrivateKey.generate().public_key().public_bytes()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.6/site-packages/cryptography/hazmat/primitives/asymmetric/x25519.py", line 39, in generate
    _Reasons.UNSUPPORTED_EXCHANGE_ALGORITHM
cryptography.exceptions.UnsupportedAlgorithm: X25519 is not supported by this version of OpenSSL.

[pjv]

I've read through everything i could find related to this issue. As far as i can tell, nobody who tried using the work-around posted by @kennedyshead was successful and i haven't yet read anything that explains why SSH authentication works fine for the asuswrt component in 0.85.1 but breaks in 0.86.x. What changed where?

Also, why is SSH authentication throwing an error related to using an X25519 key when people (like me) are using an RSA key or even when they are not using public key crypto at all, but using user/pass authentication?

[Jc2k]

@pjv RSA key used for authenticating your identity, that is seperate to negotiating a cryptographically secure transport. Your client/server negotiate what they think are the most secure Kex, Mac and Cipher combination seperately to verifying your identity. It would still do X25519 even if you did password authentication. If you ssh -vvv you'lll see things like this (I also have an RSA key for verifying my identity):

debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none

At the expense of security you can remove 25519 as a valid KEX which might work around this problem.

I'll try to explain what has changed. Here there are 2 seperate projects - HASS.io and HA. I have no experience with HASS.io - I run the HA Docker install which has a working X25519.

• The 'change' at the heart of this -> aiossh was upgraded to 1.15.1 in the latest HASS.io image
  
  
  
  • If HA pins every dependency fully - this was a manual decision to upgrade
  
  
  • If HA only pins direct dependencies (i think this is the case) then it just so happened that 1.15.1 came out and was pulled into the next HASS.io docker image (without any human making a change)
  
  
• This release drops its pynacl dependency in favour of cryptography. I believe cryptography was an existing dependency, so on paper this meant aiossh was easier to install and easier to support - it now pulls in less crypto libraries than it used to, and the version it used was already new enough to support X25519, and the cryptography team have a very active security team watching out for security bugs.
• Home Assistant uses cryptography 2.3.1. This is new enough to support X25519. In fact, 2.0.0 from 2016 is also new enough to support X25519, too.
• Ubuntu, Debian, Raspbian and the HA docker container homeassistant/home-assistant use glibc as their libc implementation. That combined with their up to date python stack means that when installing cryptography it uses the manylinux1 wheel version of the package. This is the modern version of a python package and is pre-compiled. Any macOS users would also get a pre-compiled mac wheel.
• The Travis CI system the team use to run tests automatically on every commit also uses a version of Linux that supports manylinux1 wheels.
• The manylinux1 wheel standard is designed so even 10 year old Linux systems can still install modern python packages. cryptography will work as a wheel on 10 year old linux systems too, by shipping an internal copy of openssl to use instead of the out of date one on the host. This only works with glibc. This is why they suggest you prefer the wheel wherever you can.
• AIUI, you use hass.io. From helping other users i've found this is an Alpine Linux based system. I use it for my $dayjob. But rather than use glibc it uses musl. This means its incompatible with wheels and has to use the legacy python package format, something called an sdist. In this case the sdist has to be compiled from source code. This works without error (at build time) and most cryptography features still work, but a handful only work if the operating system has a new enough openssl version.
• Again, Ubuntu/Debian/Raspbian and the standalone HA docker container have an OpenSSL that is new enough for X25519 to work. OpenSSL 1.1.0 was released in Aug 2016 with X25519 support. But Alpine Linux 3.8 has the latest bug fix release of the 1.0.x series. This still gets security fixes, but not features changes, and stops getting updated this year. This is what hass.io uses.
• Alpine 3.9 was released a couple of days ago. This has a new enough version of OpenSSL for cryptography to be fully functional. This code will just start working when hass.io switches to Alpine 3.9. This is in progress, i believe, but might not happen immediately because it needs testing.
• One of the workarounds was to pull in pynacl dependency ourselves. This didn't work I think because the old pynacl code was completely removed (I haven't looked).
• I think the current workaround is to pin the aiossh version explicitly at an old version. This is the one that should be in the next release. It's a temporary bodge and until HA can switch to a proper version of OpenSSL we are blocked from receiving aiossh security updates. Again i'm speculating, this could do with fact checking. @kennedyshead?

So TL;DR. Upstream of upstream dependency does new release trying to make it easier to install/support. It gets included in next HASS.io release. Alpine is incompatible with wheels, so compiles against Alpine OpenSSL library. Alpine OpenSSL is too old to do X25519. Suddenly it breaks, even if no code had changed.

So the code is still there and still works, but the operating system side isn't compatible if you use HASS.io. Hopefully the newest workaround will work, and either way HASS.io know Alpine 3.9 is out and its on their todo. In the mean time the manual Docker and manual venv installations of HA will still work.

Hopefully this helps explain the current situation. I'm stuck waiting for Alpine 3.9 based HASS.io myself for a different component that also needs X25519.

[pjv]

wow - thanks for that uber-comprehensive explanation @Jc2k. I am using hass.io. I also use alpine-based docker images all over the place, so familiar with musl and its constraints.

so basically, dependency-hell - got it.

[kennedyshead]

What @Jc2k said <3 (Thanx mate!)

[kennedyshead]

There is however a freeze forr V1.15.0 in aioasuswrt atm. As soon as next Hass.io is released I will remove that

[kennedyshead]

DISCLAMER: DO NOT USE THIS IF YOU DONT KNOW WHAT YOU ARE DOING.

And if you want to you can add REQUIREMENTS = ['aioasuswrt==1.1.20', 'aiossh==1.15.0'] to the component (replace current REQUIREMENTS and it will work)