3

I am looking to implement signed certificates for SSH authentication. I have followed the steps here and am now trying to figure out how I am going to implement it on my systems.

As an example, we have two environments: Production and Testing; each with their own "user key" to sign other keys. I want to be able to control who can access each environment, but the inconvenience I am running into is allowing one user to access both environments with the same private key.

From the man page of 'ssh' under '-i identity_file':

ssh will also try to load certificate information from the filename obtained by appending -cert.pub to identity filenames

This seems to imply that I would have to have multiple copies of the private key (just named differently) and name the cert file accordingly in addition to adding a .ssh/config file entry in order for it to use the correct cert.

It is my understanding that if you specify multiple IdentityFile entries in the .ssh/config, ssh will try each of them. However, there doesn't seem to be an option (at least none I can find in the documentation) to specify a cert.

Is there a way to either specify a certificate file (other than the assumed -cert.pub) in the .ssh/config or a file that contains a list of certs to check?

2

The following works for me on Debian Stretch with OpenSSH 7.4p1:

Put every certificate in a separate file, e.g.:

~/.ssh/id_ed25519-cert-ca1.pub
~/.ssh/id_ed25519-cert-ca2.pub

Then list your certificate files in ~/.ssh/config:

CertificateFile ~/.ssh/id_ed25519-cert-ca1.pub
CertificateFile ~/.ssh/id_ed25519-cert-ca2.pub

Now the ssh command should try-and-pick the right certificate automatically.

From man ssh_config:

It is possible to have multiple certificate files specified in configuration files; these certificates will be tried in sequence. Multiple CertificateFile directives will add to the list of certificates used for authentication.

1

I don't know a good way to do this, but I do know two ways.

  1. The ssh-agent seems perfectly happy to store multiple certificates for a single identity. So if you, for example, have id_ed25519 as your id and id_ed25519-cert1.pub and id_ed25519-cert2.pub, you can do this:

    cp id_ed25519-cert1.pub id_ed25519-cert.pub
    ssh-add id_ed25519
    cp id_ed25519-cert2.pub id_ed25519-cert.pub
    ssh-add id_ed25519
    

    And now both certificates can be used with the identity. Again, this is not a good solution.

  2. Create symlinks for additional identities that point to the same identity, and give each its own cert. Or copy them outright. Again, ugly, but should work.

  3. You may be tempted to put multiple certificates (since they're each one line) in a single -cert.pub file. On my system this only recognizes the first line.

  4. For an extra fun time, note that signing an identity with a cert will overwrite without confirmation an existing cert.

The underlying issue here, in my opinion, is that the same model that works with CAs for hosts does not work for authorized users. Signing a host key (assuming you specify a principal) is a statement of authentication -- it states only that by this signature you know that the server's host key identifies it legitimately.

Signing a user key likewise conveys authentication, but here you have the additional problem of authorization -- the CA's signature indicates both that the key identifies the user legitimately AND that the user should be allowed to log in to the machine.

Host keys and user keys are not really dual, since initiating a handshake with a server is not comparable to logging in (even with restrictions on your capabilities), and can't be treated thus.

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.