The usual way to log in to a Linux machine in the cloud is an SSH key: a file on your computer and its public counterpart copied to the machine. It works, but look at what it implies once there is more than one person and more than one machine: every key has to be copied to every machine, every person who leaves leaves their key on all of them until someone remembers to delete it, and a lost key is valid for ever. Do you know today, for certain, how many keys can log in to your production server and whose they are?

SSH certificates solve exactly that. It is the same technology Simplio uses for its spare key and the same one Lightsail uses for its web console, and you do not need to be an expert to understand it.

Before you start: what each thing means

SSH key: A pair of files: the private one (stays on your computer, never shared) and the public one (copied to the machine, in the user's authorized_keys file). The machine lets in whoever proves they have the private one.
SSH certificate: Your public key, signed by an authority, with a name, an expiry date and a list of users it is valid for. The machine does not need to know your key: it is enough for it to trust whoever signed it.
Certificate authority (CA): Another SSH key, but one that is only used for signing. Its public part is copied to the machines once; its private part is kept very safe, because whoever has it can sign certificates.
Principal: The user name the certificate is valid for. A certificate for "ubuntu" cannot be used to log in as "root".
Validity: From when and until when the certificate is valid. It can be a year or five minutes.
authorized_keys: The file, inside the .ssh folder of each user on the machine, with the public keys that can log in as that user. It also accepts a special line that says "accept certificates signed by this authority".

Step by step

Understand the difference with an example

With keys: for Ana to log in to ten machines, her public key is copied to ten files. When Ana leaves, it has to be deleted from ten places, and if one is forgotten, Ana (or whoever has her laptop) can still get in. With certificates: the ten machines trust one authority. Ana is issued a certificate valid until Friday. On Saturday, Ana cannot get into any of them, without touching a single machine. And if she is issued a new one every morning, there is never anything to revoke.
Create an authority (once, on your computer)
```
ssh-keygen -t ed25519 -f mi_ca -C "CA de mi empresa"
```
Two files come out. mi_ca is the private one: keep it in a password manager or on an encrypted disk, and never copy it to any machine. mi_ca.pub is the one that will go to the machines.
Tell the machine to trust your authority

There are two ways. The global one, in /etc/ssh/sshd_config, applies to all users:
```
TrustedUserCAKeys /etc/ssh/mi_ca.pub
```
And the local one, without touching the SSH configuration: a line in the user's authorized_keys, which applies only to that user:
```
cert-authority,principals="ubuntu" ssh-ed25519 AAAA... CA de mi empresa
```
The second is the right one in Lightsail, because Lightsail already uses TrustedUserCAKeys for its own web console and there can only be one. Reload SSH (sudo systemctl reload ssh) and the machine now accepts your certificates.
Sign a certificate for a person

The person sends you their public key (id_ed25519.pub). You sign it, saying which user it is valid for and how long it lasts:
```
ssh-keygen -s mi_ca -I "ana-portatil" -n ubuntu -V +1w id_ed25519.pub
```
Out comes id_ed25519-cert.pub: you give it back to them and they put it next to their key. -I is a name for the machine's log (so you know who logged in), -n the allowed user and -V +1w one week of validity. You can put +5m and you will have a five-minute certificate.
Log in and check
```
ssh -i id_ed25519 ubuntu@IP.DE.LA.MAQUINA
```
SSH uses the certificate on its own. On the machine, sudo journalctl -u ssh | grep ana-portatil shows you the login with the name you gave when signing. Once the validity has passed, the same command answers "Permission denied" without anyone having touched anything.
Add conditions: only from one IP

When signing you can add restrictions. The most useful: that the certificate is only valid from a specific address.
```
ssh-keygen -s mi_ca -I "copias-nocturnas" -n backup -V +1d -O source-address=203.0.113.10 id_backup.pub
```
If that certificate leaks, it is useless from any other IP. This is what Simplio's spare key does: five-minute certificates, for a single user, valid only from the IP of Simplio's server.

What can go wrong

"Permission denied" even though the certificate is correct

The most common: the principal does not match (you signed for "ubuntu" and are logging in as "admin"), the validity has already passed, or the machine's clock is wrong (certificates depend on the clock; check with date and enable time synchronisation).

The machine already had TrustedUserCAKeys

This is the case with Lightsail and some images. Do not change it: you would lose the web console. Use the cert-authority line in the user's authorized_keys, which coexists without any problem.

I have lost the CA's private key

You cannot sign any more certificates, but the ones already signed remain valid until they expire. Create a new CA and replace the public key on the machines while the old certificates still get in. That is why short validities are an advantage: the changeover completes on its own.

The CA's private key has been stolen

Whoever has it can sign certificates for all your machines. Replace the public key on all of them as soon as possible; if you used source-address, the thief also needs to be at that IP. That is the reason to keep it off the machines and out of email.

In Simplio

Simplio uses SSH certificates under the hood so that you do not have to. The terminal in the browser logs in with the temporary key AWS issues for each session, without anyone receiving a file. And the spare key is exactly what this guide explains, taken to the limit: a user without a password on the machine, which only accepts certificates signed by Simplio, five minutes long, for that user and only from Simplio's IP, with your two-factor code on every use. You set up the key with one button and Simplio checks every day that it still opens. How the spare key works.

The same task, in AWS and in Simplio

	In the AWS console	In Simplio
Give a person access	Copy their key to every machine	Grant them the machine in Simplio: the browser terminal uses the temporary key AWS provides
Take it away	Delete their key from every machine, without forgetting any	Take the machine away from them in Simplio
Emergency access	Create your CA, distribute the public key, sign a certificate by hand when needed	Spare key: five-minute certificate, signed by Simplio, only from its IP, with two-factor
Know who logged in	Read the SSH log on each machine	Simplio activity log: who, which machine, when, from which IP

Try it free for 15 days See how it works

SSH certificates explained from scratch: log in to your machines without handing out keys

Before you start: what each thing means

Step by step

Understand the difference with an example

Create an authority (once, on your computer)

Tell the machine to trust your authority

Sign a certificate for a person

Log in and check

Add conditions: only from one IP