SSH key exchange fails 30-70% of the time on Netgear X4S R7800
Hi, I have a strange issue on my Netgear X4S R7800. Running either DD-WRT or OpenWrt, approximately 30-70% of my SSH login attempts fail. For OpenSSH clients the error reported is "error in libcrypto". For the PuTTY client the error is more descriptive - "Signature from server's host key is invalid". The failure occurs even when using the OpenSSH client built in to OpenWrt itself (ie, SSH'ing into the router from the router via an existing remote SSH session). The failure appears to be at the tail end of the key exchange, before authentication. I've tried varying the cipher (aes128-ctr / aes256-ctr), the MAC (hmac-sha1 / hmac-sha2-256), and the key exchange algo (curve25519-sha256 / curve25519-sha...@libssh.org / diffie-hellman-group14-sha256 / diffie-hellman-group14-sha1) but the intermittent failure still occurs. The frequency of failure is about the same for all these configuration options except for diffie-hellman-group14-sha256, which fails much more frequently - it sometimes takes hundreds of attempts to succeed. Perhaps that will provide a clue to the underlying cause. Once an SSH login succeeds the connection is stable. However if I initiate a manual rekey operation via ~R then the key re-exchange fails. The router is otherwise very stable with no noticeable issues. I'm an embedded firmware engineer but have never worked on DD-WRT/OpenWrt firmware or dropbear. I have a conceptual understanding of the key exchange algo but haven't looked at the actual code of any implementation including Dropbear's. I'm seek ideas on how to troubleshoot this issue. Considering the problem is intermittent I'm thinking it's some variant in the key generation/exchange algorithm that's failing due to some issue with the router, or a more remote possibility, an issue with the Dropbear implementation. Here are pastebin links to the PuTTY full debug logs (w/raw data dumps) for both the failure and success cases: Failure Case: https://pastebin.com/MS2BtFmW Success Case: https://pastebin.com/c4j66Ga9 The only message I see from dropbear for a failed connection attempt is: authpriv.info dropbear[15948]: Child connection from 192.168.1.249:54819 authpriv.info dropbear[15948]: Exit before auth: Disconnect received Thanks!
Re: Hiding dropbear output on boot up
Hi Tania, I think you could probably add "> /dev/null 2> /dev/null" after one of the ipconfig commands in /usr/share/initramfs-tools/scripts/functions, though I'm not too familiar with how they all fit together. (Or if it's dhclient for ipv6 printing the output, get rid of the "-v" for dhclient). You could report a Debian bug for the initramfs package, they might have a better idea of a fix for it. https://packages.debian.org/stretch/dropbear-initramfs Cheers, Matt > On Wed 18/3/2020, at 8:09 pm, Tania Hagan wrote: > > Hi Dropbear, > > I have setup dropbear and busybox on a Ubuntu 18.04 desktop with LUKS > encryption. This works wonderfully except the IP-Config displays over the > unlock disk prompt causing confusion with users. Is there a way to either > hide this output or have it display before the LUKS unlock disk prompt? > > Thank you very much for any help. > Tania
Re: Timeout settings
Hello, Thank you very much for the answer. That clears it up. I reckon specifying '-K' on dbclient would then do the same as ServerAliveInterval. Cheers, Daniel On Wed, 18 Mar 2020 at 14:58, Matt Johnston wrote: > Hi Daniel, > > -K is equivalent to the OpenSSH ClientAliveInterval. The server will send > traffic to check that the connection is open. > > -I will disconnect if there is no traffic for a certain time interval. It > won't try to send any traffic over the connection, it just passively looks > at what traffic is being sent. > > Note that it seems that currently -K messages will cause the -I idle timer > to reset which isn't right, there's a pull request > https://github.com/mkj/dropbear/pull/90 which I will merge soon. > > Cheers, > Matt > > > > On Wed 18/3/2020, at 7:22 pm, Dániel Fancsali > wrote: > > > > Hello, > > > > First of all, let me just say this: awesome piece of software. Cheers! > > > > I am, however, a bit confused about the idle/keepalive settings. I have > been working with OpenSSH quite a bit, and do understand the concepts > around ServerAlive and ClientAlive as well as the TCPKeepAlive settings. > But I still struggle to wrap my head around -K and -I in dropbear. It's a > tad bit unclear which one maps to which one; or in other words, which one > happends on what layer. > > > > Maybe, my mistake here is trying to understand those in the context of > the OpenSSH settings, but on some level, it's the same protocol. > > > > So, looking at the code, I think this is what happens: > > - Setting -Kx will send an ssh packed every x seconds, and if there's no > answer 3 times in a row, it considers the connection to be dead. So this is > essentially ServerAlive/ClientAlive mechanism. > > - Specifying -Iy would say, if there's no incoming or outgoing data for > y seconds, it considers the connection dead. So this is sort of the others > side of the TCP keepalive coin. > > > > Is my understanding correct? If not, can someone please shed some light > on this for me? > > > > Regards, > > Daniel > >
Re: Timeout settings
Hi Daniel, -K is equivalent to the OpenSSH ClientAliveInterval. The server will send traffic to check that the connection is open. -I will disconnect if there is no traffic for a certain time interval. It won't try to send any traffic over the connection, it just passively looks at what traffic is being sent. Note that it seems that currently -K messages will cause the -I idle timer to reset which isn't right, there's a pull request https://github.com/mkj/dropbear/pull/90 which I will merge soon. Cheers, Matt > On Wed 18/3/2020, at 7:22 pm, Dániel Fancsali wrote: > > Hello, > > First of all, let me just say this: awesome piece of software. Cheers! > > I am, however, a bit confused about the idle/keepalive settings. I have been > working with OpenSSH quite a bit, and do understand the concepts around > ServerAlive and ClientAlive as well as the TCPKeepAlive settings. But I still > struggle to wrap my head around -K and -I in dropbear. It's a tad bit unclear > which one maps to which one; or in other words, which one happends on what > layer. > > Maybe, my mistake here is trying to understand those in the context of the > OpenSSH settings, but on some level, it's the same protocol. > > So, looking at the code, I think this is what happens: > - Setting -Kx will send an ssh packed every x seconds, and if there's no > answer 3 times in a row, it considers the connection to be dead. So this is > essentially ServerAlive/ClientAlive mechanism. > - Specifying -Iy would say, if there's no incoming or outgoing data for y > seconds, it considers the connection dead. So this is sort of the others side > of the TCP keepalive coin. > > Is my understanding correct? If not, can someone please shed some light on > this for me? > > Regards, > Daniel
Hiding dropbear output on boot up
Hi Dropbear, I have setup dropbear and busybox on a Ubuntu 18.04 desktop with LUKS encryption. This works wonderfully except the IP-Config displays over the unlock disk prompt causing confusion with users. Is there a way to either hide this output or have it display before the LUKS unlock disk prompt? Thank you very much for any help. Tania
Timeout settings
Hello, First of all, let me just say this: awesome piece of software. Cheers! I am, however, a bit confused about the idle/keepalive settings. I have been working with OpenSSH quite a bit, and do understand the concepts around ServerAlive and ClientAlive as well as the TCPKeepAlive settings. But I still struggle to wrap my head around -K and -I in dropbear. It's a tad bit unclear which one maps to which one; or in other words, which one happends on what layer. Maybe, my mistake here is trying to understand those in the context of the OpenSSH settings, but on some level, it's the same protocol. So, looking at the code, I think this is what happens: - Setting -Kx will send an ssh packed every x seconds, and if there's no answer 3 times in a row, it considers the connection to be dead. So this is essentially ServerAlive/ClientAlive mechanism. - Specifying -Iy would say, if there's no incoming or outgoing data for y seconds, it considers the connection dead. So this is sort of the others side of the TCP keepalive coin. Is my understanding correct? If not, can someone please shed some light on this for me? Regards, Daniel
