ssh_authorized_keys with space in comment breaks root account disabling

Bug #1136343 reported by Marc Riemer
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Released

Bug Description

if there is a space in the comment portion of an ssh_authorized_key, then the adding of a prefix is broken. That prefix would normally provide the way to provide the "please login as user 'ubuntu'" message. Instead, the user can go right in as root.

Reproduce cloud-config is:
   - ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA3I7VUf2l5gSn5uavROsc5HRDpZdQueUq5ozemNSj8T7enqKHOEaFoU2VoPgGEWC9RyzSQVeyD6s7APMcE82EtmW4skVEgEGSbDc1pvxzxtchBj78hJP6Cf5TCMFSXw+Fz5rF1dR23QDbN1mkHs7adr8GW4kSWqU7Q7NDwfIrJJtO7Hi42GyXtvEONHbiRPOe8stqUly7MvUoN+5kfjBM8Qqpfl2+FNhTYWpMfYdPUnE7u536WqzFmsaqJctz3gBxH9Ex7dFtrxR4qiqEr9Qtlu3xGn7Bw07/+i1D+ey3ONkZLN+LQ714cgj8fRS4Hj29SCmXp5Kt5/82cD/VN3NtHw== Scott Moser

After boot, you'll see that this key is present without the prefix, and the holder of that key can go in as root.

--- Original Bug Report --
If a ssh key has a comment like "Tim Test" ssh-import-id returns 1 and adds the key to the root user without the the login message "Please login as the user "xxxx" rather than the user "root".

# cloud-ini.log[DEBUG]: Failed to run command to import vm-user ssh ids#012Traceback (most recent call last):#012 File "/usr/lib/python2.7/dist-packages/cloudinit/config/", line 97, in import_ssh_ids#012 util.subp(cmd, capture=False)#012 File "/usr/lib/python2.7/dist-packages/cloudinit/", line 1429, in subp#012 cmd=args)#012ProcessExecutionError: Unexpected error while running command.#012Command: ['sudo', '-Hu', 'vm-user', 'ssh-import-id', 'vm-user']#012Exit code: 1#012Reason: -#012Stdout: ''#012Stderr: ''
Feb 28 19:57:14 host-5-57-41-6 [CLOUDINIT][WARNING]: Running ssh-import-id (<module 'cloudinit.config.cc_ssh_import_id' from '/usr/lib/python2.7/dist-packages/cloudinit/config/cc_ssh_import_id.pyc'>) failed

# config

ssh_pwauth: false
apt_update: true
resize_rootfs: true
ssh_import_id: [xxxxx]
 - ssh-rsa AAAB3NzaC1yc2EAAAADAQABAAABAQDBMjYcppgCFyEFyJZYKgGZccl7LEVE7tb74iXnB1jq22HUTaS7BuWmBte/VA9KIsexs2k3gUZFg1DV94nnRMctYPsDL31Re8kB+sTIsKZKoO0smfDO7NWXQdOw2fM9tYxUtbesfeadTOpzzOhoYSIkkNyL40zZC6OlVd34AczPoZ6KUZ8vE9MIcLS6T11OBrHmR9DCmjDoyydBvxVx1/k3uvoWO83Ex/iFnu0b4S/+4uQKM5B5ntwwPD/DEccq4/e3BJ7zXK86DvKkkRu3tnksD7owRRKPrtAPWzgSXNiEiFKeMdgWYsggCX5cbjMbkv3j6bjagQn9v7/K/KBOdm== Tim Test

Related branches

Revision history for this message
Scott Moser (smoser) wrote :

   I think that I understand your issue, and that you're actually reporting 2 separate issues.

a.) a space in the comment field a public key breaks the "no root" prefix
  This seems like a valid issue, and I understand it, thank you for reporting.

b.) 'ssh_import_id: [vm-user]' is not functioning as you expected
  ssh_import_id uses ssh-import-id. The purpose of ssh-import-id is to
  import a users keys from Ie, using 'ssh_import_id: [smoser]'
  would result in my ssh keys being pulled from into the configured 'user'

  In cloud-init available in 12.10 (quantal) and later, there is a richer
  method of describing users and groups including the ability to list
  ssh-import-id or ssh-authorized keys per user. See [1] for more

  In 12.04, this is just more limited, ssh-import-id only operates on the
  configured 'user'.

So, what I'll do is consider this a need to fix 'a'.
If I've misunderstood, something, please let me know.

And thanks for taking the time to report a bug.

Changed in cloud-init:
status: New → Incomplete
status: Incomplete → Triaged
importance: Undecided → Medium
Scott Moser (smoser)
summary: - ssh-import-id not accept comment of a valid ssh key
+ ssh_authorized_keys with space in comment breaks root account disabling
description: updated
Revision history for this message
Scott Moser (smoser) wrote :

I'm pretty sure that what is happening here is that the space is breaking the parser, and it thinks that there is a options field already there.
So there are 2 issues here, then:
a.) for disabling root account options should clearly be ignored if they *were* legitimately found
b.) we need to figure out how to determine if options are present or not in a key line.

man authorized_keys(5) says:
 | AuthorizedKeysFile specifies the files containing public keys for public
 | key authentication; if none is specified, the default is
 | ~/.ssh/authorized_keys and ~/.ssh/authorized_keys2. Each line of the
 | file contains one key (empty lines and lines starting with a ‘#’ are
 | ignored as comments). Protocol 1 public keys consist of the following
 | space-separated fields: options, bits, exponent, modulus, comment.
 | Protocol 2 public key consist of: options, keytype, base64-encoded key,
 | comment. The options field is optional; its presence is determined by
 | whether the line starts with a number or not (the options field never
 | starts with a number). The bits, expo‐ nent, modulus, and comment
 | fields give the RSA key for protocol version 1; the comment field is not
 | used for anything (but may be convenient for the user to identify the
 | key). For protocol version 2 the keytype is “ecdsa-sha2-nistp256”,
 | “ecdsa-sha2-nistp384”, “ecdsa-sha2-nistp521”, “ssh-dss” or “ssh-rsa”.

I'm not quite sure how to interpret
'the options field is optional; its presense is determined by whether
the line starts with a number or not'
As clearly, most lines in .ssh/authorized_keys do not start with
a number.

Revision history for this message
Scott Moser (smoser) wrote :

So, the above comment really applied to protocol 1.
We're really only interested in protocol 2.
I've walked through the sshd code, and the relevant code here is:

It basically does:
 - parse the line, ignoring the possibility of options entirely
    if that is a valid key with a valid key type, then use it
 - otherwise remove comment from the beginning and try parsing again
   - if that succeeds, use comment and key.

list of known types in (key_type_from_name in key.c):
 - rsa
 - dsa
 - ssh-rsa
 - ssh-dss
 - ecdsa
 - <email address hidden>
 - <email address hidden>
 - <email address hidden>
 - <email address hidden>
 - <email address hidden>
 - <email address hidden>
 - <email address hidden>

Revision history for this message
Scott Moser (smoser) wrote :

== recreate / test instructions ==

# get cloud-init updated deb to cloud-init_all.deb
$ rel="raring"
$ imgurl="$rel-server-cloudimg-amd64-disk1.img"

$ wget $imgurl -O $rel.img.orig
$ qemu-img convert -O qcow2 $rel.img.orig $rel.img.dist

$ chmod 444 $rel.img.dist
$ qemu-img create -f qcow2 -b $rel.img.dist patched.img.dist

# patch the patched.img.dist with new cloud-init
 bzr branch lp:~smoser/+junk/backdoor-image ./bi
 sudo ./bi/mount-callback-umount patched.img.dist -- \
    sh -ec 'mp=$MOUNTPOINT; cp cloud-init.deb $mp/tmp &&
            LANG=C chroot $mp dpkg -i /tmp/cloud-init.deb ;
            rm $mp/tmp/cloud-init.deb' --

$ cat > user-data <<EOF
password: passw0rd
chpasswd: { expire: False }
ssh_pwauth: True
  - ssh-rsa AAAAB3...NzaC1= Scott Moser

$ cloud-localds my-seed.img user-data

$ qemu-img create -f qcow2 -b $rel.img.dist unpatched.img
$ qemu-img create -f qcow2 -b patched.img.dist patched.img

$ kvm -net nic -net user,hostfwd=tcp::2222-:22 -drive file=patched.img,if=virtio -drive file=my-seed.img,if=virtio -curses

# then log in, you should be able to log in with ubuntu and passw0rd.
# sudo cat /root/.ssh/authorized_keys
# that would previously show the provided key above without a prefix
# the correct fix is to have 'options' string that disables root.

Revision history for this message
Scott Moser (smoser) wrote :

fixed in trunk at revno 787.

Changed in cloud-init:
status: Triaged → Fix Committed
Revision history for this message
Scott Moser (smoser) wrote :

fixed in 0.7.2

Changed in cloud-init:
status: Fix Committed → Fix Released
Scott Moser (smoser)
information type: Private Security → Public Security
Revision history for this message
Juerg Haefliger (juergh) wrote :

Are there plans to backport this fix to older versions of cloud-init and rebuild at least the LTS cloud images? Currently they're all broken in OpenStack since OpenStack by default creates a key with a 'Generated by Nova' comment.

Revision history for this message
Scott Moser (smoser) wrote :

  sorry for the bouncing around of bug dups I just realized that this one was also a dupe of 1220273.
  We can't fix this without changing behavior that someone might be relying on. Since that behavior isn't explicitly a security issue, we can't really do it.

To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.