Français
Menu

Qu'est-ce que SSH ?

Protocole (et commande) qui chiffre les communications pour se connecter à un autre ordinateur par le réseau et y exécuter des commandes. Le serveur écoute par défaut sur le port TCP 22. Pour l'authentification, outre les mots de passe, on utilise beaucoup l'authentification par clé publique : la clé publique qui correspond à la clé privée de l'utilisateur est enregistrée dans le fichier ~/.ssh/authorized_keys du serveur. Sur la même connexion, on peut aussi transférer des fichiers avec scp ou rsync et rediriger des ports.

Nom japonais: SSH

« SSH » apparaît dans 3 questions d'entraînement réparties sur 2 thèmes, dont Bases de Linux et de la ligne de commande, Bases des réseaux informatiques.

Domaine: Bases de Linux et de la ligne de commande

Fonctionnement de l'authentification par clé publique

On crée avec ssh-keygen une paire formée d'une clé privée et d'une clé publique, et on n'enregistre que la clé publique (le fichier .pub) dans le fichier authorized_keys du serveur. Lors de la connexion, le client produit une signature avec la clé privée et la présente au serveur, qui la vérifie avec la clé publique enregistrée : la clé privée elle-même ne circule donc jamais sur le réseau. La clé privée est protégée par une phrase de passe, et la confier à ssh-agent évite de la saisir à chaque connexion.

Vérifier le serveur

À la première connexion, ssh montre l'empreinte de la clé d'hôte du serveur et, si on l'accepte, l'enregistre dans ~/.ssh/known_hosts. Par la suite, si une clé différente de celle enregistrée est présentée, il affiche un avertissement et s'arrête, ce qui permet de repérer un serveur qui se fait passer pour un autre. Si l'avertissement apparaît sans raison, par exemple sans que le serveur ait été remplacé, il ne faut pas poursuivre la connexion.

Usage dans le travail de conception

Depuis leur PC, les utilisateurs se connectent avec ssh aux serveurs de calcul qui exécutent les outils EDA, pour y lancer des simulations et en vérifier les résultats. En écrivant dans ~/.ssh/config les alias des hôtes, les noms d'utilisateur, les fichiers de clés et les serveurs intermédiaires (ProxyJump), on peut se connecter avec un simple ssh server1. Les outils à interface graphique s'utilisent en combinaison avec le transfert X11 ou avec des mécanismes de bureau à distance.

S'entraîner : questions sur SSH

Sur un serveur auquel on s'est connecté par SSH, on a lancé un long traitement avec « ./run.sh & », puis, en fermant la connexion, le traitement s'est arrêté lui aussi. Quelle est la manière la plus appropriée de le lancer pour qu'il continue après la fermeture de la connexion ?

  1. A./run.sh > run.log 2>&1 &
  2. Bnice -n 19 ./run.sh > run.log 2>&1 &
  3. Cnohup ./run.sh > run.log 2>&1 &
Afficher la réponse et l'explication

Réponse : C. nohup ./run.sh > run.log 2>&1 &

Quand la connexion est perdue, le signal SIGHUP, qui indique que le terminal a raccroché, est envoyé au shell, et les shells comme bash envoient eux aussi SIGHUP à leurs tâches. L'action par défaut à la réception de SIGHUP est de se terminer : les tâches en arrière-plan s'arrêtent donc aussi. nohup lance la commande de sorte qu'elle ignore SIGHUP, et si sa sortie est dirigée vers un fichier, le traitement continue après la fermeture de la connexion. Si on la lance depuis un terminal sans redirection de la sortie, nohup écrit la sortie dans un fichier nommé nohup.out. Une autre méthode courante consiste à utiliser un outil comme tmux ou screen, qui maintient la session de terminal sur le serveur et permet de s'y reconnecter plus tard.

Questions fréquentes

La connexion échoue avec le message « Permission denied (publickey) ». Que faut-il vérifier ?

Il faut vérifier que la clé publique qui correspond à la clé privée utilisée est enregistrée dans le fichier ~/.ssh/authorized_keys du serveur, et que le nom d'utilisateur est correct. Si les permissions de ~/.ssh ou d'authorized_keys sur le serveur sont trop larges (accessibles en écriture à d'autres), la clé peut être refusée par sécurité : on règle donc par exemple ~/.ssh sur 700 et authorized_keys sur 600. Avec ssh -v, on voit quelles clés ont été essayées.

Comment choisir entre scp et rsync ?

Les deux transfèrent des fichiers par-dessus ssh. scp convient aux copies simples, tandis que rsync n'envoie que les différences avec la destination : il est donc efficace pour synchroniser de façon répétée de gros répertoires ou reprendre un transfert interrompu. Utilisé sous la forme rsync -av --delete, il rend la destination identique à la source, mais --delete supprime les fichiers qui n'existent que dans la destination : il faut donc être prudent.

« SSH » dans les explications

Questions mentionnant « SSH » (3)

  1. Sur un serveur auquel on s'est connecté par SSH, on a lancé un long traitement avec « ./run.sh & », puis, en fermant la connexion, le traitement s'est arrêté lui aussi. Quelle est la manière la plus appropriée de le lancer pour qu'il continue après la fermeture de la connexion ?
  2. On a créé avec ssh-keygen, sur son propre PC, une paire de clés pour l'authentification par clé publique, et on veut se connecter au serveur server1 avec ssh sans mot de passe. Quelle est la bonne façon de placer les clés ?
  3. Quelle combinaison associe correctement des protocoles aux numéros de port standard utilisés par leurs serveurs ?

Termes associés

Shell Redirection des entrées-sorties Numéro de port HTTP (Hypertext Transfer Protocol) DNS (Domain Name System) cron Expression régulière (regex) Git grep inode

Retour au glossaire