topic Re: Password-less ssh no longer works after upgrade in Operating System - HP-UX

Password-less ssh no longer works after upgrade

RockA — Wed, 17 Oct 2018 20:29:03 GMT

We were running this ssh (found in /opt/ssh/hpux64/bin/)

-rwxr-xr-x 1 bin bin 1330600 Jan 7 2015 ssh*

And it was just upgraded to (found in same location)

-rwxr-xr-x 1 bin bin 1942744 Mar 19 2018 ssh*

And now ssh does not seem to recognize the id_dsa, even with the -i option. It keeps asking for a password.

Does this new version require new private keys?

Re: Password-less ssh no longer works after upgrade

Steven Schweda — Thu, 18 Oct 2018 03:01:34 GMT

> And now ssh does not seem to recognize the id_dsa, even with the -i
> option. It keeps asking for a password.

      uname -a

   Is this system the ssh client, server, or both?

> Does this new version require new private keys?

   I haven't upgraded anything lately, so I know nothing, but...

   Which "this new version"?

      ssh -V

   Recent ssh versions might have deprecated/desupported particular
encryption or hash algorithms.

   Generally, the debug procedure for the ssh client side involves
adding a "-v" option ("-vvv" seems to be popular) to the "ssh" command,
and seeking clues in the diagnostic output. On the server side, the
system log files typically show reasons for a failure.

> And it was just upgraded to [...]

   What, exactly, did you install? Did whatever you installed come with
any documentation? Release notes, for example?

Re: Password-less ssh no longer works after upgrade

RockA — Thu, 18 Oct 2018 13:29:31 GMT

Thanks for the reply, Steven!

It is the client that cannot connect to the server.

uname -a

HP-UX <server> B.11.31 U ia64 0545442868 unlimited-user license

The old version was:

OpenSSH_6.2p2+sftpfilecontrol-v1.3-hpn13v12, OpenSSL 1.0.2k 26 Jan 2017
HP-UX Secure Shell-A.06.20.030, HP-UX Secure Shell version

The new version is:

OpenSSH_7.4p1+sftpfilecontrol-v1.3-hpn14v12, OpenSSL 1.0.2k 26 Jan 2017
HP-UX Secure Shell-A.07.40.003, HP-UX Secure Shell version

The install was done by our central operations team.

Here's the ssh -v output:

OpenSSH_7.4p1+sftpfilecontrol-v1.3-hpn14v12, OpenSSL 1.0.2k 26 Jan 2017
debug1: Reading configuration data /opt/ssh/etc/ssh_config
debug1: Connecting to genawa-itg.austin.hpecorp.net [16.195.80.156] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/bb/.ssh/identity type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/bb/.ssh/identity-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/bb/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/bb/.ssh/id_rsa-cert type -1
debug1: identity file /home/bb/.ssh/id_dsa type 2
debug1: key_load_public: No such file or directory
debug1: identity file /home/bb/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/bb/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/bb/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/bb/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/bb/.ssh/id_ed25519-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1+sftpfilecontrol-v1.3-hpn14v12
debug1: match: OpenSSH_7.4p1+sftpfilecontrol-v1.3-hpn14v12 pat OpenSSH* compat 0x04000000
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1+sftpfilecontrol-v1.3-hpn14v12
debug1: Authenticating to genawa-itg.austin.hpecorp.net:22 as 'tuxadmin'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: AUTH STATE IS 0
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: REQUESTED ENC.NAME is 'chacha20-poly1305@openssh.com'
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: REQUESTED ENC.NAME is 'chacha20-poly1305@openssh.com'
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:EE87R0FOpAeS6e76QbXqn77ti2qKO3bmFEyzZ3ybWjk
debug1: Host 'genawa-itg.austin.hpecorp.net' is known and matches the ECDSA host key.
debug1: Found key in /home/bb/.ssh/known_hosts:5
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: Skipping ssh-dss key /home/bb/.ssh/id_dsa - not in PubkeyAcceptedKeyTypes
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
*******************************************************************
* *
* This is a private system; explicit authorization from the *
* system owner is required for access or use. Unauthorized *
* access or use may result in severe civil and/or criminal *
* liability, including without limitation under 18 USC *
* Sections 1030 et seq. All rights whatsoever are reserved. *
* *
*******************************************************************
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Miscellaneous failure
No credentials cache found

debug1: Miscellaneous failure
No credentials cache found

debug1:

debug1: Next authentication method: publickey
debug1: Trying private key: /home/bb/.ssh/identity
debug1: Trying private key: /home/bb/.ssh/id_rsa
debug1: Trying private key: /home/bb/.ssh/id_ecdsa
debug1: Trying private key: /home/bb/.ssh/id_ed25519
debug1: Next authentication method: password
<account>@<fqdn>s password:

If I use the -i option to call out the public key location:

OpenSSH_7.4p1+sftpfilecontrol-v1.3-hpn14v12, OpenSSL 1.0.2k 26 Jan 2017
debug1: Reading configuration data /opt/ssh/etc/ssh_config
debug1: Connecting to genawa-itg.austin.hpecorp.net [16.195.80.156] port 22.
debug1: Connection established.
debug1: identity file /home/bb/.ssh/id_dsa type 2
debug1: key_load_public: No such file or directory
debug1: identity file /home/bb/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1+sftpfilecontrol-v1.3-hpn14v12
debug1: match: OpenSSH_7.4p1+sftpfilecontrol-v1.3-hpn14v12 pat OpenSSH* compat 0x04000000
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1+sftpfilecontrol-v1.3-hpn14v12
debug1: Authenticating to genawa-itg.austin.hpecorp.net:22 as 'tuxadmin'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: AUTH STATE IS 0
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: REQUESTED ENC.NAME is 'chacha20-poly1305@openssh.com'
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: REQUESTED ENC.NAME is 'chacha20-poly1305@openssh.com'
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:EE87R0FOpAeS6e76QbXqn77ti2qKO3bmFEyzZ3ybWjk
debug1: Host 'genawa-itg.austin.hpecorp.net' is known and matches the ECDSA host key.
debug1: Found key in /home/bb/.ssh/known_hosts:5
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: Skipping ssh-dss key /home/bb/.ssh/id_dsa - not in PubkeyAcceptedKeyTypes
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
*******************************************************************
* *
* This is a private system; explicit authorization from the *
* system owner is required for access or use. Unauthorized *
* access or use may result in severe civil and/or criminal *
* liability, including without limitation under 18 USC *
* Sections 1030 et seq. All rights whatsoever are reserved. *
* *
*******************************************************************
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Miscellaneous failure
No credentials cache found

debug1: Miscellaneous failure
No credentials cache found

debug1:

debug1: Next authentication method: publickey
debug1: Next authentication method: password
<account>@<fqdn>'s password:

I have checked that the authorized_key file on the receiving end still contains the content of the id_dsa.pub.

The .ssh directory is secured as follows:

drwx------ 2 bb bbgrp 96 Jun 10 2017 .ssh/

the id_dsa file is secured as follows:

-rw------- 1 bb bbgrp 668 Sep 16 2016 id_dsa

Re: Password-less ssh no longer works after upgrade

Steven Schweda — Thu, 18 Oct 2018 16:35:18 GMT

> It is the client that cannot connect to the server.

   Yes, by definition, but who got the SSH upgrade?

> The install was done by our central operations team.

   Ok, but you may still need to know more than that.

   I still know nothing, but:

debug1: Skipping ssh-dss key /home/bb/.ssh/id_dsa - not in PubkeyAcceptedKeyTypes
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info:
server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received

   Apparently, the server is now more restrctive about its
PubkeyAcceptedKeyTypes. I'd guess that the server configuration could
be degraded to accept your old keys, but I'd also guess that such old
keys are now considered too weak.

Re: Password-less ssh no longer works after upgrade

RockA — Thu, 18 Oct 2018 17:06:31 GMT

Hi Steven,

The upgrade was the client only. I'll try re-creating the public key. Thanks for your help!

Re: Password-less ssh no longer works after upgrade

Steven Schweda — Thu, 18 Oct 2018 17:24:47 GMT

> The upgrade was the client only. [...]

   Hmmm. I'd've blamed the server, but what do I know?

>    I still know nothing, but:

   I may be learning:

      https://h20392.www2.hpe.com/portal/swdepot/displayProductInfo.do?productNumber=T1471AA

      * Going forward DSA host keys will be disabled and it is
      recommended not to use. To support DSA host keys in v.07.30 and
      above, an extra parameter (HostKeyAlgorithms) in sshd_config file.
      For more information, see https://www.openssh.com/legacy.html.

Re: Password-less ssh no longer works after upgrade

RockA — Thu, 18 Oct 2018 22:14:48 GMT

Thanks, Steven! I'll give that a try...

Re: Password-less ssh no longer works after upgrade

RockA — Tue, 23 Oct 2018 13:03:01 GMT

Many thanks for the link, Steven!

What worked was adding -oPubkeyAcceptedKeyTypes=+ssh-dss to the ssh command.

Re: Password-less ssh no longer works after upgrade

Steven Schweda — Tue, 23 Oct 2018 19:32:09 GMT

> What worked was adding -oPubkeyAcceptedKeyTypes=+ssh-dss to the ssh
> command.

You might be able to save some typing by adding that option to the
user's "~/.ssh/config" file (or system-wide in
"/opt/ssh/etc/ssh_config").

man ssh_config