Skip to content. | Skip to navigation

Navigation

You are here: Home / Support / Guides / Tools / ssh and PKI / User Certificates

Personal tools

ssh and PKI

Using Public Key Authentication for ssh connections

User Certificates

Creating the Host CA

Remember, the CA is the root of your trust hierarchy so you want to keep it (the private part) safe. Where in your network you manipulate and store these keys depends on who has access to the host and its backups.

Again, this example uses a subdirectory of /etc/ssh as the storage directory. YMMV.

cd /etc/ssh
mkdir -p CAs/users
cd CAs/users
ssh-keygen -f user_ca

We haven't done anything special here, just generated a regular SSH key pair in a subdirectory.

Trusting the CA

The remote host needs to trust our user CA.

  1. Copy the CA to the remote host:

    scp user_ca.pub root@remote-host.example.com:/etc/ssh
    
  2. On the remote host, configure sshd to trust keys signed with user_ca:

    1. edit the config file:

      vi /etc/ssh/sshd_config
      

      Edit or add the line:

      TrustedUserCAKeys /etc/ssh/user_ca.pub
      
    2. restart sshd:

      service sshd restart
      

      or:

      systemctl restart sshd
      

      depending on your poison.

  3. Rinse and repeat for all your hosts.

Signing User Keys

  1. Retrieve the user's RSA pub key:

    scp root@user-host.example.com:~user/.ssh/id_rsa.pub .
    
  2. Sign the key we've just retrieved with our user_ca key, above:

    ssh-keygen -s user_ca -I "User's key Identification String" -n user -V +52w id_rsa.pub
    

    Again, we've passed a few more interesting flags:

    • -s key - we are signing with key
    • -I string - some human-readable identification string
    • NB no -h - this is not a host key
    • -n name[,name] - the principal name (s) that this certificate is valid for. Without this the certificate is valid for any (named) user. See note below. Some versions of OpenSSH may use -Z name[,name] instead.
    • -V duration - a duration for the validity of the signature, in this case 52 weeks from now (see ssh_config(5) for TIME FORMATS details, we could have given an explicit YYYYMMDD, for example (though see note below))

    and we'll get back a different SSH filename, id_rsa-cert.pub.

  3. Copy the new signed key back:

    scp id_rsa-cert.pub root@user-host.example.com:~user/.ssh
    ** do some repair on ownership/perms! **
    

Now, when the user uses their id_rsa key ssh will automatically pick up the certificate as well as the original identity:

$ssh-add id_rsa
Enter passphrase for id_rsa:
Identity added: id_rsa (id_rsa)
Certificate added: id_rsa-cert.pub (user)

Obviously, you can create multiple user CAs and use different signature validity durations depending on your categories of users: yourself, fellow sysadmins, others etc..

Note

Officially the SSH Certificates code was released in OpenSSH 5.4 however Redhat/CentOS' openssh-5.3p1 contains an almost complete version. In particular, -V duration doesn't accept the same options and -n name is replaced with -Z name[,name]. Without the principals option the certificate is valid from any user, i.e.. if the user's account is compromised then the certificate can be used to be claiming to be any user.

Document Actions