Not able to ssh from 5.3p1 machine to 7.9p1. 5.3p1 supports hmac-md5 ciphering technique whereas in 7.9p1 it works with hmac-sha1 algorithm. LOGS: ===== debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-sha1 debug1: kex: server->client aes128-ctr hmac-sha1 none debug2: mac_setup: found hmac-sha1 debug1: kex: client->server aes128-ctr hmac-sha1 none no hostkey alg
This sounds more like unknown host key algorithm. Please, provide complete logs.
(In reply to Karthik Adiga from comment #0) > Not able to ssh from 5.3p1 machine to 7.9p1. 5.3p1 supports hmac-md5 > ciphering technique whereas in 7.9p1 it works with hmac-sha1 > algorithm. Both versions support hmac-sha1, so that's not the problem. I suspect Jakub is right, and I further suspect you are connecting to a system like old an FreeBSD which only supports ssh-dss, which is disabled by default in current versions. If that's the case you can try ssh -o HostKeyAlgorithms=+ssh-dss ...
Created attachment 3260 [details] Both working & Non working Logs for referenece
Thanks Jakub & Darren for your timely reply. We follow RSA technique. I have upgraded openssh in arm/linux machine from 5.3p1 to 7.9p1. Earlier from a linux client(5.3p1) to arm/linux server(5.3p1) was working fine. Now after upgrade it is giving the no hostkey algorithm error. With both machines on the same version 5.3p1 cipher technique used was hmac-md5, but with server in 7.9p1 it is choosing hmac-sha1. On what basis server chooses the cipher technique i.e hmac-md5 or hmac-sha1? I'm new to this openssh. Attached the logs in previous comment. Thanks in advance.
(In reply to Karthik Adiga from comment #4) > Thanks Jakub & Darren for your timely reply. > > We follow RSA technique. Not sure what you mean by this. > I have upgraded openssh in arm/linux machine from 5.3p1 to 7.9p1. From the working connection: > debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-rsa,ssh-dss client supports all of these host key algorithms > debug2: kex_parse_kexinit: ssh-dss Sever only supports ssh-dss. I think the client only has a ssh-dss (ie DSA) host key, but 7.9p1 doesn't support that by default any more. To re-enable it you would need to add ssh-dss to HostKeyAlgorithms *and* tell it to load the DSA host key (which is no longer in the default list) in addition to all the other key types by adding this to sshd_config: HostKeyAlgorithms +ssh-dss HostKey /usr/local/etc/ssh_host_rsa_key HostKey /usr/local/etc/ssh_host_ecdsa_key HostKey /usr/local/etc/ssh_host_ed25519_key HostKey /usr/local/etc/ssh_host_dsa_key > Earlier from a linux client(5.3p1) to > arm/linux server(5.3p1) was working fine. Now after upgrade it is > giving the no hostkey algorithm error. > > With both machines on the same version 5.3p1 cipher technique used > was hmac-md5, but with server in 7.9p1 it is choosing hmac-sha1. That's fine. > On what basis server chooses the cipher technique i.e hmac-md5 or > hmac-sha1? The server sends a list of algorithms that it supports and the client picks one. If the client doesn't have a supported (and enabled) algorithm matching one that the server offers for a particular purpose then the key exchange fails.
Thanks Darren. Tried with the configurations you provided. Its still not working in my case. >The server sends a list of algorithms that it supports and the client >picks one. If the client doesn't have a supported (and enabled) ?>algorithm matching one that the server offers for a particular purpose >then the key exchange fails. As you said key exchange fails if client doesn't supports the algorithm(here in this case hmac-sha1). So failed right? Is that mean 7.9p1 is not compatible with 5.3p1? Or is there any other configurations to add or modify. Please suggest. Thank you once again.
(In reply to Karthik Adiga from comment #7) > Thanks Darren. > > Tried with the configurations you provided. Its still not working in > my case. did you restart sshd after making the config change? > As you said key exchange fails if client doesn't supports the > algorithm yes. > (here in this case hmac-sha1). no. We can tell from the log of the failing connection that both sides support hmac-sha1: debug2: mac_setup: found hmac-sha1 debug1: kex: server->client aes128-ctr hmac-sha1 none debug2: mac_setup: found hmac-sha1 debug1: kex: client->server aes128-ctr hmac-sha1 none > So failed right? Is that mean 7.9p1 is not compatible with 5.3p1? It should work. I built a 5.3p1 client and was able to connect to a 7.9p1 server with the default config. I then forced the server to support only ssh-dss ("HostKeyAlgorithms ssh-dss") and got the same error you did. > Or is there any other configurations to add or modify. > > Please suggest. Thank you once again. I suggest: - make sure you are editing the right sshd_config. A self-built one will by default use /usr/local/etc/sshd_config/ - make sure sshd has been restarted with config changes in comment#5. If that doesn't work, please attach: - a client debug log with the suggested config changes. - a server debug log (eg "/path/to/sshd -ddde -p 2222" then connect with "ssh -p 2222") - a copy of the server's config file.
Created attachment 3261 [details] config's Hi Darren, I rebooted the board. And ssh keys & config files are present in /etc/ssh/ directory in our board. No where else its available. I followed the next steps you suggested and took logs, unfortunately Server couldn't start because of errors in Match statement. But with the old version the config files remains same and able to start daemon in server & can connect from client. Is match statement modified its usage. Please find the logs & config's as you suggested. Kindly help & suggest. Thank you
(In reply to Karthik Adiga from comment #9) > I followed the next steps you suggested and took logs, unfortunately > Server couldn't start because of errors in Match statement. wait, if the server doesn't start at all with 7.9p1 how were you able to do the original tests, and test my suggestions as per comment#6?
Created attachment 3262 [details] Logs Hi Daren As per your suggestion I had run the server & collected the logs. Only change between the old & current setup is I have removed match statements from sshd_config file. I could observe the client & server connection were able to establish with port 2222, whereas with port 222 not happening. Our customised port is 222. Firewall is disabled though. This is not observed in our old same 5.3p1 setup. Shared the logs with both working 2222 port & non-workin 222 port. Thanks for all suggestions & help. Kindly suggest.
Netstat traces when ssh tried from client. ========================================== 172.63.102.169 => Client 172.60.102.2 => server netstat -pan|grep 222 tcp 0 0 0.0.0.0:222 0.0.0.0:* LISTEN 2325/xinetd tcp 0 0 172.63.102.169:222 172.60.102.2:56155 TIME_WAIT - tcp 0 0 172.63.102.169:222 172.60.102.2:56157 TIME_WAIT - tcp 0 0 :::222 :::* LISTEN 4977/sshd
(In reply to Karthik Adiga from comment #12) > netstat -pan|grep 222 > tcp 0 0 0.0.0.0:222 0.0.0.0:* LISTEN 2325/xinetd that's not sshd listening on port 222. What's the xinetd config doing? Is it running the same sshd that you expect?
Also, empty match statements like the third line here are not valid, which is why sshd complained: Match User localOperator Banner /etc/warning_preauth Match What's the intent of that? If you want to remove a previous Match you want "Match all"
Thank you so much Darren. It's working now. :) We use customised sshd_config2 from where the ssh was picking the config's for port 222.
Glad you got it sorted out.
Created attachment 3266 [details] Error logs Hi Darren Now trying in different machine. client is at 7.9p1 & server is at 5.6p1 as earlier. Now getting the below error. Any idea for this? Checked in couple of google links. didn't help. Does 7.9p1 needs to PAM upgrade to 1.3.0 ? Thanks in advance.
(In reply to Karthik Adiga from comment #17) > Created attachment 3266 [details] > Error logs That looks like the server is immediately exiting, eg due to tcpwrappers or similar, an inetd wrapper failing to exec something or the server immediately crashing. You need to look at the logs on the server side eg by instructions in comment #8. > Does 7.9p1 needs to PAM upgrade to 1.3.0 ? no.
Hi Darren, Sorry to disturb you again. Hope you are doing good. Facing some other issue at run time. Server was in 8.0p1 version and generated ssh-rsa & ssh-dsa key pairs. Able to login from client. Later Server downgraded to 5.3p1, after reboot it generates only ssh-rsa1(i guess its ssh protocol 1) key pairs. And client not able to connect to sshd as sshd crashed. Please find the below logs. debug3: checking syntax for 'Match (null)' debug1: sshd version OpenSSH_5.3p1 debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key. debug1: PEM_read_PrivateKey failed debug1: read PEM private key done: type <unknown> Could not load host key: /etc/ssh/ssh_host_rsa_key debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key. debug1: PEM_read_PrivateKey failed debug1: read PEM private key done: type <unknown> Could not load host key: /etc/ssh/ssh_host_dsa_key Disabling protocol version 2. Could not load host key sshd: no hostkeys available -- exiting. I guess ssh-protocol 1 also we need to enable. Is it? If yes, how to do it? Thanks in advance.
(In reply to Karthik Adiga from comment #20) > debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key. > debug1: PEM_read_PrivateKey failed I would guess that those keys were generated with 8.0 and for some reason 5.3 doesn't understand them so if you must do this I'd try regenerating them with the ssh-keygen that shipped with 5.3p1. > Later Server downgraded to 5.3p1, Sorry, but 5.3p1 is pushing ten years of age and is not something we are willing to spend time supporting.
Thank you Darren. Is there any way it can still work with 8.0's generated keys to be worked for 5.3p1's sshd? Why exactly it is failing? Thank you again :)
Closing all resolved bug with release of openssh-8.2
(In reply to Karthik Adiga from comment #22) > Thank you Darren. Is there any way it can still work with 8.0's > generated keys to be worked for 5.3p1's sshd? Why exactly it is > failing? A version of ssh-keygen that old would have generated the keys using legacy PEM encoding. Recent versions use a different (stronger) format which the older sshd would not understand. You can cause a current ssh-keygen to generate PEM format keys using the "-m PEM" option, which can also be used with -p flag to convert an existing key to PEM.