If you manage a bunch of server machines, you will undoubtedly have run into the following OpenSSH question:
The authenticity of host 'host.example.org (18.104.22.168)' can't be established. RSA key fingerprint is 1b:9b:b8:5e:74:b1:31:19:35:48:48:ba:7d:d0:01:f5. Are you sure you want to continue connecting (yes/no)?
If the server is a single-user machine, where you are the only person expected to login on it, answering “yes” once and then using the
Setting up one (or more) SSH Certificate Authority (CA) to create SSH Host Certificates, and have your users trust this CA, will allow you and your users to automatically trust the fingerprint of the host through the indirection of the SSH Host CA. I was surprised (but probably shouldn’t have been) to find that deploying this is straightforward. Even setting this up with hardware-backed keys, stored on a YubiKey NEO, is easy. Below I will explain how to set this up for a hypothethical organization where two persons (sysadmins) are responsible for installing and configuring machines.
I’m going to assume that you already have a couple of hosts up and running and that they run the OpenSSH daemon, so they have a
apt-get install yubikey-personalization yubico-piv-tool opensc-pkcs11 pcscd
Every person responsible for signing SSH Host Certificates in your organization needs a YubiKey NEO. For my example, there will only be two persons, but the number could be larger. Each one of them will have to go through the following process.
The first step is to prepare the NEO. First mode switch it to CCID using some device configuration tool, like yubikey-personalization.
Then prepare the PIV applet in the YubiKey NEO. This is covered by the YubiKey NEO PIV Introduction but I’ll reproduce the commands below. Do this on a disconnected machine, saving all files generated on one or more secure media and store that in a safe.
user=simon key=`dd if=/dev/random bs=1 count=24 2>/dev/null | hexdump -v -e '/1 "%02X"'` echo $key > ssh-$user-key.txt pin=`dd if=/dev/random bs=1 count=6 2>/dev/null | hexdump -v -e '/1 "%u"'|cut -c1-6` echo $pin > ssh-$user-pin.txt puk=`dd if=/dev/random bs=1 count=6 2>/dev/null | hexdump -v -e '/1 "%u"'|cut -c1-8` echo $puk > ssh-$user-puk.txt yubico-piv-tool -a set-mgm-key -n $key yubico-piv-tool -k $key -a change-pin -P 123456 -N $pin yubico-piv-tool -k $key -a change-puk -P 12345678 -N $puk
Then generate a RSA private key for the SSH Host CA, and generate a dummy X.509 certificate for that key. The only use for the X.509 certificate is to make PIV/PKCS#11 happy — they want to be able to extract the public-key from the smartcard, and do that through the X.509 certificate.
openssl genrsa -out ssh-$user-ca-key.pem 2048 openssl req -new -x509 -batch -key ssh-$user-ca-key.pem -out ssh-$user-ca-crt.pem
You import the key and certificate to the PIV applet as follows:
yubico-piv-tool -k $key -a import-key -s 9c < ssh-$user-ca-key.pem yubico-piv-tool -k $key -a import-certificate -s 9c < ssh-$user-ca-crt.pem
You now have a SSH Host CA ready to go! The first thing you want to do is to extract the public-key for the CA, and you use OpenSSH's ssh-keygen for this, specifying OpenSC's PKCS#11 module.
ssh-keygen -D /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so -e > ssh-$user-ca-key.pub
If you happen to use YubiKey NEO with OpenPGP using gpg-agent/scdaemon, you may get the following error message:
no slots cannot read public key from pkcs11
The reason is that
scdaemon exclusively locks the smartcard, so no other application can access it. You need to kill scdaemon, which can be done as follows:
gpg-connect-agent SCD KILLSCD SCD BYE /bye
The output from ssh-keygen may look like this:
Now all your users in your organization needs to add a line to their
@cert-authority *.example.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCp+gbwBHova/OnWMj99A6HbeMAGE7eP3S9lKm4/fk86Qd9bzzNNz2TKHM7V1IMEj0GxeiagDC9FMVIcbg5OaSDkuT0wGzLAJWgY2Fn3AksgA6cjA3fYQCKw0Kq4/ySFX+Zb+A8zhJgCkMWT0ZB0ZEWi4zFbG4D/q6IvCAZBtdRKkj8nJtT5l3D3TGPXCWa2A2pptGVDgs+0FYbHX0ynD0KfB4PmtR4fVQyGJjJ0MbF7fXFzQVcWiBtui8WR/Np9tvYLUJHkAXY/FjLOZf9ye0jLgP1yE10+ihe7BCxkM79GU9BsyRgRt3oArawUuU6tLgkaMN8kZPKAdq0wxNauFtH
Each sysadmin needs to go through this process, and each user needs to add one line for each sysadmin. While you could put the same key/certificate on multiple YubiKey NEOs, to allow users to only have to put one line into their file, dealing with revocation becomes a bit more complicated if you do that. If you have multiple CA keys in use at the same time, you can roll over to new CA keys without disturbing production. Users may also have different policies for different machines, so that not all sysadmins have the power to create host keys for all machines in your organization.
The CA setup is now complete, however it isn't doing anything on its own. We need to sign some host keys using the CA, and to configure the hosts' sshd to use them. What you could do is something like this, for every host host.example.com that you want to create keys for:
h=host.example.com scp root@$h:/etc/ssh/ssh_host_rsa_key.pub . gpg-connect-agent "SCD KILLSCD" "SCD BYE" /bye ssh-keygen -D /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so -s ssh-$user-ca-key.pub -I $h -h -n $h -V +52w ssh_host_rsa_key.pub scp ssh_host_rsa_key-cert.pub root@$h:/etc/ssh/
The ssh-keygen command will use OpenSC's PKCS#11 library to talk to the PIV applet on the NEO, and it will prompt you for the PIN. Enter the PIN that you set above. The output of the command would be something like this:
Enter PIN for 'PIV_II (PIV Card Holder pin)': Signed host key ssh_host_rsa_key-cert.pub: id "host.example.com" serial 0 for host.example.com valid from 2015-06-16T13:39:00 to 2016-06-14T13:40:58
The host now has a SSH Host Certificate installed. To use it, you must make sure that
You need to restart sshd to apply the configuration change. If you now try to connect to the host, you will likely still use the known_hosts fingerprint approach. So remove the fingerprint from your machine:
ssh-keygen -R $h
Now if you attempt to ssh to the host, and using the -v parameter to ssh, you will see the following:
debug1: Server host key: RSA-CERT 1b:9b:b8:5e:74:b1:31:19:35:48:48:ba:7d:d0:01:f5 debug1: Host 'host.example.com' is known and matches the RSA-CERT host certificate.
One aspect that may warrant further discussion is the host keys. Here I only created host certificates for the hosts' RSA key. You could create host certificate for the DSA, ECDSA and Ed25519 keys as well. The reason I did not do that was that in this organization, we all used GnuPG's gpg-agent/scdaemon with YubiKey NEO's OpenPGP Card Applet with RSA keys for user authentication. So only the host RSA key is relevant.
Revocation of a YubiKey NEO key is implemented by asking users to drop the corresponding line for one of the sysadmins, and regenerate the host certificate for the hosts that the sysadmin had created host certificates for. This is one reason users should have at least two CAs for your organization that they trust for signing host certificates, so they can migrate away from one of them to the other without interrupting operations.
Thanks, this was useful.
One question: ssh-keygen’s default signature validity seems to be that the it’s valid forever, which is a bit too much.
What’s the rational of choosing a signing validity of 1 year (-V +52w)?
That is a good question! The 52w was arbitrarily picked. One data point is that when the signature expires, the ssh client falls back to the regular host pinning prompt. So there is no fatal error at least.
I must admit I haven’t considered the pro’s and con’s of setting shorter/longer validity period on SSH host keys. If the signature is valid forever, you have a problem if someone steals the host private key and its certificate — they can impersonate that host going forward, and you have to revoke that certificate and distribute the revocation cert to all your users. This applies even for shorter validity periods too. So maybe an indefinite signature lifespan isn’t such a bad idea.
After running with this scheme a bit, I have mixed feelings about what it really provides you with. To work properly, all users will need to get a known_hosts snippet with the CA host certs, and possibly any revocation certs. As you will want to rotate the CA key once in a while as well, your users need a security facility to get their known_hosts snippet and have it updated. And if you have that, you could just as well distribute all your SSH host key fingerprints directly in that file instead, and skip all this SSH Host CA stuff.
Anyway, it is fun technology to play with. 🙂
Pingback: Let’s Encrypt Clients – Simon Josefsson's blog
Hello i have been following your posts about yubikeys and they are pretty thorough. I was wondering can we somehow use a gpg smartcard such as a yubikey with console and graphical logins instead of having to expose the ca master key to the local filesystem like the pam_pkcs11 module requires?
I haven’t used pam_pkcs11 actually. If you are anyone tests it, let us all know!
Correction: pam_pkcs11 requires the ca cert
I would like to point out that generating the RSA key outside the yubikey is a bad idea. And since you yubikey is actually capable of generating keys on board in such a way that they will never leave the key I would strongly opt for such a solution. At least if you will have different keys on the yubikeys. If you want the same key on multiple yubikeys it makes sense to import it sice yubikey have no secure export/import function.
I have written post about how to have scalable access control using openssh certificates: https://framkant.org/2017/07/scalable-access-control-using-openssh-certificates/
Hi Peter. Thanks for your link and work! I don’t agree that generating a key outside of the YubiKey is always a “bad idea”. For security purposes, I prefer to use free software that can be audited and reviewed. Generating the key is such a critical part of security that I am not willing to give that part up to something I cannot inspect. Your mileage may vary, of course, but where to generate the private key depends on who you trust. For many people, I would agree that generating the key on-board will lead to better overall security though.
Ah, I get your point.
Thanks for the reply!