(modifié le 29 novembre 2014 à 2:51)

authentification-ssh-sans-mot-de-passeBut : 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é :

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 :

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 :

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

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 😉

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

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 :

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.

Si mon tutoriel n'est pas clair je vous propose un second tuto sur un autre blog, si vous souhaitez utiliser un passphrase voir ce tuto

Auteur : Mr Xhark

Fondateur du blog et passionné par les nouvelles techno, suivez-moi sur twitter