To my understanding, ssh certificates are good for ,at least, two things: prevents a key sprawl and applies expirations. Instead of needing public keys for every user on the server, the server only needs one public key— the CA’s public key.

My question is: how is an individual user authenticated; how are particular permissions and roles authorized? If the CA public key authenticates the connection via a digital signature, and the server doesn’t store the public key— because after all that is the allure of an SSH certificate Authority, namely not storing a bunch of authorized keys— how does it know I am who I say I am and how does it apply the particular permissions to my session?

As Authentication of the client is concerned, It seems to me that even if I use ssh certificates the server must: first authenticate the clients public key by decrypting the digital signature with the CA public key. If it successfully decrypts then it is proven my key has been signed by the CA. Okay great. But what then. What does it do with my public key? If it isn’t stored in the authorized keys directory how does it know it’s me?

Simply, Does the ssh server store my public key? I cannot see how this would work otherwise. But if it does store it, then how would this not result in a key sprawl, which is what we’re trying to avoid?

Unless the server encrypts something with my public key after verifying the CA signature, and then sends it back for the client to decrypt. If it comes back decrypted this proves the client is in possession of the private key. And after this the server throws away the public key. Does it work like this?


Reference: https://smallstep.com/blog/use-ssh-certificates/

Essentially, your client sends a request to the CA for a certificate to use. The CA would say that you can login as user xx on server yy. It issues you the private certificate to use, and it is short lived - for example, 8 hours for a working day.

Your SSH client then sends that certificate to the remote target. The remote target gets the certificate, validates it with the Public CA certificate to prove you talked to the CA. It can then encrypt data with its own private cert, and send it back to your client. Your client uses the remote's public certificate to verify the information, and secure the connection.

You do not need to edit the ~/.ssh/authorized_keys using certificates. Your remote hosts only need the CA's public certificate, and their own private certificate, while your CA host also has public certs for your targets.

This is an over-simplification of the process.


Among all the process you described, there is also the concept of a "principal". For the moment, think of the principal as a "role" of some kind.

That is, a user may have several roles (specified when the CA signs her key), and a server may allow several roles (see below) to log in to it using a cert. As long as these two role-lists have at least one role (i.e., "principal") in common, you're in.

Server principals come from either sshd config's AuthorizedPrincipalsFile or the principals= option in the users ~/.ssh/authorized_keys file. They could also come from a specified AuthorizedPrincipalsCommand program, which dynamically produces lines with the required principals syntax (in other words, a dynamic version of the AuthorizedPrincipalsFile)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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