Voici une courte note sur la configuration des connexions sans mot de passe entre 2 systèmes Linux. Le processus consiste essentiellement à générer une clé d'authentification publique et à l'ajouter au fichier ~/.ssh/authorized_keys des hôtes distants.
Générer la clé d'authentification
Si un fichier de clé d'authentification SSH n'existe pas, générez-en un en exécutant ssh-keygen commande. Lorsque vous êtes invité à entrer une phrase secrète, utilisez une phrase secrète vide si une connexion entièrement sans mot de passe est requise :
# ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/user/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/id_rsa. Your public key has been saved in /home/user/.ssh/id_rsa.pub. The key fingerprint is: 1e:b2:f4:89:5a:7f:2d:a5:a5:4d:6d:66:2c:82:d8:18 root@remote-host
Copiez la clé publique sur l'hôte distant
Utilisez le ssh-copy-id pour installer la moitié publique de la clé d'authentification nouvellement générée dans le répertoire personnel d'un utilisateur spécifique sur l'hôte distant. La commande ssh-copy-id ajoutera alors automatiquement les informations d'identité dans le ~/.ssh/authorized_keys fichier pour l'utilisateur spécifié sur l'hôte distant (en créant ~/.ssh et ~/.ssh/authorized_keys si nécessaire).
# ssh-copy-id -i ~/.ssh/id_rsa.pub user@remote-host user@remote-hosts's password:
Alternativement, si le serveur n'est pas installé avec openssh-clients (un package qui fournit l'utilitaire de commande ssh-copy-id), vous pouvez copier la clé d'authentification avec la commande :
# cat ~/.ssh/id_rsa.pub | ssh user@remote-host "cat >> ~/.ssh/authorized_keys"
Si tout est correctement configuré, vous devriez pouvoir vous connecter à l'hôte distant sans mot de passe.
Dépannage
Vérifiez les autorisations correctes
La cause la plus fréquente de problèmes pour faire fonctionner l'authentification SSH basée sur une clé est les autorisations de fichiers sur le serveur SSH distant sur les fichiers utilisateur local et distant . Les autorisations des répertoires doivent être exactement comme indiqué ci-dessous. L'exemple présenté ici est pour l'utilisateur "oracle"
drwx------. 25 oracle oinstall 4096 Aug 21 11:01 /home/oracle/ drwx------. 2 oracle oinstall 4096 Aug 17 13:13 /home/oracle/.ssh -rw-------. 1 oracle oinstall 420 Aug 17 13:13 /home/oracle/.ssh/authorized_keys
Si les autorisations ne sont pas comme ci-dessus, définissez-les correctement :
# chmod 600 ~/.ssh/authorized_keys chmod 700 ~/.ssh/
Redémarrez le service sshd pour que les modifications prennent effet :
# service sshd restart
désactiver SElinux
SELinux peut également potentiellement empêcher sshd d'accéder au répertoire ~/.ssh sur le serveur. Ce problème peut être exclu (ou résolu) en exécutant restorecon comme suit sur le répertoire ~/.ssh de l'utilisateur distant :
# restorecon -Rv ~/.ssh