[Bug 1790963] Re: Unable to connect with openssh 7.8 client and certificates
Launchpad Bug Tracker
1790963 at bugs.launchpad.net
Thu Nov 15 16:29:05 UTC 2018
This bug was fixed in the package openssh - 1:7.9p1-1
---------------
openssh (1:7.9p1-1) unstable; urgency=medium
* New upstream release (https://www.openssh.com/txt/release-7.9):
- ssh(1), sshd(8): allow most port numbers to be specified using service
names from getservbyname(3) (typically /etc/services; closes:
#177406).
- ssh(1): allow the IdentityAgent configuration directive to accept
environment variable names. This supports the use of multiple agent
sockets without needing to use fixed paths.
- sshd(8): support signalling sessions via the SSH protocol. A limited
subset of signals is supported and only for login or command sessions
(i.e. not subsystems) that were not subject to a forced command via
authorized_keys or sshd_config.
- ssh(1): support "ssh -Q sig" to list supported signature options.
Also "ssh -Q help" to show the full set of supported queries.
- ssh(1), sshd(8): add a CASignatureAlgorithms option for the client and
server configs to allow control over which signature formats are
allowed for CAs to sign certificates. For example, this allows
banning CAs that sign certificates using the RSA-SHA1 signature
algorithm.
- sshd(8), ssh-keygen(1): allow key revocation lists (KRLs) to revoke
keys specified by SHA256 hash.
- ssh-keygen(1): allow creation of key revocation lists directly from
base64-encoded SHA256 fingerprints. This supports revoking keys using
only the information contained in sshd(8) authentication log messages.
- ssh(1), ssh-keygen(1): avoid spurious "invalid format" errors when
attempting to load PEM private keys while using an incorrect
passphrase.
- sshd(8): when a channel closed message is received from a client,
close the stderr file descriptor at the same time stdout is closed.
This avoids stuck processes if they were waiting for stderr to close
and were insensitive to stdin/out closing (closes: #844494).
- ssh(1): allow ForwardX11Timeout=0 to disable the untrusted X11
forwarding timeout and support X11 forwarding indefinitely.
Previously the behaviour of ForwardX11Timeout=0 was undefined.
- sshd(8): when compiled with GSSAPI support, cache supported method
OIDs regardless of whether GSSAPI authentication is enabled in the
main section of sshd_config. This avoids sandbox violations if GSSAPI
authentication was later enabled in a Match block.
- sshd(8): do not fail closed when configured with a text key revocation
list that contains a too-short key.
- ssh(1): treat connections with ProxyJump specified the same as ones
with a ProxyCommand set with regards to hostname canonicalisation
(i.e. don't try to canonicalise the hostname unless
CanonicalizeHostname is set to 'always').
- ssh(1): fix regression in OpenSSH 7.8 that could prevent public-key
authentication using certificates hosted in a ssh-agent(1) or against
sshd(8) from OpenSSH <7.8 (LP: #1790963).
- All: support building against the openssl-1.1 API (releases 1.1.0g and
later). The openssl-1.0 API will remain supported at least until
OpenSSL terminates security patch support for that API version
(closes: #828475).
- sshd(8): allow the futex(2) syscall in the Linux seccomp sandbox;
apparently required by some glibc/OpenSSL combinations.
* Remove dh_builddeb override to use xz compression; this has been the
default since dpkg 1.17.0.
* Simplify debian/rules using /usr/share/dpkg/default.mk.
* Remove /etc/network/if-up.d/openssh-server, as it causes more problems
than it solves (thanks, Christian Ehrhardt, Andreas Hasenack, and David
Britton; closes: #789532, LP: #1037738, #1674330, #1718227). Add an
"if-up hook removed" section to README.Debian documenting the corner
case that may need configuration adjustments.
-- Colin Watson <cjwatson at debian.org> Sun, 21 Oct 2018 10:39:24 +0100
** Changed in: openssh (Ubuntu)
Status: Confirmed => Fix Released
--
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:
Fix Released
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