Se connecter en ssh sans demande de mot de passe
Cet article a été publié par Benjamin
le 26-02-08 à 17:46 dans la catégorie Serveur
Tags :
- Libre
- Serveur
- Tutoriel
Nous avons vu comment se connecter à distance, en ssh, sur une machine dans ce tuto. Voici donc aujourd'hui comment se connecter en ssh sans demande de mot de passe.
Démonstration par l'exemple.
Démonstration par l'exemple.
J'ai une machine (A), avec un compte "benjamin" à partir de laquelle je souhaite me connecter en root sur une autre machine (B) sans demande de mot de passe.
Sur la machine A (en utilisateur benjamin) :
ssh-keygen -t rsa, puis 3 fois EntréeCette commande me génère une clé publique et une clé privée (dans l'ordre, id_rsa.pub et id_rsa) dans le dossier /home/benjamin/.ssh
Ensuite, il faut copier la clé publique (id_rsa.pub) dans un fichier authorized_keys dans le dossier /root/.ssh de la machine B.
Sur la machine B :
sudo mkdir /root/.sshCréé le dossier /root/.ssh
Sur la machine A :
scp /home/benjamin/.ssh/id_rsa.pub 192.168.1.4:/root/.ssh/authorized_keysEn supposant que l'adresse IP de la machine B soit 192.168.1.4.
Il faut, uniquement cette fois, taper le mot de passe root de la machine B. Cette commande copie le fichier /home/benjamin/.ssh/id_rsa.pub dans le fichier /root/.ssh/authorized_keys de la machine B (même si ce fichier n'existe pas).
Toujours sur la machine A (en utilisateur benjamin) :
ssh root@192.168.1.4 (puis confirmer avec yes)Plus aucun mot de passe ne sera demandé.
Le fichier /home/benjamin/.ssh/known_hosts contient les 'identifiants' du pc sur lequel on a voulu se connecter.
Résumé :
- Je génère une clé publique ssh avec le compte benjamin sur la machine A,
- je la copie sur la machine B dans le fichier /root/.ssh/authorized_keys (si je veux avoir accès au compte root sans mot de passe),
- à partir de la machine A (avec le compte benjamin) je me connecte en ssh sur la machine B (ssh root@adresse_ip_machineB)
- il se créé donc un fichier /home/benjamin/.ssh/known_hosts contenant l'identité de la machine B.
Note : Pour améliorer la sécurité de ces connexions par clé RSA, nous pouvons restreindre l'utilisation de la clé d'authentification à l'adresse IP de la machine A en ajoutant from="
Ce dernier ressemblera donc à ceci :
from="192.168.1.2" ssh-rsa AB3NzaC1yc2EAzYABIwAb[...]
Note 2 : Une fois que nos clés publiques/privées ont été générées sur la machine A (étape 1), il est possible "d'automatiser" tout le reste avec une seule commande :
ssh-copy-idTrès simplement, sur la machine A, vous n'avez qu'à taper :
ssh-copy-id root@192.168.1.4 (pour reprendre notre exemple). Cette commande se chargera de créer le répertoire .ssh et de remplir le fichier authorized_keys automatiquement sur la machine distante.Pour les connexions SSH sur un port autre que le port 22, il faut lancer la commande
ssh-copy-id "-p 2224 root@192.168.1.4"
Laisser un accès libre à une machine en root est un manque de sécurité évident, malgré toutes les précautions préalables.
Commentaires
Il faudrait mieux ne pas autoriser root et se connecter a travers un autre nom d'utilisateur.
Il vaudrait mieux aussi couper ssh-server ;) Tout se joue en fait sur les risques effectifs.
Pour info, il existe une commande legerement plus simple :
ssh-copy-id -i ~/.ssh/id_rsa.pub root@192.168.1.4
@Fanch c'est de la mauvaise foi cette réponse à Polytan. Tout guide de sécu' qui se respecte insiste sur le fait que les remote logon avec une identité root sont à bannir ! Se prendre une attaque brute force sur le compte root par ssh C'EST un risque effectif par exemple, même sur un LAN.
Cela fait le deuxième article de ce genre qui passe sur ce site... L'objectif est de réduire la sécurité des linux au point d'obtenir des armées de spam-bots pingouin comme nous avons déjà des armées de spam-bots windows ?
La possibilité de se logger via une clef dsa d'un compte utilisateur version un compte root est simplement une très très mais alors très mauvaise idée. Et ta remarque Franck, je suis d'accord avec BurningHat, est un tantinet gratuite. On ne fait pas de sécurité sur la base de risque _effectifs_, sauf s'il est question de coût. On part d'un certains nombre de principes que l'on applique, comme par exemple couper tous les ports d'une machine touchant au net avant de chercher à en ouvrir, et ne pas permettre une escalade de privilèges sans une barrière (mot de passe, clef physique, etc.).
Mais pour rendre plus effectif le risque, si tu y tiens. Une des vraies raisons qui fait que Linux n'est pour l'instant pas réellement touché par les virus, outre le fait évident que l'on représente pour l'instant une surface d'attaque moindre que les Windowsiens, est qu'un virus choppé par un navigateur ou un compte mail, va être borné à ce que l'utilisateur en touché est capable de faire. Il aura les droits de cet utilisateur et nul autre (sauf si en plus il exploite une faille d'escalade). Maintenant si une habitude est prise à coller des clefs d'accès autorisant l'accès root à des users simples, ton virus, ne serait-ce que par simple exploration de ton ~/.bash_history, va passer root sur les machines locales ou distantes que tu auras ainsi rendu vulnérable.
Une fois de plus, une bonne solution si vous voulez ne pas rentrer de mot de passe en permanence est de passer par une clef externe physique, biométrie, ou simple clef-usb. Ou alors l'utilisateur peut aussi mettre sa clef DSA sur une clef USB et la monter automatiquement en lien et place du ~/.ssh. Ce n'est pas une solution parfaite (faut pas oublier de retirer la clef après usage), mais c'est plus sur que d'ouvrir les portes en disant,
"bouh, j'suis sous Nuxli, y'a plus de risque, plus besoin de sortir couvert..."
Je pense qu'il est clair que la sécurité sur Linux est une force de l'OS, mais c'est parfois quelques choses de contraignant.
Il faut utiliser le savoir en connaissance de cause.
La sécurité sur Linux est à peu prés aussi contraignante que de fermer la porte de chez soi en sortant, cela ne viendrait pourtant à l'idée de personne de ne pas le faire"
Effectivement c'est une "faille", toutefois, il est possible d'utiliser cette technique avec un compte utilisateur plutôt qu'un compte root.
Personnellement, j'utilise cette technique pour un serveur sur mon réseau local (non accessible de l'extérieur) donc à priori pas de problème.
Automatiser la connexion de l'utilisateur root est effectivement une mauvaise idée. Cependant, l'astuce reportée à un autre utilisateur à moindres droits est une bonne idée, notamment pour ce qui est automatisation de scripts (pour la sauvegarde par exemple).
Merci pour cet article!
@burningHat, Non mais je pense que j'ai mal argumenté ma remarque qui etait juste une touche d'humour. Il n'y a toujours pas qu'une solution pour le souci soulevé, le risque que tu évoques peut par exemple se contourner par fail2ban. Je le rappelle qu'il s'agit ici d'un réseau local.
@polytan , Excuse moi si je t'ai blessé de façon quelconque, ce n'etait pas mon intention.
tout ceci ne fonctionne que si le repertoire .ssh est en mode 700.
la commande est incorrecte et dangereuse
car elle écrase tout simplement le fichier authorized_keys de l'hôte distant !
le mieux est d'utiliser ssh-copy-id -i ~/.ssh/id_rsa.pub root@192.168.1.4
salut,
bien cool cette commande :)
je présume que le résultat se concatène au fichier authorized_keys.
je teste lundi, ça va me faciliter la tache dans pas mal de cas.
Salut Benj au passage ;)
Bonjour,
merci pour ce tuto.
J'ai quand même un problème : il n'ya plus de demande de mot de passe effectivement, mais quand je tente de scripter le tout, il me demande à chaque fois le mot de passe.
ma commande est la suivante:
sftp -oIdentityFile=/home/oracle/.ssh/id_rsa ${USER_SRV_DIST}@${IP_ADDR_SRV_DIST} << VERIF_CONNEX cd ${REP_DUMP_CIBLE} quitVERIF_CONNEX
Si je comprends bien, il ne faut pas taper de passphrase pour éviter la demande de mot de passe. Alors en faisant une copie de mes clés privée/publique on peut accéder au serveur ?