Comment créer une CA SSH pour valider les hôtes et les clients avec Ubuntu

Introduction

Lors de la configuration d'un grand nombre de serveurs avec de nombreux utilisateurs, maintenir l'accès SSH en accord avec votre infrastructure peut devenir complexe. Il existe plusieurs façons de mettre en œuvre une autorité d'authentification centralisée, comme LDAP, mais celles-ci sont parfois excessives.

SSH a en fait la fonctionnalité d'utiliser une autorité de certification pour authentifier les serveurs et les clients. Cela fonctionne dans les deux sens. En utilisant ce système, vous pouvez authentifier un hôte auprès d'un client, évitant ainsi des messages confus concernant l'impossibilité de valider l'authenticité de l'hôte. Vous pouvez également valider le client auprès de l'hôte, vous permettant d'enregistrer une nouvelle clé SSH à un seul endroit et de permettre l'accès à travers votre organisation.

Nous discuterons de la manière d'exploiter ces certificats de deux manières comme mentionné ci-dessus. Nous ferons une démonstration sur trois instances VPS Ubuntu 12.04. L'une servira d'hôte, une autre de client, et la troisième fonctionnera comme autorité de certification.

Comment configurer les certificats d'hôte

Nous commencerons par configurer des certificats qui authentifieront nos serveurs auprès de nos clients. Cela permettra à nos clients de se connecter à nos serveurs sans avoir à remettre en question l'authenticité du serveur.

Nous commençons par la machine que nous utiliserons comme autorité de certification. Dans cet exemple, nous l'appellerons « auth.example.com ».

Génération de clés de signature

Tout d'abord, nous devons générer des clés RSA qui serviront de clés de signature. Utilisez n'importe quel utilisateur que vous souhaitez, mais l'utilisateur root est probablement une bonne idée. Nous allons créer des clés appelées « server_ca » et « server_ca.pub » car celles-ci seront utilisées pour authentifier nos serveurs.

Créons ces clés dans notre répertoire personnel :

cd ~
ssh-keygen -f server_ca

On vous demandera si vous souhaitez créer une phrase secrète. Cela ajoutera une couche de protection supplémentaire à votre clé dans le cas où elle tomberait entre de mauvaises mains. Une fois cela terminé, vous aurez une clé privée et une clé publique dans votre répertoire personnel:

ls

server_ca   server_ca.pub

Signature des clés d'hôte

Maintenant que nous avons nos clés, nous pouvons commencer à signer nos clés d'hôte.

Nous devrions commencer par signer la clé d'hôte de l'autorité de certification elle-même. Nous pouvons le faire en utilisant la syntaxe suivante :

 ssh-keygen -s clé_de_signature -I identifiant_de_clé -h -n nom_d_hôte -V +52w clé_rsa_d_hôte 

Passons en revue ce que tout cela signifie.

• -s: C'est la clé privée que nous venons de créer et que nous utiliserons pour signer toutes les autres clés.
• -Je: C'est un nom qui est utilisé pour identifier le certificat. Il est utilisé à des fins de journalisation lorsque le certificat est utilisé pour l'authentification.
• -h: Cela marque le certificat résultant comme une clé d'hôte, par opposition à une clé de client.
• -n : Ceci est utilisé pour identifier le nom (utilisateur ou hôte) qui est associé à ce certificat.
• -V: Cela spécifie combien de temps le certificat est valide. Dans ce cas, nous précisons que le certificat expirera dans un an (52 semaines).

Ensuite, nous spécifions la clé que nous voulons signer.

Dans notre cas, pour signer notre propre clé RSA d'hôte, nous allons utiliser une ligne qui ressemble à ceci. Nous allons identifier ce serveur comme « host_auth_server ». On nous demandera la phrase de passe que nous avons utilisée lors de la création de la clé de signature :

ssh-keygen -s server_ca -I host_auth_server -h -n auth.example.com -V +52w /etc/ssh/ssh_host_rsa_key.pub

Signed host key /etc/ssh/ssh_host_rsa_key-cert.pub: id "host_auth_server" serial 0 for auth.example.com valid from 2014-03-20T12:25:00 to 2015-03-19T12:26:05

Comme vous pouvez le voir dans la sortie, notre certificat est valide pour un an. Il a été créé dans le même répertoire que notre clé d'hôte du serveur (/etc/ssh/) et s'appelle “ssh_host_rsa_key-cert.pub ”.

Maintenant que nous avons signé notre clé d'hôte sur l'autorité de certification elle-même, nous pouvons signer la clé d'hôte pour le serveur SSH séparé auquel nous essayons de nous authentifier auprès des clients.

Copiez la clé d'hôte de notre serveur SSH. Nous ferons référence à cette machine comme « sshserver.example.com ». Vous pouvez le faire en utilisant scp :

cd ~
scp root@sshserver.example.com:/etc/ssh/ssh_host_rsa_key.pub .

Maintenant, nous pouvons créer un certificat à partir de ce fichier en utilisant la même méthode que celle que nous avons utilisée ci-dessus. Nous devrons modifier certaines valeurs pour faire référence au nouvel hôte que nous signons :

ssh-keygen -s server_ca -I host_sshserver -h -n sshserver.example.com -V +52w ssh_host_rsa_key.pub

Signed host key ssh_host_rsa_key-cert.pub: id "host_sshserver" serial 0 for sshserver.example.com valid from 2014-03-20T12:40:00 to 2015-03-19T12:41:48

Maintenant, nous devons copier le fichier de certificat généré sur l'hôte. Encore une fois, nous pouvons utiliser scp pour cela :

scp ssh_host_rsa_key-cert.pub root@sshserver.example.com:/etc/ssh/

Ensuite, nous pouvons supprimer à la fois la clé publique du serveur SSH et le certificat de notre serveur d'authentification :

rm ssh_host_rsa_key.pub ssh_host_rsa_key-cert.pub

Nous avons maintenant les certificats signés en place, nous devons juste configurer nos composants pour les utiliser.

Configurer les composants pour utiliser les certificats d'hôte

Tout d'abord, nous devons continuer avec nos deux serveurs (auth.example.com et sshserver.example.com) pour les rendre conscients des fichiers de certificat que nous avons créés.

Sur ces deux machines, nous devrons modifier le fichier de configuration principal du démon SSH. Assurez-vous de modifier le fichier sshd_config, et non le fichier ssh_config :

sudo nano /etc/ssh/sshd_config

Si vous pouvez trouver une ligne HostCertificate, modifiez-la. Sinon, ajoutez ceci en bas du fichier. Nous devons établir le chemin vers notre fichier de certificat d'hôte :

HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

Enregistrez et fermez le fichier lorsque vous avez terminé.

Maintenant, redémarrez le démon SSH pour appliquer ces changements :

sudo service ssh restart

Faites ceci sur tous les serveurs pour lesquels vous configurez des certificats d'hôte.

Maintenant, nos serveurs sont configurés pour utiliser le certificat, mais notre client ne sait pas comment vérifier le certificat que le serveur présentera.

Sur notre machine cliente, que nous appellerons « client.example.com », ouvrez ou créez le fichier « ~/.ssh/known_hosts » :

nano ~/.ssh/known_hosts

Nous devons supprimer toutes les entrées qui concernent les serveurs que nous configurons pour l'entrée du certificat. Il serait peut-être préférable de tout supprimer.

Ensuite, nous devons ajouter une entrée spéciale qui spécifie la clé publique que nous devons utiliser pour vérifier le certificat que nos hôtes nous remettront lors de la connexion. Commencez par @cert-authority. Ensuite, il peut inclure une restriction de domaine où la clé sera appliquée, suivie de la clé de l'autorité de certification publique avec laquelle nous avons signé tous les documents.

Sur votre machine d'autorité de certification, vous pouvez obtenir la clé de signature de certificat publique en tapant :

cat ~/server_ca.pub

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCxC+gikReZlWEnZhKkGzhcNeRD3dKh0L1opw4/LQJcUPfRj07E3ambJfKhX/+G4gfrKZ/ju0nanbq+XViNA4cpTIJq6xVk1uVvnQVOi09p4SIyqffahO9S+GxGj8apv7GkailNyYvoMYordMbIx8UVxtcTR5AeWZMAXJM6GdIyRkKxH0/Zm1r9tsVPraaMOsKc++8isjJilwiQAhxdWVqvojPmXWE6V1R4E0wNgiHOZ+Wc72nfHh0oivZC4/i3JuZVH7kIDb+ugbsL8zFfauDevuxWeJVWn8r8SduMUVTMCzlqZKlhWb4SNCfv4j7DolKZ+KcQLbAfwybVr3Jy5dSl root@auth

En utilisant ces informations, la ligne dans votre fichier ~/.ssh/known_hosts devrait ressembler à :

@cert-authority *.example.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCxC+gikReZlWEnZhKkGzhcNeRD3dKh0L1opw4/LQJcUPfRj07E3ambJfKhX/+G4gfrKZ/ju0nanbq+XViNA4cpTIJq6xVk1uVvnQVOi09p4SIyqffahO9S+GxGj8apv7GkailNyYvoMYordMbIx8UVxtcTR5AeWZMAXJM6GdIyRkKxH0/Zm1r9tsVPraaMOsKc++8isjJilwiQAhxdWVqvojPmXWE6V1R4E0wNgiHOZ+Wc72nfHh0oivZC4/i3JuZVH7kIDb+ugbsL8zFfauDevuxWeJVWn8r8SduMUVTMCzlqZKlhWb4SNCfv4j7DolKZ+KcQLbAfwybVr3Jy5dSl root@auth

Enregistrez et fermez le fichier lorsque vous avez terminé.

Maintenant, lorsque vous visitez le serveur SSH pour la première fois depuis votre client (en utilisant le nom d'hôte complet), vous ne devriez pas être invité à faire confiance à l'hôte distant. C'est parce que l'hôte vous a présenté son certificat d'hôte, signé par l'autorité de certification. Vous avez vérifié votre fichier known_hosts et confirmé que le certificat est légitime.

Comment configurer les clés utilisateur

Maintenant que nous avons appris à authentifier les serveurs auprès de nos utilisateurs, nous pouvons également configurer notre autorité de certification pour authentifier nos utilisateurs auprès de nos serveurs.

Comme précédemment, ce processus commencera sur notre serveur d'autorité de certification. Nous devrons générer un nouvel ensemble de clés, cette fois-ci, pour signer des certificats d'utilisateur :

ssh-keygen -f users_ca

Encore une fois, choisissez une phrase de passe afin que votre clé soit protégée si quelqu'un accède à votre appareil.

Configurer les serveurs pour accepter des connexions avec la certification de l'utilisateur

Lorsque vous avez terminé, vous devrez copier la clé publique sur chacun de vos serveurs SSH qui doivent valider l'authenticité des utilisateurs. Nous allons faire cela en utilisant scp comme d'habitude :

scp users_ca.pub root@sshserver.example.com:/etc/ssh/

Nous devons modifier la configuration de notre démon SSH sur notre serveur SSH pour rechercher cette clé.

Sur notre hôte « sshserver.example.com », ouvrez le fichier de configuration :

sudo nano /etc/ssh/sshd_config

Au bas, en dessous de notre ligne HostCertificate, nous devons ajouter une autre ligne qui fait référence au fichier que nous venons de copier :

TrustedUserCAKeys /etc/ssh/users_ca.pub

Encore une fois, nous devrons redémarrer le démon SSH pour que ces changements prennent effet :

sudo service ssh restart

Clé de connexion de l'utilisateur signé

Maintenant que les serveurs sont configurés pour faire confiance aux clés signées par la clé users_ca, nous devons en fait signer les clés d'authentification des utilisateurs afin que ce système fonctionne.

Tout d'abord, nous devons transférer notre clé client vers le serveur de l'autorité de certification avec scp. Depuis le serveur de certification, tapez :

 cd ~ scp username@client.example.com:/home/username/.ssh/id_rsa.pub . 

Maintenant que nous avons la clé sur la machine cert, nous pouvons la signer en utilisant notre clé users_ca. Cela sera très similaire à la dernière fois que nous avons signé des clés en utilisant les clés server_ca, sauf que maintenant, nous n'incluons pas le paramètre -h, car ce sont des clés utilisateur.

La commande que nous voulons est quelque chose comme cela. Changez la valeur “nom d'utilisateur” pour refléter le nom de l'utilisateur pour lequel vous signez afin de faciliter la gestion :

 ssh-keygen -s users_ca -I user_nom_utilisateur -n nom_utilisateur -V +52w id_rsa.pub 

 Clé utilisateur signée id_rsa-cert.pub : id "user_nom_utilisateur" série 0 pour nom_utilisateur valide du 2014-03-20T14:45:00 au 2015-03-19T14:46:52 

On vous demandera le mot de passe users_ca qui a été défini lors de la création de la clé. Maintenant, nous avons un fichier id_rsa-cert.pub dans notre répertoire que nous devons transférer sur notre machine cliente :

 scp id_rsa-cert.pub nom_utilisateur@client.example.com:/home/nom_utilisateur/.ssh/ 

Maintenant, lorsque vous vous connectez à sshserver.example.com depuis votre ordinateur client, vous ne devriez pas être invité à fournir vos détails d'authentification, même si vous ne vous êtes jamais connecté à ce serveur en tant qu'utilisateur auparavant.

Conclusion

En signant vos clés d'hôte et d'utilisateur, vous pouvez créer un système plus flexible pour la validation des utilisateurs et des serveurs. Cela vous permet de mettre en place une autorité centralisée pour l'ensemble de votre infrastructure, afin de valider vos serveurs auprès de vos utilisateurs, et vos utilisateurs auprès de vos serveurs.

Bien que ce ne soit peut-être pas la méthode la plus puissante pour créer une authentification centralisée, elle est facile à mettre en place et utilise des outils existants sans nécessiter beaucoup de temps ni de configuration. Elle a également l'avantage de ne pas nécessiter que le serveur CA soit en ligne pour vérifier les certificats.