[Bug 1790963] Re: Unable to connect with openssh 7.8 client and certificates
Bug Watch Updater
1790963 at bugs.launchpad.net
Wed Nov 7 18:30:25 UTC 2018
Launchpad has imported 8 comments from the remote bug at
https://bugzilla.redhat.com/show_bug.cgi?id=1623929.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2018-08-30T13:22:47+00:00 Jakub wrote:
Description of problem:
The OpenSSH server in RHEL7.6 does not send complete list of signature algorithms in SHA2 extension.
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
This causes failures if the client is on OpenSSH 7.8p1+ (Fedora 28+) and
for some reason disabled the rsa-sha2-* public key algorithms with
PubkeyAcceptedKeyTypes configuration option.
The correct list should look like this:
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-
sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384
,ecdsa-sha2-nistp521,null>
This does not affect any other key types at this moment.
Version-Release number of selected component (if applicable):
openssh-7.4p1-16
How reproducible:
specific configuration
Steps to Reproduce:
1. Install OpenSSH 7.8p1 (Fedora 28+)
2. Configure pubkey authentication using RSA key with remote server example.com
3. ssh -vvv -o PubkeyAcceptedKeyTypes=ssh-rsa example.com
Actual results:
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:I1XXiJ/wkXC6Vn8ohZVHcJTCCKoPKm4mL8qtjtyNMhw /home/lslebodn/.ssh/id_rsa
debug1: send_pubkey_test: no mutual signature algorithm
Expected results:
The authentication should proceed using ssh-rsa algorithm.
Additional info:
This is a change in OpenSSH 7.8 that it is getting more strict about handling this extension. Unfortunately we carry broken version in RHEL7, which is not sending complete list of algorithms.
Workaround:
In client, list also the SHA2 extension algorithms:
PubkeyAcceptedKeyTypes rsa-sha2-256,rsa-sha2-512
If you need to adjust this list, rather use the + sign.
Thanks lslebodn for reporting this issue to me.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1790963/comments/0
------------------------------------------------------------------------
On 2018-09-04T16:46:16+00:00 Christoph wrote:
Hi,
client fedora 28 with openssh-7.8p1-2.fc28.x86_64
using a ssh-rsa-cert-v01 at openssh.com client certificate
> debug1: Offering public key: RSA-CERT > SHA256:xxx /home/c/.ssh/id_rsa-cert.pub
> debug1: send_pubkey_test: no mutual signature algorithm
The proposed workaround does not seem to work (Even if adding the cert
type)
> PubkeyAcceptedKeyTypes rsa-sha2-256,rsa-sha2-512,ssh-rsa,ssh-rsa-
cert-v01 at openssh.com
Reply at:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1790963/comments/1
------------------------------------------------------------------------
On 2018-09-04T17:33:06+00:00 Jakub wrote:
If you want to use certificates, you need to list also the SHA2 variants
of certificates:
rsa-sha2-256-cert-v01 at openssh.com,rsa-sha2-512-cert-v01 at openssh.com
Not sure if this is somewhere documented, but is should do the job.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1790963/comments/2
------------------------------------------------------------------------
On 2018-09-05T11:07:44+00:00 Christoph wrote:
Hi,
i tried
PubkeyAcceptedKeyTypes rsa-sha2-256,rsa-sha2-512,rsa-
sha2-256-cert-v01 at openssh.com,rsa-sha2-512-cert-v01 at openssh.com,ssh-rsa-
cert-v01 at openssh.com
but still
debug1: send_pubkey_test: no mutual signature algorithm
Reply at:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1790963/comments/3
------------------------------------------------------------------------
On 2018-09-05T11:36:43+00:00 Jakub wrote:
Please, open a customer case if you have this issue with your RHEL
installation.
https://access.redhat.com/
This will really need a fix in RHEL7 since the new OpenSSH checks the
signature algorithms against the hardcoded list there, which is wrong.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1790963/comments/4
------------------------------------------------------------------------
On 2018-09-06T17:21:31+00:00 Etienne wrote:
Hi all,
Even if the CA is an RSA key, you can sign ECDSA or ED25519 keys so you
get ECDSA/ED25519 certs which allow you to work around the issue without
changing anything server-side
Exemple cert:
$ ssh-keygen -Lf ~/.ssh/id_ed25519-cert.pub
~/.ssh/id_ed25519-cert.pub:
Type: ssh-ed25519-cert-v01 at openssh.com user certificate
Public key: ED25519-CERT SHA256:<...>
Signing CA: RSA SHA256:<...>
Key ID: "..."
Reply at:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1790963/comments/8
------------------------------------------------------------------------
On 2018-10-31T12:17:01+00:00 Christoph wrote:
I think something happend within openssh 7.9 if my interpretation of
this is correct: https://www.spinics.net/lists/openssh-unix-
dev/msg05371.html
Reply at:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1790963/comments/12
------------------------------------------------------------------------
On 2018-10-31T12:55:48+00:00 Jakub wrote:
Indeed, there is fix [1] in latest OpenSSH 7.9p1 so updating the clients
to the latest version should resolve the issue. But it does not change
that there is a bug in RHEL7 too.
[1] https://github.com/openssh/openssh-portable/commit/1a4a9cf8
Reply at:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1790963/comments/13
** Changed in: openssh (Fedora)
Status: Unknown => Confirmed
** Changed in: openssh (Fedora)
Importance: Unknown => Undecided
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1790963
Title:
Unable to connect with openssh 7.8 client and certificates
Status in openssh package in Ubuntu:
Confirmed
Status in openssh package in Fedora:
Confirmed
Bug description:
Users are unable to connect to Ubuntu when using openssh client 7.8
and certificates. We have seen this with both xenial and bionic, but
this affects connecting to ANY host running openssh server <7.8.
It appears to be specific to using certificate authentication.
The only known recourse at this time is either downgrade clients to
7.7 or a previous version of openssh, or create new keys/certificates
with a different alg that is acceptable for both the older server and
newer client.
The error message via ssh -vvv is:
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:REDACTED
debug1: send_pubkey_test: no mutual signature algorithm
When comparing the list returned from a 7.6 server and a 7.8 server
via "ssh -Q key", we find that 7.8 returns rsa-
sha2-512-cert-v01 at openssh.com and rsa-sha2-256-cert-v01 at openssh.com
which are not present (or valid) for the earlier version server.
It appears that the change noted here in the release notes[1] for 7.8 is related:
* sshd(8): the semantics of PubkeyAcceptedKeyTypes and the similar
HostbasedAcceptedKeyTypes options have changed. These now specify
signature algorithms that are accepted for their respective
authentication mechanism, where previously they specified accepted
key types. This distinction matters when using the RSA/SHA2
signature algorithms "rsa-sha2-256", "rsa-sha2-512" and their
certificate counterparts. Configurations that override these
options but omit these algorithm names may cause unexpected
authentication failures (no action is required for configurations
that accept the default for these options).
This is also affecting other Linux distributions as well:
https://bugzilla.redhat.com/show_bug.cgi?id=1623929
https://bugs.archlinux.org/task/59838
[1] https://www.openssh.com/txt/release-7.8
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1790963/+subscriptions
More information about the foundations-bugs
mailing list