| Les deux révisions précédentesRévision précédenteProchaine révision | Révision précédente |
| tuto:ssh-certificat [2024/04/16 17:55] – Thomas | tuto:ssh-certificat [2024/04/29 10:01] (Version actuelle) – Thomas |
|---|
| ===== Clés SSH et certificats ===== | ===== Clés SSH et certificats ===== |
| |
| Sans clés signées, on doit distribuer sa clé publique à tous les users distants qui vont chacun·e l'intégrer dans son ''~/.ssh/authorized_keys''. Si nous décidons de changer de clé, il faut re-distribuer sa nouvelle clé partout où cela est nécessaire. Enfin lors de la 1ère connexion à un serveur, celui-ci nous envoie sa clé que nous devons accepter car non connue. De la même manière, si cette clé change ou si nous nous y connectons en utilisant un nom différent, il faudra à nouveau accepter la clé. | Sans clés signées, on doit distribuer sa clé publique à tous les users distants qui vont chacun·e l'intégrer dans son ''~/.ssh/authorized_keys''. Si nous décidons de changer de clé, il faut re-distribuer sa nouvelle clé partout où cela est nécessaire. Enfin lors de la 1ère connexion à un serveur, celui-ci nous envoie sa clé que nous devons accepter car non connue. De la même manière, si cette clé change ou si nous nous y connectons en utilisant un nom différent, il faudra à nouveau accepter la clé.\\ |
| La clé user envoyée peut être soumise à des restrictions précisées dans ''~/.ssh/authorized_keys'', par exemple ''no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding''. | La clé user envoyée peut être soumise à des restrictions précisées dans ''~/.ssh/authorized_keys'', par exemple ''no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding''. |
| |
| Avec des certificats (signature de la clé), seule l'autorité qui signe les clés des users doit être communiquée aux différents serveurs. De la même manière, seule la clé qui signe les clés des serveurs doit être communiquée globalement aux clients. Toutes les clés signées par ces autorités seront acceptées (à certaines conditions). Ainsi il est possible de changer sa clé user ou du serveur sans avoir à la communiquer. Il suffit juste de la signer. | Avec des certificats (signature de la clé), seule la clé publique de l'autorité qui signe les clés des users doit être communiquée aux différents serveurs. De la même manière, seule la clé publique de l'autorité qui signe les clés des serveurs doit être communiquée globalement aux clients. Toutes les clés signées par ces autorités seront acceptées (à certaines conditions). Ainsi il est possible de changer sa clé user ou du serveur sans avoir à la communiquer. Il suffit juste de la signer.\\ |
| Les restrictions citées ci-dessus sont intégrées dans le certificat. Un certificat peut aussi avoir une date de validité et un numéro de série. | Les restrictions citées ci-dessus sont intégrées dans le certificat. Un certificat peut aussi avoir une date de validité et un numéro de série. |
| |
| |
| <note>On ne va créer qu'une seule fois ces autorités pour tous les serveurs sshd et tous les users.</note> | <note>On ne va créer qu'une seule fois ces autorités pour tous les serveurs sshd et tous les users.</note> |
| | |
| | <note warning>Conserver les clés privées de ces autorités en lieu sûr. Et surtout assurez-vous que vous pouvez les utiliser localement.\\ |
| | Si vous les stocker à distance et que vous ne pouvez plus accéder au serveur en question car votre certificat a expiré, vous serez dans le… Personnellement je stocke mes clés dans mon fichier keepass.</note> |
| |
| === Génération des clés === | === Génération des clés === |
| * -I <hostservername> : c'est le nom que l'on verra dans les logs, je préfère que l'on voit le nom du hostname mais on peut mettre n'importe quoi. | * -I <hostservername> : c'est le nom que l'on verra dans les logs, je préfère que l'on voit le nom du hostname mais on peut mettre n'importe quoi. |
| * -n <hostservername> : ce sont les noms autorisés pour se connecter au serveur, on peut mettre plusieurs noms séparés par une virgule. Exemple : "''myhost.example.org,myhost''". | * -n <hostservername> : ce sont les noms autorisés pour se connecter au serveur, on peut mettre plusieurs noms séparés par une virgule. Exemple : "''myhost.example.org,myhost''". |
| * -V '+52w' : le certificat sera valide 52 semaines. Si vide, il n'expire jamais. | * -V '+52w' : le certificat sera valide 52 semaines. Sans cette option, le certificat n'expire pas. |
| * -z 0001 : numéro de série du certificat (facultatif). Il permet de vérifier si un certificat obsolète est utilisé. | * -z 0001 : numéro de série du certificat (facultatif). Il permet de vérifier si un certificat obsolète est utilisé. |
| |
| |
| === Vérifier le certificat === | === Vérifier le certificat === |
| <code>ssh-keygen -Lf id_ed25519-cert.pub</code> | <code>ssh-keygen -Lf id_ed25519-cert.pub |
| | id_ed25519-cert.pub: |
| | Type: ssh-ed25519-cert-v01@openssh.com user certificate |
| | Public key: ED25519-CERT SHA256:UAsTjJVR6X5Os9jl8u9ERWyrXM16Emi4P4wzDSyd9m7 |
| | Signing CA: ED25519 SHA256:PuFWoaE75fHFOz+RVxHXpAVRfqv1WX9J7UaDwAMaKBH (using ssh-ed25519) |
| | Key ID: "user1@mydomain.com" |
| | Serial: 1 |
| | Valid: from 2024-04-17T08:13:00 to 2025-04-16T08:14:43 |
| | Principals: |
| | user1 |
| | user2 |
| | user3 |
| | Critical Options: (none) |
| | Extensions: |
| | permit-X11-forwarding |
| | permit-agent-forwarding |
| | permit-port-forwarding |
| | permit-pty |
| | permit-user-rc |
| | </code> |
| |
| === Intégrer les autorités sur les serveurs === | === Intégrer l'autorité des clés users sur les serveurs === |
| Sur chaque serveur, copiez la clé publique du certificat user : | Sur chaque serveur, copiez la clé publique du certificat user : |
| <code># install -m 644 user_ca.pub /etc/ssh/ssh_user_ca.pub</code> | <code># install -m 644 user_ca.pub /etc/ssh/ssh_user_ca.pub</code> |
| |
| Peuplez le fichier ''known_hosts'' : | |
| <code># echo "@cert-authority * <contenu de host_ca.pub du serveur>" > /etc/ssh/ssh_known_hosts</code> | |
| J'aurais pu mettre ''*.domain.tld'' pour dire que cette clé n'est utile que pour ces domaines. | |
| |
| Ajoutez ces lignes dans ''/etc/ssh/sshd_config'' : | Ajoutez ces lignes dans ''/etc/ssh/sshd_config'' : |
| </code> | </code> |
| Puis redémarrez le serveur sshd. | Puis redémarrez le serveur sshd. |
| | |
| | === Intégrer l'autorité des clés serveurs sur les clients === |
| | |
| | Sur chaque client, peuplez le fichier ''known_hosts'' : |
| | <code># echo "@cert-authority * <contenu de host_ca.pub>" > /etc/ssh/ssh_known_hosts</code> |
| | J'aurais pu mettre ''*.domain.tld'' pour dire que cette clé n'est utile que pour ces domaines. |
| | |
| | |
| |
| Ajoutez ces lignes dans ''/etc/ssh/ssh_config'' : | Ajoutez ces lignes dans ''/etc/ssh/ssh_config'' : |
| </code> | </code> |
| |
| Dorénavant vous n'aurez plus jamais besoin des fichiers ''~/.ssh/known_hosts'' et ''~/.ssh/authorized_keys''. En effet, le fichier ''/etc/ssh/ssh_known_hosts'' contient la clé publique du certificat qui signe les clés des serveurs sshd. Lors d'une 1ère connexion à un serveur, il ne vous sera plus demandée d'accepter (aveuglément) la clé du serveur. | Dorénavant vous n'aurez plus jamais besoin des fichiers ''~/.ssh/known_hosts'' et ''~/.ssh/authorized_keys''. En effet, le fichier ''/etc/ssh/ssh_known_hosts'' contient la clé publique de l'autorité qui signe les clés des serveurs sshd. Lors d'une 1ère connexion à un serveur, il ne vous sera plus demandée d'accepter (aveuglément) la clé du serveur. |
| |
| Le fichier ''/etc/ssh/ssh_user_ca.pub'' vérifie que le certificat envoyé est bien valide avec les options et les users autorisés, ce qui rend osbolète ''~/.ssh/authorized_keys''. | Le fichier ''/etc/ssh/ssh_user_ca.pub'' vérifie que le certificat envoyé est bien valide avec les options et les users autorisés, ce qui rend osbolète ''~/.ssh/authorized_keys''. |
