SSH User CA: Sign a user certificate with selected hosts instead of all hosts?

Question

I have many servers that shares a common TrustedUserCAKeys. I want to sign a user certificate so it grants some access on specific servers instead of all of them.

For example, the following command generates a certificate that can be used to log in as root on all servers:

ssh-keygen -s ca -I example -n root id_rsa.pub

I tried the following command, but it generates a certificate that's ... useless.

ssh-keygen -s ca -I example -n root@server1 id_rsa.pub

I intended to generate a certificate that can only sign in as root on server1, but not root on any other server. I've made sure that server1 is the FQDN on that server (or the complete content of /etc/hostname). Is there a way to achieve this without touching sshd_config on any host?

Answer 1

Without changing the sshd_config file, the answer is generally no. The mechanism to pull this off is to setup an AuthorizedPrincipalsFile (or AuthorizedPrincipalsCommand). Without this directive in sshd_config, the default behavior is that the username for the authentication attempt must be listed literally as one of the principals embedded in the certificate. This is why 'root' works, but 'root@server1' does not.

In order to make a certificate using 'root@server1' work (without adding entries into /root/.ssh/authorized_keys), you would need to configure an AuthorizedPrincipalsFile for the root user (later OpenSSH versions permit this directive inside a Match block), and list 'root@server1', and do something similar on other servers. You can also extend this to permit certificates applicable to groups of servers, like 'root@dev' or even 'root@*', as long as each appropriate flavor is listed as a principal in the AuthorizedPrincipalsFile.

Another way of implementing this, is to explicitly list the CA key and allowed principals in the .ssh/authorized_keys file, using both the cert-authority and principals= options. These are covered in the sshd man page description of the Authorized_Keys File Format.

Answer 2

The problem is when you issue ssh certificate if you directly put root in Principals you will be giving access to all the servers which trust your CA.

To avoid this never issue a certificate with username. Instead create a strategy for access. A typical scenario is some people need access to testing servers, some need access to database servers and some need access to all the servers. So I create multiple principles

• project-dev - Access to Development/Testing Servers
• project-databases - Access to database servers
• project-super - Access to all the servers

To achieve this add AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u in sshd_config file.

So when someone tries to log in to a server with root username, it will check file /etc/ssh/auth_principals/root (notice %u stands for user).

So if user certificate has a principle listed in this file user will be given access.

Authorised principles file for this scenario will be

• Dev Servers - project-dev\nproject-super
• Database Servers - project-dev\nproject-super
• Production Servers - project-super

So create a strategy as per your needs.

Note : If you still issue certificate with root in Principles It would still work. So avoid that.

I wrote a blog to setup complete ssh certificate infrastructure :

https://medium.com/better-programming/how-to-use-ssh-certificates-for-scalable-secure-and-more-transparent-server-access-720a87af6617