Authentification basée sur les certificats SSH – Un guide rapide

2020-01-05

Machine-translated — the English original is authoritative.

Au cours de la dernière décennie, nous sommes passés de telnet et des mots de passe en clair à ssh et aux paires de clés chiffrées. Cette décennie, avec l'adoption rapide des clouds publics et des architectures microservices, nous avons besoin d'une solution plus robuste, évolutive et gérable.

SSH et les paires de clés sont excellents pour les petits déploiements, cependant, avec l'introduction des clouds publics et des pipelines de déploiement continu, il devient très difficile de gérer les clés publiques des utilisateurs. Quand avez-vous été la dernière fois à auditer vos fichiers authorised_keys sur l'ensemble de votre parc pour vous assurer que toutes les clés publiques étaient toujours valides ? Ce contractant qui avait besoin d'un accès pour une semaine… qui a pensé à supprimer sa clé ?… et ainsi de suite.

Les grands acteurs du cloud aujourd'hui, comme Netflix et Facebook, nous ont montré comment ils ont relevé ce défi tout en utilisant toujours SSH.

Ils utilisent des certificats signés par une Autorité de Certification (CA) pour fournir à la fois l'Authenticité des Hôtes et des Utilisateurs avec SSH. En tirant parti des certificats, nous obtenons la capacité de créer des identifiants éphémères et à courte durée de vie. Votre équipe pourrait obtenir automatiquement un nouveau certificat signé lorsqu'elle se connecte le matin et celui-ci expirerait après 8 heures. Si le certificat d'un utilisateur est compromis, il peut être révoqué s'il est encore valide.

Aussi, comme vous le verrez ci-dessous, il est beaucoup plus facile de gérer la configuration SSH pour une flotte de serveurs hôtes.

Ce guide est destiné à aider les personnes à comprendre les mécanismes impliqués dans la mise en place d'une authentification ssh basée sur les certificats. Pour les situations de production, une solution basée sur une API serait généralement utilisée, telle que HashiCorp’s Vault – j'en parlerai dans un prochain article de blog.

Serveur Autorité de Certification (CA)	Serveur(s) Hôte(s)	Client(s)
	Configuration du certificat du serveur hôte
C'est le serveur généralement géré par une équipe de sécurité. Les clés privées CA racine sont conservées sur ce serveur et doivent être protégées. Si ces clés sont compromises, il sera nécessaire de Révoquer & Rotation/Recréer TOUS les certificats !!	Il s'agit des serveurs qui sont construits ou reprovisionnés. Le certificat signé par la CA Hôte est utilisé pour prouver l'Authenticité de l'Hôte aux clients. Il est envoyé au client ssh lors de la poignée de main initiale lorsqu'un client ssh tente de se connecter.	L'ordinateur portable ou le serveur utilisateur qui exécute le client ssh. Le certificat signé par la CA Client est utilisé pour prouver l'Authenticité du Client au Serveur Hôte
Étape 1. Créer les clés de signature CA HÔTE : Exemple `ssh-keygen -t rsa -N '' -C HOST-CA -b 4096 -f host-ca`	Étape 2. Générons un nouvel ensemble de clés hôtes ssh RSA avec 4096 bits. Généralement, les clés sont générées par défaut lors de l'installation de openssh-server mais elles utilisent 2048 bits. Vous devez le faire également lors du clonage des VM si vous avez besoin d'une authenticité unique : Exemple `sudo ssh-keygen -N '' -C HOST-KEY -t rsa -b 4096 -h -f /etc/ssh/ssh_host_rsa_key`
Étape 3. Copiez la clé PUBLIQUE, user@target-host:`/etc/ssh/ssh_host_rsa_key.pub`, créée à l'`Étape 2.` sur le serveur hôte vers le serveur CA : Exemple `scp root@192.168.9.200:/etc/ssh/ssh_host_rsa_key.pub .`
Étape 4. Créez le certificat Hôte signé par la CA pour l'hôte cible en utilisant la clé privée CA-HOST, `host-ca`, créée à l'`Étape 1.`, et la clé publique du serveur hôte, `ssh_host_rsa_key.pub`, récupérée à l'`Étape 3` : Exemple `ssh-keygen -s ../host-ca -I dev_host_server -h -V -5m:+52w ssh_host_rsa_key.pub`
Étape 5. Copiez le certificat HÔTE, `ssh_host_rsa_key-cert.pub`, créé à l'`Étape 4.`, sur le serveur hôte : Exemple `scp ssh_host_rsa_key-cert.pub root@192.168.9.200:/etc/ssh/ssh_host_rsa_key-cert.pub`
Étape 6. Supprimez la clé publique hôte désormais obsolète et le certificat hôte du serveur CA : Exemple `rm ssh_host_rsa_key-cert.pub ssh_host_rsa_key.pub`
	Étape 7. Configurez le Serveur Hôte pour utiliser le nouveau fichier de certificat,`/etc/ssh/ssh_host_rsa_key-cert.pub`, dans la configuration du serveur ssh, `/etc/ssh/sshd_config`, en ajoutant la ligne suivante `HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub`. Redémarrez ensuite le service ssh. Exemple `grep -qxF 'HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub' /etc/ssh/sshd_config \|\| echo 'HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub' \| sudo tee -a /etc/ssh/sshd_config` suivi de `sudo systemctl restart ssh`
Étape 8. Capturez le contenu de la clé PUBLIQUE CA-HOST, `host-ca.pub`, car elle sera nécessaire pour configurer les clients ssh. Exemple `cat host-ca.pub`		Étape 9. Nous devons maintenant configurer les clients ssh pour qu'ils puissent valider les Certificats Hôte en utilisant la clé PUBLIQUE CA-HOST, `host-ca.pub` , créée à l'`Étape 1.` en l'ajoutant au `~/.ssh/known_hosts` de chaque utilisateur. Exemple grep -qxF '@cert-authority * ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDFmZo/bkvhmUEjx3erXC+rZ1R3htLHtz0VzZNpgQD2sT2KZLW3yBiKYIKgxICM04MQsVHY1k5y4ek/tgnw05m5KOO5KTHxxKjcBKf2EyvwG0o8vnzo6UgweqXEePigAzSGQfcsGp75tVu3qmeLKXtJOo1WaWmTSNH4Qoq89xRiPslCVDi1i2VEPxJi3+eeFL5WO+nBK9Xt28DaXY4B43sgC1KC6DSRUR2JhlgPGMKP2eTE5+UaEldyPVzdIl2j3tLsaURfr+cZ6ryPEE9phT1bjcOSC3A88NrROZH1FvpZpG6NQPXusTWjre/NIz2TdG44AopbFRKAEpMVFw67AJ6oDWHPTrh2TGh3SQEIIZTdhudZIHnwiSBuKUOqyV65KH/mmy5gr8X2miHbM+qh6ISjqwPN6TjAhUPgkjxtwa7K+tDseBoFsrRIgP65hHAIlEFodHUI8Lu3P5HswH39z8ouEDR+qU54z9JO/E0Mw9YQPk19A6jr7o9/06wqSXfkVmS1VwvyZI90Zqrtg4+lZ3Zq/GLDqpxTlakfEAddOd9Ns01GgeSab4mKDwB6r2VTsunXQ4DDJkzxm9ioJmX7Ctv9J50Hqqcv+kiM8jJHrsB4IIrc0Cc/qb08YAo//i44JTuPxs2+FS2ifDmQA+TK5fJxwUIQJ6KDQ+0wB+T6yeYMJw== HOST-CA' ~/.ssh/known_hosts \|\| echo '@cert-authority * ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDFmZo/bkvhmUEjx3erXC+rZ1R3htLHtz0VzZNpgQD2sT2KZLW3yBiKYIKgxICM04MQsVHY1k5y4ek/tgnw05m5KOO5KTHxxKjcBKf2EyvwG0o8vnzo6UgweqXEePigAzSGQfcsGp75tVu3qmeLKXtJOo1WaWmTSNH4Qoq89xRiPslCVDi1i2VEPxJi3+eeFL5WO+nBK9Xt28DaXY4B43sgC1KC6DSRUR2JhlgPGMKP2eTE5+UaEldyPVzdIl2j3tLsaURfr+cZ6ryPEE9phT1bjcOSC3A88NrROZH1FvpZpG6NQPXusTWjre/NIz2TdG44AopbFRKAEpMVFw67AJ6oDWHPTrh2TGh3SQEIIZTdhudZIHnwiSBuKUOqyV65KH/mmy5gr8X2miHbM+qh6ISjqwPN6TjAhUPgkjxtwa7K+tDseBoFsrRIgP65hHAIlEFodHUI8Lu3P5HswH39z8ouEDR+qU54z9JO/E0Mw9YQPk19A6jr7o9/06wqSXfkVmS1VwvyZI90Zqrtg4+lZ3Zq/GLDqpxTlakfEAddOd9Ns01GgeSab4mKDwB6r2VTsunXQ4DDJkzxm9ioJmX7Ctv9J50Hqqcv+kiM8jJHrsB4IIrc0Cc/qb08YAo//i44JTuPxs2+FS2ifDmQA+TK5fJxwUIQJ6KDQ+0wB+T6yeYMJw== HOST-CA' \| tee -a ~/.ssh/known_hosts
	Configuration du certificat client
Étape 10. Créer les clés de signature CA Client : Exemple `ssh-keygen -t rsa -N '' -C CLIENT-CA -b 4096 -f client-ca`
Étape 11. Copiez la clé publique de signature CA Client, `client-ca.pub`, créée à l'`Étape 10.` vers les serveurs hôtes cibles (PAS les serveurs clients) Exemple `scp client-ca.pub root@host:/etc/ssh/client-ca.pub`	Étape 12. Configurez le Serveur Hôte pour utiliser le nouveau fichier CA Client, `client-ca.pub`, dans la configuration du serveur ssh, `/etc/ssh/sshd_config`, en ajoutant la ligne suivante `TrustedUserCAKeys /etc/ssh/client-ca.pub`. Redémarrez ensuite le service ssh. Exemple `grep -qxF 'TrustedUserCAKeys /etc/ssh/client-ca.pub' /etc/ssh/sshd_config \|\| echo 'TrustedUserCAKeys /etc/ssh/client-ca.pub' \| sudo tee -a /etc/ssh/sshd_config` suivi de `sudo systemctl restart ssh`
Étape 13. Copiez, faxez, envoyez par e-mail ou par tout autre moyen la clé ssh publique du(des) client(s), `/home/someuser/.ssh/id_rsa.pub`, vers le serveur CA et signez la clé comme suit : Exemple `ssh-keygen -s client-ca -I graham-dev -n root,vagrant,graham,pi -V -5:+52w -z 1 ~/.ssh/id_rsa.pub`		Étape 14. Copiez, faxez, envoyez par e-mail ou par tout autre moyen le nouveau certificat ssh du(des) client(s), `id_rsa-cert.pub`, vers les répertoires `/home/someuser/.ssh` des clients et testez comme suit : `ssh -v root@192.168.9.200`

Configuration du certificat du serveur hôte

Étape 1 sur le serveur CA – Créer la clé de signature Hôte


graham@graz-baz:~/.WiP $ ssh-keygen -t rsa -N '' -C HOST-CA -b 4096 -f host-ca
Generating public/private rsa key pair.
Your identification has been saved in host-ca.
Your public key has been saved in host-ca.pub.
The key fingerprint is:
SHA256:uKJqQBCvoukiJ6n0GRX6Me8/VmHUB6bps81ekpUjdJ8 HOST-CA
The keys randomart image is:
+---[RSA 4096]----+
|.. .o. |
|.. .+. . |
|. . . .o ... |
| o . .. .o. . +|
|+ . +. S .o.. E.|
|+. o +. .= + .|
|+o ..... .. = . |
|B.o.o.. o . o |
|B=.o .o.. . |
+----[SHA256]-----+
graham@graz-baz:~/.WiP $ ls -al
total 16
drwx------ 2 graham graham 4096 Jan 3 12:35 .
drwxr-xr-x 19 graham graham 4096 Jan 3 12:14 ..
-rw------- 1 graham graham 3247 Jan 3 12:35 host-ca
-rw-r--r-- 1 graham graham 733 Jan 3 12:35 host-ca.pub
graham@graz-baz:~/.WiP $

Notes :

omettez -N si vous souhaitez inclure une phrase de passe avec la génération de clé
-t le type peut être dsa, rsa, ecdsa ou ed25519. Je choisis rsa car il est largement accepté partout bien que moins sécurisé.
-b taille de clé de 4096 bits pour retarder les attaques par force brute – toutes les chances sont annulées lorsque nous aurons des téléphones mobiles quantiques 😉

Étape 2 sur le(s) serveur(s) hôte(s) cible(s) – Créer une nouvelle paire de clés ssh hôte (facultatif, si les clés existent)


root@redis01:# sudo ssh-keygen -N '' -C HOST-KEY -t rsa -b 4096 -h -f /etc/ssh/ssh_host_rsa_key
Generating public/private rsa key pair.
/etc/ssh/ssh_host_rsa_key already exists.
Overwrite (y/n)? y
Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub.
The key fingerprint is:
SHA256:3lpUNJcP8GDhkHmozrhP4XA99s16AaV0kLI1fysjpEc HOST-KEY
The keys randomart image is:
+---[RSA 4096]----+
| .+O=.. |
| ==*== |
| . *o*.o |
| ...Eo . o|
| .+S O . ..|
| .=o* = =.. |
| .+ + o =. |
| .. o .. |
| .o .. |
+----[SHA256]-----+
root@redis01:~# ls -al /etc/ssh/
total 596
drwxr-xr-x 2 root root 4096 Jan 2 22:51 .
drwxr-xr-x 89 root root 4096 Jan 2 23:57 ..
-rw-r--r-- 1 root root 384 Jan 2 22:51 hashistack-ca.pub
-rw-r--r-- 1 root root 553122 Mar 4 2019 moduli
-rw-r--r-- 1 root root 1580 Mar 4 2019 ssh_config
-rw-r--r-- 1 root root 3362 Jan 2 22:51 sshd_config
-rw------- 1 root root 227 Jan 2 22:45 ssh_host_ecdsa_key
-rw-r--r-- 1 root root 1083 Jan 2 22:51 ssh_host_ecdsa_key-cert.pub
-rw-r--r-- 1 root root 174 Jan 2 22:45 ssh_host_ecdsa_key.pub
-rw------- 1 root root 399 Jan 2 22:45 ssh_host_ed25519_key
-rw-r--r-- 1 root root 94 Jan 2 22:45 ssh_host_ed25519_key.pub
-rw------- 1 root root 3243 Jan 3 13:38 ssh_host_rsa_key
-rw-r--r-- 1 root root 734 Jan 3 13:38 ssh_host_rsa_key.pub
-rw-r--r-- 1 root root 338 Jan 2 22:45 ssh_import_id
root@redis01:~# date
Fri Jan 3 13:38:52 UTC 2020
root@redis01:~#

Notes :

Pour mon environnement de développement, j'utilise les mêmes clés hôtes et certificats sur tous les serveurs hôtes (clonés à partir du même modèle). Ce n'est peut-être pas une bonne idée pour la production, mais c'est mieux que ce que j'ai aujourd'hui.
HashiCorp's Vault fournit une solution de signature CA PKI basée sur une API élégante lorsque vous devez mettre à l'échelle et maintenir la gestion des certificats et l'auditabilité. Cela sera mis en œuvre prochainement…

Étape 3 sur le serveur CA – Copier les clés publiques hôte(s)


graham@graz-baz:~/.WiP $ mkdir tmp-keys
graham@graz-baz:~/.WiP $ cd tmp-keys/
graham@graz-baz:~/.WiP/tmp-keys $ scp root@192.168.9.200:/etc/ssh/ssh_host_rsa_key.pub .
ssh_host_rsa_key.pub 100% 734 416.9KB/s 00:00
graham@graz-baz:~/.WiP/tmp-keys $ ls -al
total 12
drwxr-xr-x 2 graham graham 4096 Jan 3 13:44 .
drwx------ 3 graham graham 4096 Jan 3 13:42 ..
-rw-r--r-- 1 graham graham 734 Jan 3 13:44 ssh_host_rsa_key.pub
graham@graz-baz:~/.WiP/tmp-keys $

Étape 4 sur le serveur CA – Créer un certificat ssh hôte signé


graham@graz-baz:~/.WiP/tmp-keys $ ssh-keygen -s ../host-ca -I dev_host_server -h -V -5m:+52w ssh_host_rsa_key.pub
Signed host key ssh_host_rsa_key-cert.pub: id "dev_host_server" serial 0 valid from 2020-01-03T16:51:35 to 2021-01-01T16:56:35
...
graham@graz-baz:~/.WiP/tmp-keys $ date
Fri 3 Jan 14:15:47 GMT 2020
graham@graz-baz:~/.WiP/tmp-keys $ ls -al
total 16
drwxr-xr-x 2 graham graham 4096 Jan 3 14:15 .
drwx------ 3 graham graham 4096 Jan 3 13:42 ..
-rw-r--r-- 1 graham graham 2359 Jan 3 14:15 ssh_host_rsa_key-cert.pub
-rw-r--r-- 1 graham graham 734 Jan 3 13:44 ssh_host_rsa_key.pub
graham@graz-baz:~/.WiP/tmp-keys $

Étape 5 sur le serveur CA – copier le nouveau certificat ssh hôte sur l'hôte

Sur le serveur CA


graham@graz-baz:~/.WiP/tmp-keys $ scp ssh_host_rsa_key-cert.pub root@192.168.9.200:/etc/ssh/ssh_host_rsa_key-cert.pub
ssh_host_rsa_key-cert.pub 100% 2359 973.0KB/s 00:00
graham@graz-baz:~/.WiP/tmp-keys $

Sur le Serveur Hôte


root@redis01:~# ls -al /etc/ssh/
total 600
drwxr-xr-x 2 root root 4096 Jan 3 14:38 .
drwxr-xr-x 89 root root 4096 Jan 2 23:57 ..
-rw-r--r-- 1 root root 384 Jan 2 22:51 hashistack-ca.pub
-rw-r--r-- 1 root root 553122 Mar 4 2019 moduli
-rw-r--r-- 1 root root 1580 Mar 4 2019 ssh_config
-rw-r--r-- 1 root root 3362 Jan 2 22:51 sshd_config
-rw------- 1 root root 227 Jan 2 22:45 ssh_host_ecdsa_key
-rw-r--r-- 1 root root 1083 Jan 2 22:51 ssh_host_ecdsa_key-cert.pub
-rw-r--r-- 1 root root 174 Jan 2 22:45 ssh_host_ecdsa_key.pub
-rw------- 1 root root 399 Jan 2 22:45 ssh_host_ed25519_key
-rw-r--r-- 1 root root 94 Jan 2 22:45 ssh_host_ed25519_key.pub
-rw------- 1 root root 3243 Jan 3 13:38 ssh_host_rsa_key
-rw-r--r-- 1 root root 2359 Jan 3 14:38 ssh_host_rsa_key-cert.pub
-rw-r--r-- 1 root root 734 Jan 3 13:38 ssh_host_rsa_key.pub
-rw-r--r-- 1 root root 338 Jan 2 22:45 ssh_import_id
root@redis01:~#

Étape 6 sur le serveur CA – faire le ménage


graham@graz-baz:~/.WiP/tmp-keys $ ls -al
total 16
drwxr-xr-x 2 graham graham 4096 Jan 3 14:15 .
drwx------ 3 graham graham 4096 Jan 3 13:42 ..
-rw-r--r-- 1 graham graham 2359 Jan 3 14:15 ssh_host_rsa_key-cert.pub
-rw-r--r-- 1 graham graham 734 Jan 3 13:44 ssh_host_rsa_key.pub
graham@graz-baz:~/.WiP/tmp-keys $ rm ssh_host_rsa_key.pub ssh_host_rsa_key-cert.pub
graham@graz-baz:~/.WiP/tmp-keys $ ls -al
total 8
drwxr-xr-x 2 graham graham 4096 Jan 3 15:41 .
drwx------ 3 graham graham 4096 Jan 3 13:42 ..
graham@graz-baz:~/.WiP/tmp-keys $

Étape 7 sur le Serveur Hôte – Configurer ssh pour utiliser le nouveau certificat hôte


root@redis01:~# grep -qxF 'HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub' /etc/ssh/sshd_config || echo 'HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub' | sudo tee -a /etc/ssh/sshd_config
HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub
root@redis01:~# grep HostCertificate /etc/ssh/sshd_config
HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub
root@redis01:~# sudo systemctl restart ssh
root@redis01:~# sudo systemctl status ssh
● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2020-01-03 15:33:29 UTC; 6s ago
Process: 31111 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
Main PID: 31112 (sshd)
Tasks: 1 (limit: 1112)
CGroup: /system.slice/ssh.service
└─31112 /usr/sbin/sshd -D

Jan 03 15:33:29 redis01 systemd[1]: Stopping OpenBSD Secure Shell server...
Jan 03 15:33:29 redis01 systemd[1]: Stopped OpenBSD Secure Shell server.
Jan 03 15:33:29 redis01 systemd[1]: Starting OpenBSD Secure Shell server...
Jan 03 15:33:29 redis01 sshd[31112]: Server listening on 0.0.0.0 port 22.
Jan 03 15:33:29 redis01 sshd[31112]: Server listening on :: port 22.
Jan 03 15:33:29 redis01 systemd[1]: Started OpenBSD Secure Shell server.
root@redis01:~#

Étape 8 sur le serveur CA – Capturer les détails de la clé publique CA Hôte


graham@graz-baz:~/.WiP $ ls
host-ca host-ca.pub tmp-keys
graham@graz-baz:~/.WiP $ cat host-ca.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDFmZo/bkvhmUEjx3erXC+rZ1R3htLHtz0VzZNpgQD2sT2KZLW3yBiKYIKgxICM04MQsVHY1k5y4ek/tgnw05m5KOO5KTHxxKjcBKf2EyvwG0o8vnzo6UgweqXEePigAzSGQfcsGp75tVu3qmeLKXtJOo1WaWmTSNH4Qoq89xRiPslCVDi1i2VEPxJi3+eeFL5WO+nBK9Xt28DaXY4B43sgC1KC6DSRUR2JhlgPGMKP2eTE5+UaEldyPVzdIl2j3tLsaURfr+cZ6ryPEE9phT1bjcOSC3A88NrROZH1FvpZpG6NQPXusTWjre/NIz2TdG44AopbFRKAEpMVFw67AJ6oDWHPTrh2TGh3SQEIIZTdhudZIHnwiSBuKUOqyV65KH/mmy5gr8X2miHbM+qh6ISjqwPN6TjAhUPgkjxtwa7K+tDseBoFsrRIgP65hHAIlEFodHUI8Lu3P5HswH39z8ouEDR+qU54z9JO/E0Mw9YQPk19A6jr7o9/06wqSXfkVmS1VwvyZI90Zqrtg4+lZ3Zq/GLDqpxTlakfEAddOd9Ns01GgeSab4mKDwB6r2VTsunXQ4DDJkzxm9ioJmX7Ctv9J50Hqqcv+kiM8jJHrsB4IIrc0Cc/qb08YAo//i44JTuPxs2+FS2ifDmQA+TK5fJxwUIQJ6KDQ+0wB+T6yeYMJw== HOST-CA

Étape 9 sur le(s) Client(s) – Configurer la clé publique CA Hôte

Avant l'ajout de la clé publique host-ca :


graham@graz-baz:~/web_page_counter/terraform/VMware/Dev/Monolith $ ssh -v root@192.168.9.200
OpenSSH_7.4p1 Raspbian-10+deb9u7, OpenSSL 1.0.2u 20 Dec 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.9.200 [192.168.9.200] port 22.
debug1: Connection established.
debug1: identity file /home/graham/.ssh/id_rsa type 1
debug1: identity file /home/graham/.ssh/id_rsa-cert type 5
debug1: key_load_public: No such file or directory
debug1: identity file /home/graham/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/graham/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/graham/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/graham/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/graham/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/graham/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Raspbian-10+deb9u7
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
debug1: match: OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.9.200:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-rsa-cert-v01@openssh.com
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: compression: none

debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: compression: none

debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

debug1: Server host certificate: ssh-rsa-cert-v01@openssh.com SHA256:3lpUNJcP8GDhkHmozrhP4XA99s16AaV0kLI1fysjpEc, serial 0 ID "dev_host_server" CA ssh-rsa SHA256:uKJqQBCvoukiJ6n0GRX6Me8/VmHUB6bps81ekpUjdJ8 valid from 2020-01-03T14:10:32 to 2021-01-01T14:15:32

debug1: No matching CA found. Retry with plain key

The authenticity of host '192.168.9.200 (192.168.9.200)' cant be established.

RSA key fingerprint is SHA256:3lpUNJcP8GDhkHmozrhP4XA99s16AaV0kLI1fysjpEc.

Are you sure you want to continue connecting (yes/no)?

Ajout de la clé publique host-ca :


graham@graz-baz:~/web_page_counter/terraform/VMware/Dev/Monolith $ grep -qxF 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDFmZo/bkvhmUEjx3erXC+rZ1R3htLHtz0VzZNpgQD2sT2KZLW3yBiKYIKgxICM04MQsVHY1k5y4ek/tgnw05m5KOO5KTHxxKjcBKf2EyvwG0o8vnzo6UgweqXEePigAzSGQfcsGp75tVu3qmeLKXtJOo1WaWmTSNH4Qoq89xRiPslCVDi1i2VEPxJi3+eeFL5WO+nBK9Xt28DaXY4B43sgC1KC6DSRUR2JhlgPGMKP2eTE5+UaEldyPVzdIl2j3tLsaURfr+cZ6ryPEE9phT1bjcOSC3A88NrROZH1FvpZpG6NQPXusTWjre/NIz2TdG44AopbFRKAEpMVFw67AJ6oDWHPTrh2TGh3SQEIIZTdhudZIHnwiSBuKUOqyV65KH/mmy5gr8X2miHbM+qh6ISjqwPN6TjAhUPgkjxtwa7K+tDseBoFsrRIgP65hHAIlEFodHUI8Lu3P5HswH39z8ouEDR+qU54z9JO/E0Mw9YQPk19A6jr7o9/06wqSXfkVmS1VwvyZI90Zqrtg4+lZ3Zq/GLDqpxTlakfEAddOd9Ns01GgeSab4mKDwB6r2VTsunXQ4DDJkzxm9ioJmX7Ctv9J50Hqqcv+kiM8jJHrsB4IIrc0Cc/qb08YAo//i44JTuPxs2+FS2ifDmQA+TK5fJxwUIQJ6KDQ+0wB+T6yeYMJw== HOST-CA' ~/.ssh/known_hosts || echo '@cert-authority * ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDFmZo/bkvhmUEjx3erXC+rZ1R3htLHtz0VzZNpgQD2sT2KZLW3yBiKYIKgxICM04MQsVHY1k5y4ek/tgnw05m5KOO5KTHxxKjcBKf2EyvwG0o8vnzo6UgweqXEePigAzSGQfcsGp75tVu3qmeLKXtJOo1WaWmTSNH4Qoq89xRiPslCVDi1i2VEPxJi3+eeFL5WO+nBK9Xt28DaXY4B43sgC1KC6DSRUR2JhlgPGMKP2eTE5+UaEldyPVzdIl2j3tLsaURfr+cZ6ryPEE9phT1bjcOSC3A88NrROZH1FvpZpG6NQPXusTWjre/NIz2TdG44AopbFRKAEpMVFw67AJ6oDWHPTrh2TGh3SQEIIZTdhudZIHnwiSBuKUOqyV65KH/mmy5gr8X2miHbM+qh6ISjqwPN6TjAhUPgkjxtwa7K+tDseBoFsrRIgP65hHAIlEFodHUI8Lu3P5HswH39z8ouEDR+qU54z9JO/E0Mw9YQPk19A6jr7o9/06wqSXfkVmS1VwvyZI90Zqrtg4+lZ3Zq/GLDqpxTlakfEAddOd9Ns01GgeSab4mKDwB6r2VTsunXQ4DDJkzxm9ioJmX7Ctv9J50Hqqcv+kiM8jJHrsB4IIrc0Cc/qb08YAo//i44JTuPxs2+FS2ifDmQA+TK5fJxwUIQJ6KDQ+0wB+T6yeYMJw== HOST-CA' | tee -a ~/.ssh/known_hosts
@cert-authority * ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDFmZo/bkvhmUEjx3erXC+rZ1R3htLHtz0VzZNpgQD2sT2KZLW3yBiKYIKgxICM04MQsVHY1k5y4ek/tgnw05m5KOO5KTHxxKjcBKf2EyvwG0o8vnzo6UgweqXEePigAzSGQfcsGp75tVu3qmeLKXtJOo1WaWmTSNH4Qoq89xRiPslCVDi1i2VEPxJi3+eeFL5WO+nBK9Xt28DaXY4B43sgC1KC6DSRUR2JhlgPGMKP2eTE5+UaEldyPVzdIl2j3tLsaURfr+cZ6ryPEE9phT1bjcOSC3A88NrROZH1FvpZpG6NQPXusTWjre/NIz2TdG44AopbFRKAEpMVFw67AJ6oDWHPTrh2TGh3SQEIIZTdhudZIHnwiSBuKUOqyV65KH/mmy5gr8X2miHbM+qh6ISjqwPN6TjAhUPgkjxtwa7K+tDseBoFsrRIgP65hHAIlEFodHUI8Lu3P5HswH39z8ouEDR+qU54z9JO/E0Mw9YQPk19A6jr7o9/06wqSXfkVmS1VwvyZI90Zqrtg4+lZ3Zq/GLDqpxTlakfEAddOd9Ns01GgeSab4mKDwB6r2VTsunXQ4DDJkzxm9ioJmX7Ctv9J50Hqqcv+kiM8jJHrsB4IIrc0Cc/qb08YAo//i44JTuPxs2+FS2ifDmQA+TK5fJxwUIQJ6KDQ+0wB+T6yeYMJw== HOST-CA
graham@graz-baz:~/web_page_counter/terraform/VMware/Dev/Monolith $ cat ~/.ssh/known_hosts
@cert-authority * ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDFmZo/bkvhmUEjx3erXC+rZ1R3htLHtz0VzZNpgQD2sT2KZLW3yBiKYIKgxICM04MQsVHY1k5y4ek/tgnw05m5KOO5KTHxxKjcBKf2EyvwG0o8vnzo6UgweqXEePigAzSGQfcsGp75tVu3qmeLKXtJOo1WaWmTSNH4Qoq89xRiPslCVDi1i2VEPxJi3+eeFL5WO+nBK9Xt28DaXY4B43sgC1KC6DSRUR2JhlgPGMKP2eTE5+UaEldyPVzdIl2j3tLsaURfr+cZ6ryPEE9phT1bjcOSC3A88NrROZH1FvpZpG6NQPXusTWjre/NIz2TdG44AopbFRKAEpMVFw67AJ6oDWHPTrh2TGh3SQEIIZTdhudZIHnwiSBuKUOqyV65KH/mmy5gr8X2miHbM+qh6ISjqwPN6TjAhUPgkjxtwa7K+tDseBoFsrRIgP65hHAIlEFodHUI8Lu3P5HswH39z8ouEDR+qU54z9JO/E0Mw9YQPk19A6jr7o9/06wqSXfkVmS1VwvyZI90Zqrtg4+lZ3Zq/GLDqpxTlakfEAddOd9Ns01GgeSab4mKDwB6r2VTsunXQ4DDJkzxm9ioJmX7Ctv9J50Hqqcv+kiM8jJHrsB4IIrc0Cc/qb08YAo//i44JTuPxs2+FS2ifDmQA+TK5fJxwUIQJ6KDQ+0wB+T6yeYMJw== HOST-CA
@cert-authority * ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDFmZo/bkvhmUEjx3erXC+rZ1R3htLHtz0VzZNpgQD2sT2KZLW3yBiKYIKgxICM04MQsVHY1k5y4ek/tgnw05m5KOO5KTHxxKjcBKf2EyvwG0o8vnzo6UgweqXEePigAzSGQfcsGp75tVu3qmeLKXtJOo1WaWmTSNH4Qoq89xRiPslCVDi1i2VEPxJi3+eeFL5WO+nBK9Xt28DaXY4B43sgC1KC6DSRUR2JhlgPGMKP2eTE5+UaEldyPVzdIl2j3tLsaURfr+cZ6ryPEE9phT1bjcOSC3A88NrROZH1FvpZpG6NQPXusTWjre/NIz2TdG44AopbFRKAEpMVFw67AJ6oDWHPTrh2TGh3SQEIIZTdhudZIHnwiSBuKUOqyV65KH/mmy5gr8X2miHbM+qh6ISjqwPN6TjAhUPgkjxtwa7K+tDseBoFsrRIgP65hHAIlEFodHUI8Lu3P5HswH39z8ouEDR+qU54z9JO/E0Mw9YQPk19A6jr7o9/06wqSXfkVmS1VwvyZI90Zqrtg4+lZ3Zq/GLDqpxTlakfEAddOd9Ns01GgeSab4mKDwB6r2VTsunXQ4DDJkzxm9ioJmX7Ctv9J50Hqqcv+kiM8jJHrsB4IIrc0Cc/qb08YAo//i44JTuPxs2+FS2ifDmQA+TK5fJxwUIQJ6KDQ+0wB+T6yeYMJw== HOST-CA
graham@graz-baz:~/web_page_counter/terraform/VMware/Dev/Monolith $

Et le grand test…


graham@graz-baz:~/web_page_counter/terraform/VMware/Dev/Monolith $ ssh -v root@192.168.9.200
OpenSSH_7.4p1 Raspbian-10+deb9u7, OpenSSL 1.0.2u 20 Dec 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.9.200 [192.168.9.200] port 22.
debug1: Connection established.
debug1: identity file /home/graham/.ssh/id_rsa type 1
debug1: identity file /home/graham/.ssh/id_rsa-cert type 5
debug1: key_load_public: No such file or directory
debug1: identity file /home/graham/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/graham/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/graham/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/graham/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/graham/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/graham/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Raspbian-10+deb9u7
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
debug1: match: OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.9.200:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-rsa-cert-v01@openssh.com
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: compression: none

debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: compression: none

debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

debug1: Server host certificate: ssh-rsa-cert-v01@openssh.com SHA256:3lpUNJcP8GDhkHmozrhP4XA99s16AaV0kLI1fysjpEc, serial 0 ID "dev_host_server" CA ssh-rsa SHA256:uKJqQBCvoukiJ6n0GRX6Me8/VmHUB6bps81ekpUjdJ8 valid from 2020-01-03T16:51:35 to 2021-01-01T16:56:35

debug1: Host '192.168.9.200' is known and matches the RSA-CERT host certificate.

debug1: Found CA key in /home/graham/.ssh/known_hosts:1

debug1: rekey after 134217728 blocks

Configuration du certificat client

Étape 10 sur le serveur CA – Créer une clé de signature CA client


$ ssh-keygen -t rsa -N '' -C CLIENT-CA -b 4096 -f client-ca
Generating public/private rsa key pair.
Your identification has been saved in client-ca.
Your public key has been saved in client-ca.pub.
The key fingerprint is:
SHA256:bDOWewefRFdvXDGQixnVgVjnHHPSjOLeO381BiAPF/Q CLIENT-CA
The keys randomart image is:
+---[RSA 4096]----+
| .o=+*@*|
| o =oo==X|
| =.*Eoo+|
| . . =.+ . |
| S ..... |
| o + +...o.|
| . . + ..o|
| . . o .|
| oo|
+----[SHA256]-----+
~/hashistack-ca
$ ls -al
total 48
drwx------ 8 grazzer staff 256 3 Jan 21:30 .
drwxr-xr-x+ 106 grazzer staff 3392 3 Jan 17:21 ..
-rw-r--r--@ 1 grazzer staff 6148 3 Jan 21:00 .DS_Store
-rw------- 1 grazzer staff 3369 3 Jan 21:30 client-ca
-rw------- 1 grazzer staff 735 3 Jan 21:30 client-ca.pub
-rw------- 1 grazzer staff 3247 3 Jan 20:46 host-ca
-rw------- 1 grazzer staff 733 3 Jan 20:46 host-ca.pub
drwx------ 5 grazzer staff 160 3 Jan 20:50 tmp-keys
~/hashistack-ca
$

Étape 11 sur le serveur CA – Copier la clé publique de signature CA client vers TOUS les hôtes cibles


$ scp client-ca.pub root@192.168.9.200:/etc/ssh/client-ca.pub
client-ca.pub
$

Étape 12 sur les Hôtes cibles – Configurer pour utiliser la nouvelle clé publique CA client


vagrant@redis01:~$ sudo mv .ssh/client-ca.pub /etc/ssh/.
vagrant@redis01:~$ chmod 644 /etc/ssh/client-ca.pub
vagrant@redis01:~$ grep -qxF 'TrustedUserCAKeys /etc/ssh/client-ca.pub' /etc/ssh/sshd_config || echo 'TrustedUserCAKeys /etc/ssh/client-ca.pub' | sudo tee -a /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/client-ca.pub
vagrant@redis01:~$ sudo systemctl restart ssh
vagrant@redis01:~$ sudo systemctl status ssh
● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2020-01-03 22:18:58 UTC; 30s ago
Process: 29741 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
Main PID: 29743 (sshd)
Tasks: 1 (limit: 1112)
CGroup: /system.slice/ssh.service
└─29743 /usr/sbin/sshd -D

Jan 03 22:18:58 redis01 systemd[1]: Starting OpenBSD Secure Shell server...
Jan 03 22:18:58 redis01 sshd[29743]: Server listening on 0.0.0.0 port 22.
Jan 03 22:18:58 redis01 sshd[29743]: Server listening on :: port 22.
Jan 03 22:18:58 redis01 systemd[1]: Started OpenBSD Secure Shell server.
vagrant@redis01:~$

Étape 13 sur le serveur CA – Créer des certificats signés individuels pour les clients


$ ssh-keygen -s ../client-ca -I graham-dev -n root,vagrant,graham,pi -V -5:+52w -z 1 id_rsa.pub
Signed user key id_rsa-cert.pub: id "graham-dev" serial 1 for root,vagrant,graham,pi valid from 2020-01-03T23:05:07 to 2021-01-01T23:05:12
~/hashistack-ca/client-key
$ scp id_rsa-cert.pub graham@192.168.1.199:/home/graham/.ssh/id_rsa-cert.pub
id_rsa-cert.pub 100% 2562 136.2KB/s 00:00
~/hashistack-ca/client-key
$

Étape 14 sur le(s) client(s) – Tester l'accès au nouveau certificat ssh


$ ssh -v root@192.168.9.200
OpenSSH_7.9p1, LibreSSL 2.7.3
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug1: Connecting to 192.168.9.200 [192.168.9.200] port 22.
debug1: Connection established.
debug1: identity file /Users/grazzer/.ssh/id_rsa type 0
debug1: identity file /Users/grazzer/.ssh/id_rsa-cert type 4
debug1: identity file /Users/grazzer/.ssh/id_dsa type -1
debug1: identity file /Users/grazzer/.ssh/id_dsa-cert type -1
debug1: identity file /Users/grazzer/.ssh/id_ecdsa type -1
debug1: identity file /Users/grazzer/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/grazzer/.ssh/id_ed25519 type -1
debug1: identity file /Users/grazzer/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/grazzer/.ssh/id_xmss type -1
debug1: identity file /Users/grazzer/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
debug1: match: OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002
debug1: Authenticating to 192.168.9.200:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-rsa-cert-v01@openssh.com
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: compression: none

debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: compression: none

debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

debug1: Server host certificate: ssh-rsa-cert-v01@openssh.com SHA256:3lpUNJcP8GDhkHmozrhP4XA99s16AaV0kLI1fysjpEc, serial 0 ID "dev_host_server" CA ssh-rsa SHA256:uKJqQBCvoukiJ6n0GRX6Me8/VmHUB6bps81ekpUjdJ8 valid from 2020-01-03T16:51:35 to 2021-01-01T16:56:35

debug1: Host '192.168.9.200' is known and matches the RSA-CERT host certificate.

debug1: Found CA key in /Users/grazzer/.ssh/known_hosts:1

debug1: rekey after 134217728 blocks

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug1: SSH2_MSG_NEWKEYS received

debug1: rekey after 134217728 blocks

debug1: Will attempt key: /Users/grazzer/.ssh/id_rsa RSA SHA256:ZjZMqCQywrvljKloim0haaUEx7Io0NrVHO5QxXWaZdc

debug1: Will attempt key: /Users/grazzer/.ssh/id_rsa RSA-CERT SHA256:ZjZMqCQywrvljKloim0haaUEx7Io0NrVHO5QxXWaZdc

debug1: Will attempt key: /Users/grazzer/.ssh/id_dsa

debug1: Will attempt key: /Users/grazzer/.ssh/id_ecdsa

debug1: Will attempt key: /Users/grazzer/.ssh/id_ed25519

debug1: Will attempt key: /Users/grazzer/.ssh/id_xmss

debug1: SSH2_MSG_EXT_INFO received

debug1: kex_input_ext_info: server-sig-algs=ssh-ed25519

debug1: SSH2_MSG_SERVICE_ACCEPT received

debug1: Authentications that can continue: publickey,password

debug1: Next authentication method: publickey

debug1: Offering public key: /Users/grazzer/.ssh/id_rsa RSA SHA256:ZjZMqCQywrvljKloim0haaUEx7Io0NrVHO5QxXWaZdc

debug1: Authentications that can continue: publickey,password

debug1: Offering public key: /Users/grazzer/.ssh/id_rsa RSA-CERT SHA256:ZjZMqCQywrvljKloim0haaUEx7Io0NrVHO5QxXWaZdc

debug1: Server accepts key: /Users/grazzer/.ssh/id_rsa RSA-CERT SHA256:ZjZMqCQywrvljKloim0haaUEx7Io0NrVHO5QxXWaZdc

debug1: Authentication succeeded (publickey).

Authenticated to 192.168.9.200 ([192.168.9.200]:22).

debug1: channel 0: new [client-session]

debug1: Requesting no-more-sessions@openssh.com

debug1: Entering interactive session.

debug1: pledge: network

debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0

debug1: Sending environment.

debug1: Sending env LANG = en_GB.UTF-8

debug1: Sending env LC_TERMINAL_VERSION = 3.3.6

debug1: Sending env LC_TERMINAL = iTerm2

Welcome to Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-72-generic x86_64)

* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage

* Overheard at KubeCon: "microk8s.status just blew my mind".

https://microk8s.io/docs/commands#microk8s.status

* Canonical Livepatch is available for installation.
- Reduce system reboots and improve kernel security. Activate at:
https://ubuntu.com/livepatch
Last login: Fri Jan 3 22:46:44 2020 from 192.168.2.101
root@redis01:~#

Note :

Le certificat généré ci-dessus est Valide -V depuis 5 minutes pour les 30 prochains jours -5m:+30d. Idéalement, gardez cela aussi court que possible – pour mon environnement de développement/jeu, la sécurité n'est pas une préoccupation réelle – 30 jours est acceptable.

HTH

Graham

Originally published on allthingscloud.eu (2020-01-05).