Current state: Proof of concept.
A small SSH server that generates SSH user certificates on demand over an SSH connection.
You connect to the CA with your ordinary SSH client, using public key authentication.
Use it like this to first generate a certificate and then use the certificate to login to a server:
$ ssh -p 2222 user@localhost > cert.pub
$ ssh -i cert.pub user@some-ssh-server
The generated certificate will be valid and limited to the user name you use here ("user" above). Any user name is currently accepted if your public key is in the list of authorized keys.
You can use a TKey both for the user authentication and for the CA. The connection with the the TKey happens transparently through the use of tkey-ssh-agent running both on the CA server and your machine.
Nota bene: The TKey is (so far) not required to use this program.
-
System owners don't want to manage individual users' public keys on the servers or embedded systems.
-
Instead, they only install a trusted CA public key on all servers.
-
The system owner hands out Tillitis TKeys to all trusted users and enrolls them with the
tkey-ssh-ca
. -
Short-lived certificates are automatically generated when needed and specific to certain user roles or hosts, authenticated by the user's long-lived TKey identity.
You need to generate a host key pair to identify the host running the ssh-ca:
$ ssh-keygen -t ed25519
Call it host_ed25519
.
You need the tkey-ssh-agent installed and running on both the CA server and the user's machine.
Make sure the ssh-keygen
command is available.
If you don't want to touch the TKey every time the CA generates a cert look into the documentation to compile the tkey-ssh-agent and the corresponding tkey-device-signer without the touch requirement.
After starting the tkey-ssh-agent (possibly with a USS), get the
public key of your CA's key pair, typically with ssh-add -L
. Place
the key in a file called ca_key.pub
in the ssh-ca directory.
Note that if you're trying this out on the same machine you can use the same pubkey both for the CA and the user. You will then be expected to touch your TKey twice: first when authentication to tkey-ssh-ca, then to sign the new cert.
If you want to, you can allow anyone to request a certificate. If you
want to allow this, start the tkey-ssh-ca
with the --insecure
flag. NOTE WELL: Anyone who requests a certificate and presents a
public key will get a certificate!
If, on the other hand, you want to allow just a list of approved
identities to request a cert: Get the users' public keys and place
them in authorized_keys
in the tkey-ssh-ca directory, one per line
in this format:
ssh-ed25519 AAAA... key-id@domain
Insert the TKey in the CA server.
Start the CA server:
$ ./tkey-ssh-ca
Place the CA's public key you extracted to ca_key.pub
in /etc/ssh
on the servers you want to access.
Add this line:
TrustedUserCAKeys /etc/ssh/ca_key.pub
to /etc/ssh/sshd_config
.
Restart sshd.
Your server now trusts user certificates generated by this CA. You should be able to login with a cert.
tkey-ssh-ca currently depends the tkey-ssh-agent running on the CA server, too. This might change. It might, instead, connect to the TKey directly.