This question regards configuration of SSH on client host side when a server HOST certificate is known to be compromised.

In brief: How do we revoke SSH HOST certificates, what files need to be updated on CLIENT side hosts so that the certificate offered by the responding server during ssh connection attempt is recognised as a revoked certificate?

The long version: CLIENT certificates:

Each user generates a key pair, submits the public key to a CLIENT CA who generates a client certificate and returns it to the user. The user puts the certificate (ending in -cert.pub) alongside his private key and it gets loaded by ssh-add when he adds the private key and supplies the passphrase.

The CLIENT CA's public key is listed in the server hosts' trusted CAs file and the sshd daemon authorises the user's connection because the CA appears in that file. It also checks other conditions specified the certificate such as not expired and account in user principals. The server also checks whether the certificate has been revoked against the revoked user's file. So when the user's private key and certificate have been compromised, as soon as the CA is notified, he revokes the certificate and distributes that to server host revoked users files.

Consequently the compromised key and certificate are no longer a threat when the revoked users files have been updated.

HOST certificates:

Each host node has a host certificate which has been signed by a HOST CA. Each client node has global known hosts file typically /etc/ssh_known_hosts which has been updated to contain an entry for the given HOST CA. But there appears to be no revoked hosts file anywhere.

When a user on the client node attempts to ssh into the server host, ssh (on the client host) accepts the host certificate offered by the server host because the public key of the signing authority who signed that certificate is in the ssh_known_hosts file.
But where and when is that host certificate verified against revocation? The revoked users file on hosts applies to client certificates regarding INCOMING connections. HOST certificates need to be checked by SSH on OUTGOING connections to server hosts, the certificate offered needs to be checked for revocation by SSH on the client side. If that were not done, the ONLY way to recover from a compromised host key and certificate would be for the CA itself to become untrusted, to be removed from /etc/ssh_known_hosts on the client host system. T his would mean all hosts with certificates signed by the same CA would also be rendered unknown hosts.

So what and where do we put revoked HOST information on client host side so that ssh recognises host certificates as revoked and identifies the HOST as untrustworthy?

Thanks in Advance

  • Ask CA to revoke the certificate and update CRL. Clients will automatically download CRL during connection and will be noticed that server certificate is revoked by its issuer. – Crypt32 Jul 19 '17 at 5:28
  • @Crypt32: OpenSSH certs are not the X.509/PKIX certs used in SSL/TLS and S/MIME etc, normally do not use external CA(s), and never use CRLs, although as the self-answer says they do have KRLs which are conceptually similar (but not automatic) – dave_thompson_085 Jul 19 '17 at 6:47

openssh specifies a configuration option for this.

Add the following line to /etc/ssh/ssh_config:

RevokedHostKeys /etc/ssh/revoked_host_keys

That file must exist and be readable otherwise all host keys will be rejected. The file can either contain a public key per line for each revoked host key. Or it can be a KRL file which is a more compact.

ssh-keygen can produce a KRL file from such a text file.

See man ssh-keygen and man ssh_config for more information.

Blush.. I'm answering my own question. Sorry for bothering everyone I had looked everywhere for an answer to my question, yet only found my answer after posting the question.

  • It is fine that you answer your own question. Other people might have the same question and now the answer is here. You should also accept the answer so that it is known to be valid. – Tero Kilkanen Jul 19 '17 at 8:29

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.