Red Hat Bugzilla – Bug 1493406
Regression: SSH authorized_keys now has strict syntax WRT to spaces
Last modified: 2018-09-01 20:58:21 EDT
Description of problem: The SSH authorized_keys parsing used to accept keys that looked like this (notice the double space). ssh-rsa AAAAB3NzaC1yc2EAAAAB.... However once upgrading to the most recent OpenSSH in RHEL at this time, the spaces must be removed for sshd to recognize the key. ssh-rsa AAAAB3NzaC1yc2EAAAAB.... This can cause customers to lose access to systems. We discovered this in the Cockpit CI system. Version-Release number of selected component (if applicable): Regression happened when upgrading between the following versions: openssh-server-6.6.1p1-31.el7.x86_64 openssh-server-7.4p1-12.el7_4.x86_64 How reproducible: Every time: Steps to Reproduce: 1. Ensure target system has openssh-server-7.4p1-12.el7_4.x86_64 running 2. Add additional spaces to ssh key in authorized_keys on target system 3. Try to log in to the target system Actual results: Key is not parsed, login fails. Expected results: Key is used to log in. Additional info: Possible related log entries. sshd[67092]: debug1: trying public key file /root/.ssh/authorized_keys sshd[67092]: debug1: fd 4 clearing O_NONBLOCK sshd[67092]: debug2: user_key_allowed: check options: 'ssh-rsa ' sshd[67092]: debug2: user_key_allowed: advance: '' sshd[67092]: debug2: key not found
Hmmm, I pasted bad. Here's an authorized_key line that used to work, but no longer does: ssh-rsa AAAAB3NzaC1yc2EAAAAB.... blah@example.com Here's an authorized_key line that works on both old and now openssh: ssh-rsa AAAAB3NzaC1yc2EAAAAB.... blah@example.com
This change was introduced in 2014 (openssh-6.7) with the commit [1], in (ssh)key.c method (ssh)key_read(), which is parsing the public key from buffer. The old uudecode() method was replaced by the new sshbuf_b64tod() buffer call. The first method was skipping leading and trailing whitespace, but the second one is not (also it is already getting a "zero-length buffer" as an argument -- strchr(cp, ' ') returns the immediately following space). The fix can look like introducing the skipping of the whitespace in the sshkey_read() function, but as already mentioned, I am not sure how 3 years old bug will be accepted. Though lets give it a try. The following patch will allow me reading the keys with more whitespace characters between key identificator and the key blob: diff --git a/sshkey.c b/sshkey.c index fe874043..f5cf3bef 100644 --- a/sshkey.c +++ b/sshkey.c @@ -1210,6 +1210,9 @@ sshkey_read(struct sshkey *ret, char **cpp) return SSH_ERR_KEY_TYPE_MISMATCH; if ((blob = sshbuf_new()) == NULL) return SSH_ERR_ALLOC_FAIL; + /* skip whitespace */ + for (; *cp == ' ' || *cp == '\t'; cp++) + ; /* trim comment */ space = strchr(cp, ' '); if (space) { Let's see upstream opinions. [1] https://github.com/openssh/openssh-portable/commit/8668706d
*** Bug 1498614 has been marked as a duplicate of this bug. ***
FYI, this was fixed upstream and will be in OpenSSH 7.7 release, but in rather more complicated form than I proposed. We will probably not be able to backport the upstream fix, because it depends on removing the SSHv1 keys, but we might be able to achieve something similar if we would consider this as important enough.