Génération de la paire de clés cryptographiques

L'authentification SSH par clés asymétriques repose sur une paire de clés : une clé privée conservée localement et une clé publique distribuée aux serveurs distants. Sur un terminal macOS ou Linux, générez une clé RSA robuste de 4096 bits :

ssh-keygen -b 4096 -t rsa -f ~/.ssh/id_rsa_prod -N ""

Le paramètre -N "" définit une phrase de passe vide pour permettre les connexions entièrement automatisées sans intervention humaine. Vérifiez ensuite la création des fichiers dans le répertoire dédié :

ls -l ~/.ssh/id_rsa_prod*

Cette commande listera le fichier id_rsa_prod (la clé privée) et id_rsa_prod.pub (la clé publique).

Déploiement de la clé publique sur le serveur distant

Au lieu de copier manuellement le fichier via SCP puis de l'éditer, il est préférable d'utiliser un flux SSH direct pour créer l'arborescence et injecter la clé publique de manière atomique :

cat ~/.ssh/id_rsa_prod.pub | ssh admin@10.0.0.50 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Cette méthode évite l'écrasement accidentel de clés existantes en utilisant l'opérateur d'ajout >>, et s'affranchit des ereurs liées à des commandes mal formatées qui pourraient introduire des caractères invalides dans le fichier d'autorisation.

Configuration du client SSH local

Pour simplifier les futures connexions et éviter de spécifier l'utilisateur, l'adresse IP et le chemin de la clé à chaque tentative, déclarez un alias d'hôte dans le fichier de configuration local :

nano ~/.ssh/config

Ajoutez le bloc de configuration suivant :

Host web-prod
    HostName 10.0.0.50
    User admin
    IdentityFile ~/.ssh/id_rsa_prod
    IdentitiesOnly yes

La directive IdentitiesOnly yes force le client SSH à n'utiliser que la clé explicitement spécifiée, évitant ainsi les échecs d'authentification courants lorsque trop de clés sont chargées simultanément dans l'agent SSH. La connexion au serveur s'effectuera désormais simplement avec la commande :

ssh web-prod

Dépannage : Résolution des erreurs de permissions

Le démon SSH (sshd) applique des règles de sécurité très strictes. Si les permissions des fichiers ou des répertoires de l'utilisateur cible sont trop permissives, l'authentification par clé sera systématiquemnet rejetée par mesure de sécurité.

En cas d'échec de connexion, utilisez temporairement un mot de passe pour vous connecter, puis inspectez les journaux d'authentification système :

sudo tail -n 30 /var/log/secure

Sur les systèmes basés sur Debian ou Ubuntu, le fichier de journalisation se situe généralement à /var/log/auth.log. Recherchez des messages d'erreur similaires à ceux-ci :

Authentication refused: bad ownership or modes for directory /home/admin/.ssh
Authentication refused: bad ownership or modes for file /home/admin/.ssh/authorized_keys

Ces avertissements indiquent que le répertoire .ssh ou le fichier authorized_keys est accesible en écriture par d'autres utilisateurs, ou que le propriétaire des fichiers n'est pas l'utilisateur cible (une situation fréquente si le répertoire a été créé ou modifié avec les privilèges root).

Appliquez les correctifs de permissions et de propriété suivants pour rétablir la conformité exigée par SSH :

# Restreindre l'accès au répertoire .ssh au propriétaire uniquement
chmod 0700 /home/admin/.ssh

# Restreindre l'accès au fichier authorized_keys
chmod 0600 /home/admin/.ssh/authorized_keys

# Réassigner la propriété récursive de tous les fichiers au bon utilisateur
sudo chown -R admin:admin /home/admin/.ssh