openssh bugs - Apr 2019 - [Bug 2991] New: Not supports hmac-md5 ciphering technique

https://bugzilla.mindrot.org/show_bug.cgi?id=2991

            Bug ID: 2991
           Summary: Not supports hmac-md5 ciphering technique
           Product: Portable OpenSSH
           Version: 7.9p1
          Hardware: ARM
                OS: Linux
            Status: NEW
          Severity: major
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: karthikadiga123 at gmail.com

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 at openssh.com
debug2: kex_parse_kexinit: none,zlib at 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

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2991

Jakub Jelen <jjelen at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jjelen at redhat.com

--- Comment #1 from Jakub Jelen <jjelen at redhat.com> ---
This sounds more like unknown host key algorithm. Please, provide
complete logs.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2991

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at dtucker.net

--- Comment #2 from Darren Tucker <dtucker at dtucker.net> ---
(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 ...

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2991

Karthik Adiga <karthikadiga123 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |karthikadiga123 at gmail.com

--- Comment #3 from Karthik Adiga <karthikadiga123 at gmail.com> ---
Created attachment 3260
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3260&action=edit
Both working & Non working Logs for referenece

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2991

--- Comment #4 from Karthik Adiga <karthikadiga123 at gmail.com> ---
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.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2991

--- Comment #5 from Darren Tucker <dtucker at dtucker.net> ---
(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 at openssh.com,ssh-dss-cert-v01
at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh-dss-cert-v00 at
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.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2991

--- Comment #6 from Karthik Adiga <karthikadiga123 at gmail.com> ---
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.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2991

--- Comment #7 from Karthik Adiga <karthikadiga123 at gmail.com> ---
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.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2991

--- Comment #8 from Darren Tucker <dtucker at dtucker.net> ---
(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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2991

--- Comment #9 from Karthik Adiga <karthikadiga123 at gmail.com> ---
Created attachment 3261
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3261&action=edit
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

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2991

--- Comment #10 from Darren Tucker <dtucker at dtucker.net> ---
(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?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2991

--- Comment #11 from Karthik Adiga <karthikadiga123 at gmail.com> ---
Created attachment 3262
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3262&action=edit
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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2991

--- Comment #12 from Karthik Adiga <karthikadiga123 at gmail.com> ---
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

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2991

--- Comment #13 from Darren Tucker <dtucker at dtucker.net> ---
(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?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2991

--- Comment #14 from Darren Tucker <dtucker at dtucker.net> ---
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"

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2991

--- Comment #15 from Karthik Adiga <karthikadiga123 at gmail.com> ---
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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2991

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WORKSFORME

--- Comment #16 from Darren Tucker <dtucker at dtucker.net> ---
Glad you got it sorted out.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2991

--- Comment #17 from Karthik Adiga <karthikadiga123 at gmail.com> ---
Created attachment 3266
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3266&action=edit
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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2991

--- Comment #18 from Darren Tucker <dtucker at dtucker.net> ---
(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.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2991

Karthik Adiga <karthikadiga123 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WORKSFORME                  |---

--- Comment #19 from Karthik Adiga <karthikadiga123 at gmail.com> ---
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.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2991

--- Comment #20 from Karthik Adiga <karthikadiga123 at gmail.com> ---
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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2991

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |WORKSFORME

--- Comment #21 from Darren Tucker <dtucker at dtucker.net> ---
(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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2991

Karthik Adiga <karthikadiga123 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WORKSFORME                  |---

--- Comment #22 from Karthik Adiga <karthikadiga123 at gmail.com> ---
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 :)

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2991

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |WORKSFORME

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2991

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #23 from Damien Miller <djm at mindrot.org> ---
Closing all resolved bug with release of openssh-8.2

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2991

--- Comment #24 from Darren Tucker <dtucker at dtucker.net> ---
(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.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.