But : se connecter en secure shell (SSH) sans entrer de mot de passe entre deux machines Linux.

Principe

Il peut-être utile d’automatiser des transferts de fichiers de façon sécurisée entre deux machines fonctionnant sous une distribution Linux.

Vous pouvez par exemple créer des CRONS qui se chargeront d’effectuer un transfert via rsync, généralement utilisé pour créer des sauvegardes entre deux serveurs distincts.

Le principe reste le même : on établit une connexion SSH dans laquelle vont circuler les données (via rsync, scp ou sftp).

Une connexion SSH s’établit avec un nom d’utilisateur autorisé à se connecter en SSH sur la machine (voir sshd_config), ainsi qu’un mot de passe associé à ce compte. Un échange de clé publique s’effectue ensuite pour créer une connexion SSH sécurisée, plus d’infos chez Wikipedia.

Pour que la machine distante accepte une connexion sans mot de passe, il faut que le serveur distant possède la clé publique du serveur local (dans la liste des clés publiques autorisées à effectuer une connexion sans mot de passe).

Nota : toutes les commandes de ce guide ont été effectuées sous Debian Etch (4.0), mais elle restent valables sur de nombreuses distributions : Debian toutes versions, Red Hat, CentOS, etc.

Etape 1 : générer la clé publique (machine locale)

Connectez-vous en root sur la machine locale, puis générer la clé :

ssh-keygen -t dsa -b 1024

serveurlocal:# ssh-keygen -t dsa -b 1024
Generating public/private dsa key pair.
Enter file in which to save the key (/root/.ssh/id_dsa): [TOUCHE ENTREE]
Enter passphrase (empty for no passphrase):[TOUCHE ENTREE]
Enter same passphrase again:[TOUCHE ENTREE]
Your identification has been saved in /root/.ssh/id_dsa.
Your public key has been saved in /root/.ssh/id_dsa.pub.
The key fingerprint is:
44:f8:69:4b:ad:9f:bd:42:dd:3d:17:04:0d:f0:b9:81 root@serveurlocal
The key's randomart image is:
+--[ DSA 1024]----+
|       ..  ..o+  |
|      ..    o .o |
|       ..o E +.  |
|       .= .   o. |
|       oSo . o ..|
|        o . . ..o|
|         o o    o|
|          + .    |
|           ...   |
+-----------------+
serveurlocal:#

Attention : n’entrez aucun passphrase, validez par entrée. Si vous entrez un passphrase il devra être entré à chaque demande de connexion, nous perdons le bénéfice de l’automatisation

Cela va générer deux fichiers dans le répertoire /root/.ssh/ :

• id_dsa : la clé privée (à ne pas diffuser), appelée identification pour identité
• id_dsa.pub : la clé publique

Note : n’utilisez que des clés de 1024 bits maximum, vous pourrez sinon avoir le message d’erreur : « DSA keys must be 1024 bits ».

Etape 2 : transférer la clé publique dans le serveur distant

Plusieurs méthodes s’offrent à vous pour transférer la clé publique vers la machine distante, nous allons toutes les voir en détail.

Méthode A : Transfert via ssh-copy-id

La commande ssh-copy-id permet d’installer votre clé publique sur une machine distante :

serveurlocal:~# ssh-copy-id -i /root/.ssh/id_dsa.pub root@serveurdistant
root@serveurdistant's password:
Now try logging into the machine, with "ssh 'root@serveurdistant'", and check in:

.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

serveurlocal:~#

L’intérêt de cette commande est double puisqu’elle place la clé directement dans le serveur distant et elle applique également les bons droits (chmod) sur le répertoire ~/.ssh ainsi que sur le fichier authorized_keys.

Liens utiles : QTH (pour ssh-copy-id)

Méthode B : Transfert via SCP

Pré-requis : connectez-vous en SSH sur le serveur distant, puis vérifiez que le répertoire ~/.ssh existe ainsi que le fichier authorized_keys Si ce n’est pas le cas, les créer  et appliquer les bons droits :

serveurdistant:# mkdir ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh

Vous pouvez ensuite envoyer la clé publique du serveur local en utilisant le de transfert SeCure coPy (SCP) :

scp ~/.ssh/id_dsa.pub root@serveurdistant:/root/clelocale.pub

serveurlocal:~# scp ~/.ssh/id_dsa.pub root@serveurdistant:/root/clelocale.pub
The authenticity of host 'serveurdistant (82.0.1.2)' can't be established.
RSA key fingerprint is 17:5d:99:24:b5:e1:b0:3a:98:e9:90:59:0d:1e:c6:9c.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'serveurdistant,82.0.1.2' (RSA) to the list of known hosts.
root@serveurdistant's password:
id_dsa.pub                                                                     100%  608     0.6KB/s   00:00
serveurlocal:~#

A la question « Are you sure you want to continue connecting » bien répondre yes (en toutes lettres).

Ajoutons ensuite la clé dans le fichier ~/.ssh/authorized_keys :

cat /root/clelocale.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
rm -f /root/clelocale.pub

Liens : Joël Brogniart, NotMyIdea (Alexis Métaireau)

Méthode C : Transfert via SSH + commande (manuel)

Réservée aux geeks ultimes, cette technique permet en une ligne de commande de faire tout le boulot, elle ressemble un peu à la commande ssh-copy-id puisqu’elle permet d’écrire dans la valeur de la clé stockée localement dans le serveur distant

ssh root@serveurdistant "echo $(cat ~/.ssh/id_dsa.pub) >> .ssh/authorized_keys"

Pensez également à faire un coup de chmod par mesure de sécurité :

cat /root/clelocale.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
rm -f /root/clelocale.pub

Liens : Hostingrails, Ubuntu (ssh), Yoann’s Blog

Exemple de transfert via Rsync

Voici un exemple de transfert de fichier entre les deux machines grâce à Rsync, il ne faut pas oublier de préciser la clé publique dans la commande :

rsync -avz -e "ssh -i /root/.ssh/id_dsa" root@serveurdistant:/chemin/distant /chemin/local

Lien : Jdmz

Aspect sécurité

Je vous déconseille fortement d’utiliser ce genre de transfert directement avec l’utilisateur root, vous comprendrez que si la clé publique vous est dérobée (par un quelconque piratage de votre site/serveur) vous offrez une connexion à un second serveur en SSH sans mot de passe…

Je vous invite plutôt à créer un second utilisateur unix qui ne sera pas super-utilisateur, quitte à lui donner différents droits d’exécution via le fichiers sudoers. C’est aussi pour cela que j’ai assez insisté sur le chmod, qui ne rendra visible la clé publique que à l’utilisateur concerné : il serait impossible, en exploitant une quelconque faille d’un mauvais script PHP, de récupérer cette clé publique car l’utilisateur  exécutant sera celui d’apache (www-data ou httpd) et n’aura aucun droit dessus.

Je partagerai prochainement l’un de mes scripts à base de rsync qui exploite ces échanges SSH sans mot de passe

Note : le fichier ~/.ssh/authorized_keys ne doit contenir aucun retour chariot pour une même clé, mais uniquement pour séparer les différentes clés autorisée.

Auteur : Mr Xhark

Fondateur du blog et passionné par les technologies je partage mes découvertes quotidiennement.