Bug 1076895 - openssh-7.6p1-1.1.x86_64 fails key authentication
openssh-7.6p1-1.1.x86_64 fails key authentication
Status: RESOLVED INVALID
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Network
Current
x86-64 SUSE Other
: P5 - None : Major (vote)
: ---
Assigned To: Petr Cerny
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-01-20 08:50 UTC by ray herman
Modified: 2018-01-20 18:35 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ray herman 2018-01-20 08:50:59 UTC
Following "ypper dup"
openssh-7.6p1-1.1.x86_64 from 
opensuse:tumbleweed:20180117
Fails to authenticate to remote hosts (Leap-42.3) using keys (dsa and rsa).
Previous version worked.
Installing openssh-7.2p2-15.1.x86_64
from update/leap/42.3/oss/  restores functionality.
Comment 1 Neil Rickert 2018-01-20 15:41:36 UTC
Working fine for me with an RSA key.  I tried two different RSA keys, and both worked.

Yes, it fails with a DSA key.  I've been expecting this.  DSA keys were deprecated some time ago.  They have still worked because openSUSE has been slow in updating to a newer version.

When I try "ssh -v" I get:
 debug1: Skipping ssh-dss key nwr - not in PubkeyAcceptedKeyTypes

I expect you can "fix" your problem with a suitable line in sshd_config.  Presumably that goes on the 42.3 server to which you are connecting.

It looks as if this restriction has been there for a while, but was not enforced.  The new version is enforcing it.
Comment 2 ray herman 2018-01-20 18:30:50 UTC
My apologies for a momentary panic. 
Thanks Neil for pointing me in the right direction.
I had tried to login to an account with only a DSS key in "authorized_keys" on the remote host.

The openssh-7.6p1 local client appears not to use the DSA key (both DSA and RSA keys were present).  Adding the RSA public key to the remote host's authorized_keys solved the problem.

The new ssh-keygen can still generate DSS key pairs even although it does not use them.
Comment 3 ray herman 2018-01-20 18:35:50 UTC
User Error