La façon habituelle d'entrer dans une machine Linux dans le cloud est une clé SSH : un fichier sur votre ordinateur et sa moitié publique copiée sur la machine. Ça fonctionne, mais regardez ce que cela implique dès qu'il y a plus d'une personne et plus d'une machine : chaque clé doit être copiée sur chaque machine, chaque personne qui part laisse sa clé sur toutes jusqu'à ce que quelqu'un pense à la supprimer, et une clé perdue vaut pour toujours. Savez-vous aujourd'hui, avec certitude, combien de clés peuvent entrer sur votre serveur de production et à qui elles appartiennent ?

Les certificats SSH résolvent exactement cela. C'est la même technologie que Simplio utilise pour sa clé de rechange et la même que Lightsail utilise pour sa console web, et il n'est pas nécessaire d'être expert pour la comprendre.

Avant de commencer : ce que signifie chaque chose

Clé SSH: Une paire de fichiers : la privée (reste sur votre ordinateur, ne se partage jamais) et la publique (se copie sur la machine, dans le fichier authorized_keys de l'utilisateur). La machine laisse entrer qui prouve détenir la privée.
Certificat SSH: Votre clé publique, signée par une autorité, avec un nom, une date d'expiration et une liste d'utilisateurs pour lesquels elle vaut. La machine n'a pas besoin de connaître votre clé : il lui suffit de faire confiance à qui l'a signée.
Autorité de certification (CA): Une autre clé SSH, mais qui ne sert qu'à signer. Sa publique se copie sur les machines une fois ; sa privée se garde très soigneusement, parce que qui la détient peut signer des certificats.
Principal: Le nom d'utilisateur pour lequel le certificat vaut. Un certificat pour « ubuntu » ne sert pas à entrer comme « root ».
Validité: À partir de quand et jusqu'à quand le certificat vaut. Cela peut être un an ou cinq minutes.
authorized_keys: Le fichier, dans le dossier .ssh de chaque utilisateur de la machine, avec les clés publiques qui peuvent entrer sous son nom. Il admet aussi une ligne spéciale qui dit « accepte les certificats signés par cette autorité ».

Pas à pas

Comprenez la différence avec un exemple

Avec des clés : pour qu'Ana entre sur dix machines, sa clé publique est copiée dans dix fichiers. Quand Ana s'en va, il faut la supprimer à dix endroits, et si on en oublie un, Ana (ou qui a son portable) continue d'entrer. Avec des certificats : les dix machines font confiance à une autorité. On signe à Ana un certificat valable jusqu'à vendredi. Samedi, Ana n'entre plus nulle part, sans toucher à une seule machine. Et si on lui en signe un nouveau chaque matin, il n'y a jamais rien à révoquer.
Créez une autorité (une fois, sur votre ordinateur)
```
ssh-keygen -t ed25519 -f mi_ca -C "CA de mi empresa"
```
Deux fichiers en sortent. mi_ca est la privée : gardez-la dans un gestionnaire de mots de passe ou sur un disque chiffré, et ne la copiez jamais sur aucune machine. mi_ca.pub est celle qui ira sur les machines.
Dites à la machine de faire confiance à votre autorité

Il y a deux façons. La globale, dans /etc/ssh/sshd_config, vaut pour tous les utilisateurs :
```
TrustedUserCAKeys /etc/ssh/mi_ca.pub
```
Et la locale, sans toucher à la configuration de SSH : une ligne dans l'authorized_keys de l'utilisateur, qui ne vaut que pour lui :
```
cert-authority,principals="ubuntu" ssh-ed25519 AAAA... CA de mi empresa
```
La seconde est celle qui convient dans Lightsail, parce que Lightsail utilise déjà TrustedUserCAKeys pour sa propre console web et qu'il ne peut y en avoir qu'une. Rechargez SSH (sudo systemctl reload ssh) et la machine accepte désormais vos certificats.
Signez un certificat pour une personne

La personne vous envoie sa clé publique (id_ed25519.pub). Vous la signez, en indiquant pour quel utilisateur elle vaut et combien de temps :
```
ssh-keygen -s mi_ca -I "ana-portatil" -n ubuntu -V +1w id_ed25519.pub
```
Il en sort id_ed25519-cert.pub : vous le lui rendez et elle le place à côté de sa clé. -I est un nom pour le journal de la machine (ainsi vous savez qui est entré), -n l'utilisateur autorisé et -V +1w une semaine de validité. Vous pouvez mettre +5m et vous aurez un certificat de cinq minutes.
Entrez et vérifiez
```
ssh -i id_ed25519 ubuntu@IP.DE.LA.MAQUINA
```
SSH utilise le certificat tout seul. Sur la machine, sudo journalctl -u ssh | grep ana-portatil vous montre l'entrée avec le nom que vous avez mis à la signature. Une fois la validité passée, la même commande répond « Permission denied » sans que personne n'ait touché à rien.
Ajoutez des conditions : seulement depuis une IP

À la signature, vous pouvez ajouter des restrictions. La plus utile : que le certificat ne vaille que depuis une adresse précise.
```
ssh-keygen -s mi_ca -I "copias-nocturnas" -n backup -V +1d -O source-address=203.0.113.10 id_backup.pub
```
Si ce certificat fuite, il ne sert à rien depuis toute autre IP. C'est ce que fait la clé de rechange de Simplio : des certificats de cinq minutes, pour un seul utilisateur, valables uniquement depuis l'IP du serveur de Simplio.

Ce qui peut mal tourner

« Permission denied » alors que le certificat est correct

Le plus courant : le principal ne correspond pas (vous avez signé pour « ubuntu » et vous entrez comme « admin »), la validité est passée, ou l'heure de la machine est fausse (les certificats dépendent de l'horloge ; vérifiez avec date et activez la synchronisation de l'heure).

La machine avait déjà TrustedUserCAKeys

C'est le cas de Lightsail et de certaines images. Ne le changez pas : vous perdriez la console web. Utilisez la ligne cert-authority dans l'authorized_keys de l'utilisateur, qui cohabite sans problème.

J'ai perdu la privée de la CA

Vous ne pouvez plus signer de certificats, mais ceux déjà signés restent valables jusqu'à leur expiration. Créez une nouvelle CA et remplacez la publique sur les machines pendant que les anciens certificats entrent encore. C'est pour cela que les validités courtes sont un avantage : le changement se termine tout seul.

On m'a volé la privée de la CA

Qui la détient peut signer des certificats pour toutes vos machines. Remplacez la publique sur toutes au plus vite ; si vous avez utilisé source-address, le voleur doit en plus se trouver à cette IP. C'est la raison de la garder hors des machines et hors du courrier.

Dans Simplio

Simplio utilise des certificats SSH en coulisses pour que vous n'ayez pas à le faire. Le terminal dans le navigateur entre avec la clé temporaire qu'AWS délivre pour chaque session, sans que personne ne reçoive de fichier. Et la clé de rechange est exactement ce qu'explique ce guide, poussé à l'extrême : un utilisateur sans mot de passe sur la machine, qui n'accepte que des certificats signés par Simplio, de cinq minutes, pour cet utilisateur et seulement depuis l'IP de Simplio, avec votre code de double authentification à chaque utilisation. Vous laissez la clé avec un bouton et Simplio vérifie chaque jour qu'elle ouvre toujours. Comment fonctionne la clé de rechange.

La même chose, dans AWS et dans Simplio

	Dans la console AWS	Dans Simplio
Donner accès à une personne	Copier sa clé sur chaque machine	Lui accorder la machine dans Simplio : le terminal du navigateur utilise la clé temporaire que donne AWS
Le lui retirer	Supprimer sa clé de chaque machine, sans en oublier une	Lui retirer la machine dans Simplio
Accès de secours	Créer votre CA, distribuer la publique, signer à la main un certificat quand il le faut	Clé de rechange : certificat de cinq minutes, signé par Simplio, seulement depuis son IP, avec double authentification
Savoir qui est entré	Lire le journal SSH de chaque machine	Journal d'activité de Simplio : qui, quelle machine, quand, depuis quelle IP

Essayer gratuitement 15 jours Voir comment ça marche

Certificats SSH expliqués de zéro : entrer dans vos machines sans distribuer de clés

Avant de commencer : ce que signifie chaque chose

Pas à pas

Comprenez la différence avec un exemple

Créez une autorité (une fois, sur votre ordinateur)

Dites à la machine de faire confiance à votre autorité

Signez un certificat pour une personne

Entrez et vérifiez

Ajoutez des conditions : seulement depuis une IP