Principes fondamentaux de la connexion SSH

Chiffrement asymétrique

SSH repose sur le principe du chiffrement asymétrique, également appelé cryptographie à clé publique.

Caractéristiques du chiffrement asymétrique

• Une paire de clés est composée d'une clé publique et d'une clé privée
• La clé publique est distribuée aux nœuds du réseau qui souhaitent initier une communication
• La clé privée demeure sur le serveur et n'est jamais partagée
• Les données chiffrées avec la clé publique ne peuvent être déchiffrées que par la clé privée correspondante
• Lorsqu'un client initie une communication, il utilise la clé publique pour chiffrer. Même si un attaquant intercepte les données, il ne peut pas les déchiffrer car il ne possède pas la clé privée
• Le serveur utilise sa clé privée pour déchiffrer les messages reçus

Mécanisme de connexion SSH

Première connexion

Lors de la première connexion, le serveur distant envoie sa clé publique au client. Une invite apparaît alors :

L'authenticité de l'hôte 'serveur-distant.example.com (12.18.429.21)' ne peut pas être établie.
L'empreinte de la clé RSA est 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d.
Êtes-vous sûr de vouloir continuer la connexion (oui/non)?

Lorsque le client confirme, le système stocke les informations de l'hôte (nom, adresse IP, clé publique) dans le fichier ~/.ssh/known_hosts. Cela permet d'éviter la vérification manuelle lors des connexions suivantes. Exemple de contenu d'un fichier known_hosts :

serveur1.mondomain.com,192.168.1.10 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC7EXAMPLE8Z9qK2N3W4mV1p2L3Kj8H7fE2xA0B5cD4eF6gH7iJ8kL9mN0oP1qR2sT3uV4wX5yZ6aB7cD8eF9gH0iJ1kL2mN3oP4qR5sT6uV7wX8yZ9aA0bC1dE2f
serveur2.mondomain.com,192.168.1.20 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC9EXAMPLE1aB2cD3eF4gH5iJ6kL7mN8oP9qR0sT1uV2wX3yZ4aB5cD6eF7gH8iJ9kL0mN1oP2qR3sT4uV5wX6yZ7aA8bC9dE0fG1hI2jK

Authentification

Le client chiffre son mot de passe avec la clé publique du serveur, puis l'envoie. Le serveur détermine le message en utilisant sa clé privée. Comme seul le serveur possède cette clé privée, un attaquant intermédiaire interceptant les données ne peut pas les déchiffrer.

Risques de sécurité

Lors de la première connexion, le client doit faire confiance à la clé publique reçue. Si un attaquant intercepte cette étape, il peut transmettre sa propre clé publique au client. Ainsi, l'attaquant capture les identifiants du client, puis se connecte au serveur distant à son tour.

Connexion sans mot de passe par clé publique

L'authentification par mot de passe à chaque connexion s'avèrefastidieuse. Le chiffrement asymétrique permet de résoudre ce problème. Le client génère sa propre paire de clés etplace la clé publique sur le serveur. Ainsi, les deux parties disposent de clés publiques mutuelles, permettant une communication chiffrée durant toute la session.

Procédure de configuration

Le client exécute la commande ssh-keygen pour générer une paire de clés. Les fichiers sont créés dans le répertoire ~/.ssh : id_rsa (clé privée) et id_rsa.pub (clé publique).

Cette opération ne s'effectue qu'une seule fois. La clé publique doit être ajoutée sur le serveur distant, dans le fichier ~/.ssh/authorized_keys.

Méthodes pour copier la clé publique

• Méthode manuelle : copier le contenu de la clé publique et l'ajouter au fichier authorized_keys sur le serveur. Utiliser la commande suivante :

ssh utilisateur@serveur 'mkdir -p .ssh && cat >> .ssh/authorized_keys' < ~/.ssh/id_rsa.pub

• Méthode automatisée : utiliser ssh-copy-id :

ssh-copy-id utilisateur@serveur

Étapes d'authentification par clé publique

1. Le client stocke sa clé publique sur le serveur, dans le fichier authorized_keys.
2. Lorsque le serveur reçoit une demande de connexion, il recherche la clé publique du client dans authorized_keys. Il génère ensuite un nombre aléatoire N, chiffre ce nombre avec la clé publique du client (obtenant pubClient(N)), puis envoie le résultat au client.
3. Le client déchiffre le message avec sa clé privée pour obtenir N. Il calcule ensuite un condensé (hash) MD5 combinant N et la clé de session en cours : MD5(N + sessionKey), puis envoie ce condensé au serveur.
4. Le serveur effectue le même calcul de condensé avec les mêmes valeurs.
5. Le serveur сравнивает les deux condensés. S'ils correspondent, l'authentification réussit.

Gestion du service SSH

Structure du répertoire .ssh

Le répertoire .ssh, analog au fichier .profile d'un utilisateur, est associé à chaque utilisateur. Les utilisateurs root et ops ont chacun leur propre répertoire .ssh avec des contenus distincts.

Structure standard

• id_rsa : clé privée du client
• id_rsa.pub : clé publique du client
• known_hosts : stockage des clés publiques des serveurs distants lors des connexions sortantes
• authorized_keys : stockage des clés publiques des clients autorisés à se connecter au serveur

Gestion du démon SSH sur CentOS

Pour gérer le service sshd, les commandes suivantes sont disponibles :

service sshd status    # Vérifier le statut
service sshd restart   # Redémarrer le service
service sshd start     # Démarrer le service
service sshd stop      # Arrêter le service

Toute modification du fichier /etc/ssh/sshd_config nécessite un redémarrage du service sshd.

Résolution des problèmes de configuration

Erreur fréquentes

Authentication refused: bad ownership or modes for file /chemin/.ssh/authorized_keys

Cette erreur se produit car le serveur SSH vérifie les permissions du fichier authorized_keys lors d'une tentative de connexion. Le fichier ne doit pas être accessible en écriture par d'autres utilisateurs que le propriétaire.

Solution

Vérifier les permissions et les ajuster si nécessaire :

chmod g-w ~/.ssh/authorized_keys
chmod o-w ~/.ssh/authorized_keys

Cette restriction existe car le répertoire .ssh doit être propre à l'utilisateur. Seul l'utilisateur concerné et root devraient pouvoir modifier ces fichiers. Sinon, un autre utilisateur pourrait ajouter des clés publiques non autorisées et accéder au serveur.

Alternative possible : désactiver la vérification des permissions dans /etc/ssh/sshd_config en mettant StrictModes à no. Cette pratique est toutefois fortement déconseillée pour des raisons de sécurité.

Sources complémentaires

https://www.jianshu.com/p/33461b619d53https://www.ruanyifeng.com/blog/2011/12/ssh_remote_login.htmlhttps://www.daveperrett.com/articles/2010/09/14/ssh-authentication-refused/https://tldp.meulie.net/en/solrhe/chap15sec122.html