Comment 4 for bug 1613199

Thanks Augistina,
I believe you are correct, nova does accept keys generated according to rfc4253. At issue is whether nova should accept only keys formated according to rfc4253, or all contents intended for the default users authorized_keys file. (The format of the authorized_keys file isn't covered by the RFC, but by the man page for OpenSSHD https://www.freebsd.org/cgi/man.cgi?sshd(8) under the section AUTHORIZED KEYS FILE FORMAT.)

My point is that keys generated according to RFC4253 are a subset of the content people expect to put in the authorized_keys. Now nova already goes beyond RFC4253 by accept a comment field on the ened of the public key matter (or more specifically both paramiko and python-cryptography go beyond RFC4253).
Its tempting to say that nova shouldn't go beyond RFC4253 because it already support public keys, but I think this is a loss of functionality.

So my workflow was roughtly:

ssh-keygen -f ca
ssh-keygen -f personal
echo "cert-authority " > uploadthis.pub
cat ca.pub >> uploadthis.pub
nova keypair-add -f uploadthis.pub ca_keypair
ssh-keygen -s ca -I Chris_Key -n debian,ubuntu,ec2-user -V +520w personal.pub # this produces personal-cert.pub
eval `ssh-agent` # note that gnome-ssh-keyring doesn't work, Mac OS keyring does, OpenSSH ssh-agent does
ssh-add personal
nova boot .....
ssh ...

I then collect pub keys from my colleagues and repeat the ssh-keygen -s and lock up the file "ca" (the private part) in a safe. My colleagues don't need access to the private part of ca because they have their own cert (in the same way my web server doesn't need access to the private part of the x509 root cas for SSL verification). When ever we on board a new team member, the ca file comes out of the safe. Whenever a team member leaves, we update the certificate revocation list (Actually we haven't had to do this yet, since this is a new workflow). Because everyone had their own personal key we don't need to rekey the instances.

Other workflows that are impacted involve pre-pending differemt material to the front of the public key. For example if you wish to use nova to setup an rsync server that no one can log into, and restrict rsync to a subdirectory you could follow instructions here

https://www.samba.org/ftp/unpacked/rsync/support/rrsync

The full list of options is in the sshd man page

Thanks for your time looking at this (and reading my long comments :-)

Cheers,
--
Chris.