Secure Shell

#ssh

Table des matières

À propos 1

Chapitre 1: Démarrer avec Secure Shell 2

Remarques 2

Versions 2

Examples 2

Installation ou configuration 2

Installation 2

Sur Linux basé sur Debian, vous pouvez installer openssh utilisant 3

Sur RHEL / CentOS, vous devez utiliser yum : 3

Sur Arch Linux, utilisez pacman: 3

Sur OSX, le openssh devrait déjà être installé. 3

Instructions TODO pour Windows 3

Installer 3

Configuration 4

Créer votre clé SSH 4

Comment SSH dans une machine 5

Ajout de votre clé publique à la liste des clés autorisées de l'utilisateur du serveur 6

Connexion depuis un script en utilisant un mot de passe 6

Fichier de configuration 7

Agent SSH 7

Chapitre 2: Commandes à distance 9

Examples 9

Bonjour le monde 9

Commandes interactives et basées sur un écran 9

Chapitre 3: Débogage des problèmes ssh 10

Examples 10

La clé privée n'est pas acceptée (débogage des clients OpenSSH) 10

IDENTIFICATION HÔTE À DISTANCE A CHANGÉ! 10

Connexion rejetée 11

La connexion a expiré 12

ssh_exchange_identification: lire: connexion réinitialisée par l'homologue 13

ssh_exchange_identification: connexion fermée par l'hôte distant 13

Chapitre 4: Gestion des fichiers distants via ssh 15

Introduction 15

Examples 15

Montage du répertoire distant via ssh 15

Déplacement de fichiers entre serveurs via ssh 15

Chapitre 5: Travailler avec des clés ssh 16

Examples 16

Convertir PPK (clé PuTTY) au format OpenSSH 16

Chapitre 6: Tuer une session SSH sans réponse 17

Introduction 17

Examples 17

Tuer une session SSH en utilisant le caractère d'échappement 17

Chapitre 7: Tunnels inverses 18

Examples 18

OpenSSH 18

Ligne de commande 18

Configuration 18

Courir en arrière-plan 18

Crédits 20

À propos

You can share this PDF with anyone you feel could benefit from it, downloaded the latest version from: secure-shell

It is an unofficial and free Secure Shell ebook created for educational purposes. All the content is extracted from Stack Overflow Documentation, which is written by many hardworking individuals at Stack Overflow. It is neither affiliated with Stack Overflow nor official Secure Shell.

The content is released under Creative Commons BY-SA, and the list of contributors to each chapter are provided in the credits section at the end of this book. Images may be copyright of their respective owners unless otherwise specified. All trademarks and registered trademarks are the property of their respective company owners.

Use the content presented in this book at your own risk; it is not guaranteed to be correct nor accurate, please send your feedback and corrections to info@zzzprojects.com

https://riptutorial.com/fr/home 1

Chapitre 1: Démarrer avec Secure Shell

Remarques

SSH (Secure Shell) est un protocole cryptographique pour la communication point à point sur le réseau non sécurisé (Internet). Il rend obsolètes les anciens protocoles utilisés dans le rlogin ( rlogin , rsh , telnet ).

Il est généralement utilisé pour se connecter à des serveurs distants, à des machines virtuelles ou à des conteneurs dans un centre de données ou dans votre cloud privé (moteur de calcul Google, AWS, ...). Mais il est également couramment utilisé en conjonction avec git pour accéder et mettre à jour votre référentiel de manière sécurisée et facile à l'aide de clés publiques plutôt que de mots de passe.

Il devrait également mentionner tous les sujets importants dans ssh, et établir un lien avec les sujets connexes. La documentation de ssh étant nouvelle, vous devrez peut-être créer des versions initiales de ces rubriques connexes. FAIRE

Versions

Version Notes de version Date de sortie

OpenSSH 7.3p1 Dernière version 2016-08-01

OpenSSH 7.2p2 2016-03-09

OpenSSH 7.1p2 2016-01-14

OpenSSH 7.1 2015-08-21

OpenSSH 7.0 2015-11-08

OpenSSH 6.9 2015-07-01

OpenSSH 6.8 2015-03-18

Examples

Installation ou configuration

Version gratuite de l'implémentation du protocole SSH, OpenSSH est disponible dans toutes les distributions Linux. Il se compose des packages serveur et client.

Installation

https://riptutorial.com/fr/home 2

Sur Linux basé sur Debian, vous pouvez installer openssh utilisant

# apt-get install openssh-server openssh-client

Sur RHEL / CentOS, vous devez utiliser yum :

# yum install openssh-server openssh-clients

Fedora actuel utilise dnf au lieu de yum .

Sur Arch Linux, utilisez pacman:

# pacman -S openssh

Sur OSX, le openssh devrait déjà être installé.

Si vous souhaitez utiliser une version plus récente, vous devez installer le openssh de brew:

# brew install openssh --with-brewed-openssl --with-keychain-support

Instructions TODO pour Windows

Installer

Le client openssh ne nécessite aucune configuration particulière et est prêt à être utilisé juste après l’installation. Vous pouvez essayer d'exécuter ssh remote , où la remote est l'hôte distant exécutant le serveur ssh .

Le serveur openssh est généralement démarré après l'installation et la configuration par défaut est appliquée. Sinon, vous pouvez le démarrer sur des systèmes basés sur systemd en utilisant

Sur Linux basé sur Debian avec systemd:

# systemctl start ssh

Sur RHEL / CentOS / Fedora et Arch Linux:

# systemctl start sshd

Ou sur des systèmes novateurs utilisant

https://riptutorial.com/fr/home 3

# service sshd start

Configuration

Le fichier openssh des fichiers de configuration sous /etc/ssh/ . Le client lit également la configuration du client dans ~/.ssh/config . Le serveur utilise un fichier sshd_config , qui contient la plupart des valeurs par défaut et contient des paires clé-valeur simples. Exemple:

Protocol 2 PasswordAuthentication yes ChallengeResponseAuthentication no UsePAM yes AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY X11Forwarding yes Subsystem sftp /usr/libexec/openssh/sftp-server

Créer votre clé SSH

Vous pouvez créer votre clé ssh en utilisant ssh-keygen, c'est un programme qui fait partie de l'installation de ssh. Pour cela, il suffit de l'exécuter et de suivre les instructions à l'écran.

Voici un exemple:

$ ssh-keygen Generating public/private rsa key pair.

Le répertoire par défaut où votre paire de clés ssh sera enregistrée se trouve dans le dossier .ssh de votre répertoire de base (vous pouvez le modifier en spécifiant un chemin valide) et le nom par défaut de la paire de clés est id_rsa pour la clé privée et id_rsa.pub pour la clé publique:

Enter file in which to save the key (/home/nasreddine/.ssh/id_rsa): /home/my_folder/my_ssh_key

Vous pouvez protéger votre clé SSH contre toute utilisation non autorisée en saisissant un mot de passe. Ceci est facultatif mais il est recommandé d'utiliser une phrase de passe. Notez que, comme pour tout autre programme de commande, lors de la saisie de votre phrase secrète, elle n’affiche rien à l’écran, mais elle est enregistrée:

Enter passphrase (empty for no passphrase): Enter same passphrase again:

Une fois que vous avez entré votre phrase secrète, ssh-keygen générera une clé et l'enregistrera dans le chemin que vous avez choisi:

Your identification has been saved in /home/my_folder/my_ssh_key. Your public key has been saved in /home/my_folder/my_ssh_key.pub.

Avaient fini. Maintenant, notre clé ssh est prête à être utilisée.

https://riptutorial.com/fr/home 4

Comment SSH dans une machine

Pour vous connecter à un compte d'utilisateur sur une machine avec SSH, vous pouvez utiliser la commande ssh username@ip_address . Il vous demandera un mot de passe. Si vous tapez le mot de passe correct, vous serez connecté au shell de cet utilisateur sur cette machine. Sinon, il vous demandera à nouveau le mot de passe.

Par exemple

root@dev10:~# ssh root@10.11.50.3 root@10.11.50.3's password: Welcome to Ubuntu 16.04 LTS (GNU/Linux 4.4.0-31-generic x86_64) Last login: Fri Jul 22 18:33:27 2016 from 10.11.50.10 root@dev2:~#

Si vous souhaitez utiliser une clé ssh spécifique pour vous connecter à une machine, utilisez le nom d'utilisateur ssh -i /path/to/ssh_secret_key username@host

Lorsque vous vous connectez à une machine pour la première fois, il vous sera demandé de vérifier l' empreinte de la machine cible. Il s’agit d’un mécanisme de sécurité permettant d’éviter une attaque de type « man-in-the-middle» . Vous pouvez voir l'empreinte de la machine cible en émettant cette commande sur la machine cible.

ssh-keygen -l -E md5 -f /etc/ssh/ssh_host_ecdsa_key.pub

Vous pouvez taper "oui" si les deux sont identiques. Il procédera à l'invite de mot de passe.

Exemple:

https://riptutorial.com/fr/home 5

root@dev10:~# ssh root@10.11.50.3 The authenticity of host '10.11.50.3 (10.11.50.3)' can't be established. ECDSA key fingerprint is dd:a3:de:cd:5b:01:cd:0b:b6:bc:b3:09:c2:c8:1a:68. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '10.11.50.3' (ECDSA) to the list of known hosts. root@10.11.50.3's password: Last login: Fri Jul 22 17:45:09 2016 from 10.11.1.71 root@dev2:~#

Ajout de votre clé publique à la liste des clés autorisées de l'utilisateur du serveur

Pour que ssh se ssh à un serveur, la clé publique de votre identité doit être ajoutée à la liste des clés approuvées. Le plus souvent, cela se fait par utilisateur:

ssh-copy-id -i ~/.ssh/<identity>.pub <user>@<hostname>

Ce qui peut aussi être fait manuellement:

cat ~/.ssh/<identity>.pub | ssh <user>@<hostname> 'cat >> ~/.ssh/authorized_keys'

Après avoir fait cela, vous devriez pouvoir vous connecter sans avoir à fournir le mot de passe de l'utilisateur lorsque vous transmettez le fichier d'identité à l'appel ssh .

Connexion depuis un script en utilisant un mot de passe

Lorsque vous avez vraiment besoin de scripter la connexion ssh , transférer le mot de passe dans la commande ssh ne fonctionne pas ( echo passw0rd | ssh host ). C'est parce que le mot de passe n'est pas lu depuis l'entrée standard, mais directement depuis TTY (téléscripteur, téléscripteur, télétype pour des raisons historiques).

Mais il existe sshpass outil sshpass qui fonctionne autour de ce problème. Il peut lire le mot de passe du paramètre, du fichier ou de la variable d'environnement. Mais notez qu'aucune de ces options ne répond aux exigences de sécurité pour un mot de passe!

$ sshpass -p passw0rd ssh host $ sshpass -f /secret/filename ssh host $ SSHPASS=passw0rd sshpass -e ssh host

Les options de ligne de commande peuvent être vues par d'autres utilisateurs sous ps (pendant l'exécution, elles sont masquées, mais pas pendant le démarrage et vous ne pouvez pas vous y fier):

... 23624 6216 pts/5 Ss Aug30 0:00 \_ /bin/bash

... 12812 1988 pts/5 S+ 08:50 0:00 | \_ sshpass -p passw0rd ssh host

... 45008 5796 pts/15 Ss+ 08:50 0:00 | \_ ssh host

Notez que les variables environemnet d'un processus sont également accessibles par d'autres

https://riptutorial.com/fr/home 6

processus sur le système utilisant le /proc/PID/environ .

Enfin, stocker le mot de passe dans le fichier peut sembler être la meilleure idée possible, mais utiliser les clés comme décrit dans les autres exemples est la meilleure manière d’utiliser ssh .

Fichier de configuration

Les fichiers de configuration OpenSSH sont utilisés pour la configuration qui doit être appliquée chaque fois que le client ssh est exécuté. La plupart des options de ligne de commande sont possibles dans les fichiers de configuration.

OpenSSH utilise la configuration des sources suivantes dans l'ordre:

Options de ligne de commande1. Fichier de configuration de l'utilisateur ~/.ssh/config2. Fichier de configuration système /etc/ssh/ssh_config3.

Les options de configuration sont répertoriées une par une dans les fichiers de configuration.

# This is a comment. # Parameter can be specified like this, separated with white space. StrictHostKeyChecking ask # Or parameter key and value may be separated with white space and =. ForwardX11 = yes # The parameter value can be quoted if it contains white space. IdentityFile "/file system/path with/white space"

La liste complète des paramètres de configuration possibles est disponible ici .

L'une des fonctionnalités les plus utiles du fichier de configuration est qu'il peut être divisé en fonction du nom d'hôte ou de l'adresse. De cette façon, vous pouvez avoir différentes configurations pour différents hôtes.

# Based on host name. Host host1.domain.com User user1 Host host2.domain.com User user2 # Or wildcard matching name or ip. Host *elastic-cloud.com 10.201.4.? User user3

Agent SSH

Si vous avez défini une longue phrase secrète et que vous ne souhaitez pas continuer à la saisir

https://riptutorial.com/fr/home 7

chaque fois que vous souhaitez vous connecter au serveur, vous pouvez utiliser SSH-Agent pour stocker votre phrase secrète lorsque vous êtes connecté à votre ordinateur.

Démarrez l'agent ssh en arrière-plan:

eval "$(ssh-agent -s)" # Agent pid 59566

Et ajoutez votre clé au ssh-agent, vous serez invité à saisir votre phrase secrète:

ssh-add ~/.ssh/matrix.ac # Enter passphrase for /home/osaka/.ssh/matrix.ac: # Identity added: /home/osaka/.ssh/matrix.ac (/home/osaka/.ssh/matrix.ac)

Terminé. Connectez-vous maintenant avec ssh user@matrix.ac et vous ne devriez pas avoir à saisir votre phrase secrète. Vous pouvez étendre cela en utilisant des programmes tels que gnome-keyring / seahorse, keychain et autres gestionnaires de clés.

Lire Démarrer avec Secure Shell en ligne: https://riptutorial.com/fr/ssh/topic/2070/demarrer-avec-secure-shell

https://riptutorial.com/fr/home 8

Chapitre 2: Commandes à distance

Examples

Bonjour le monde

Pour envoyer une commande distante via SSH (le serveur SSH doit être exécuté sur l'hôte distant), vous pouvez simplement écrire la commande après user @ machine .

ssh alice@example.com echo 'Hello World'

Bonjour le monde

Il renvoie la sortie à l'expéditeur, exécutée sur l'hôte distant.

Commandes interactives et basées sur un écran

De nombreuses commandes et programmes du côté distant sont basés sur un écran (par exemple, mc ) ou ils doivent demander un mot de passe (par exemple, sudo ) pour pouvoir exécuter ce type de programme que vous pouvez utiliser avec l'option -t .

ssh -t alice@example.com sudo ls /

[sudo] mot de passe pour alice:

bin root dev etc home lib mnt opt proc root exécuter usr var

Lire Commandes à distance en ligne: https://riptutorial.com/fr/ssh/topic/3297/commandes-a-distance

https://riptutorial.com/fr/home 9

Chapitre 3: Débogage des problèmes ssh

Examples

La clé privée n'est pas acceptée (débogage des clients OpenSSH)

Par défaut, la plupart des informations sont masquées par l'utilisateur. Vous pouvez utiliser les -v pour obtenir un journal détaillé de la tentative de connexion, qui identifiera généralement le problème en montrant pourquoi le comportement est différent de celui attendu.

Supposons que vous vous connectiez au serveur example.com utilisant ssh (ou un autre client OpenSSH comme sftp ou scp ) et que votre clé privée ne soit pas acceptée par le serveur et que le serveur demande le mot de passe (ou refuse la connexion):

$ ssh example.com user@example.com's password:

Essayez de lancer le ssh avec les commutateurs -vvv , qui écriront tous les messages de débogage. Ce sera beaucoup d'informations, mais après un certain temps, il est assez facile de comprendre que:

$ ssh -vvv example.com

Le problème le plus courant est que la clé ne se trouve pas à l'emplacement prévu. Vous pouvez vous attendre à des lignes similaires, se plaignant des fichiers manquants. Vérifier que votre fichier a bien été lu est un bon début:

debug1: identity file /home/username/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/username/.ssh/id_dsa-cert type -1

Nous pouvons continuer à la partie authentification. La clé peut être proposée, mais rejetée par le serveur, en raison d'un problème de configuration du serveur. Le journal pourrait ressembler à ceci:

debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: username@localhost debug3: send_pubkey_test debug3: send packet: type 50 debug2: we sent a publickey packet, wait for reply debug3: receive packet: type 51 debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

IDENTIFICATION HÔTE À DISTANCE A CHANGÉ!

https://riptutorial.com/fr/home 10

L'erreur commune à l'aide de ssh est de voir l'erreur comme

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is SHA256:L5ri/Xdgpuals893ej1z5F1wlg1n2YNeBf/tsABX+QQ. Please contact your system administrator. Add correct host key in /Users/username/.ssh/known_hosts to get rid of this message. Offending RSA key in /Users/username/.ssh/known_hosts:12 RSA host key for *IP address* has changed and you have requested strict checking. Host key verification failed.

Cela signifie que vous vous êtes connecté au même serveur auparavant et qu'il a été identifié à l'aide de différentes clés d'hôte. Si vous savez que vous avez modifié les clés du serveur, réinstallé le serveur ou l'administrateur du serveur a annoncé des modifications, il est généralement possible de supprimer l'ancienne clé et de laisser le ssh en stocker de nouvelles.

L'ancienne clé peut être supprimée de manière transparente à l'aide de ssh-keygen :

ssh-keygen -R *IP address*

Et la prochaine connexion devrait vous demander de vérifier la nouvelle empreinte digitale:

ssh192.168.0.128 The authenticity of host '192.168.0.128 (192.168.0.128)' can't be established. ECDSA key fingerprint is SHA256:L5ri/Xdgpuals893ej1z5F1wlg1n2YNeBf/tsABX+QQ. Are you sure you want to continue connecting (yes/no)?

Si vous n'êtes pas au courant de ce qui précède, le mieux est de contacter votre administrateur de serveur pour vous assurer que tout va bien. Dans le cas contraire, l'attaquant potentiel pourrait obtenir à la fois vos informations d'authentification et toutes les données transférées!

Connexion rejetée

Une erreur "Connexion refusée" se produit si votre client envoie une demande de connexion à un hôte de serveur distant et que l'hôte distant répond qu'il refuse d'accepter la demande. L'erreur "Connexion refusée" signifie essentiellement que l'ordinateur n'accepte pas les connexions à l'adresse IP et au port demandés.

"Connexion refusée" peut être provoquée par un pare-feu qui bloque les demandes de connexion. Un pare-feu configuré pour bloquer les connexions à un point de terminaison particulier peut être configuré pour supprimer les demandes de connexion - auquel cas le client ne recevra jamais de réponse et finira par expirer. Ou le pare-feu peut répondre aux demandes de connexion de connexion avec une réponse de refus.

Mis à part les pare-feu, dans le cas de SSH, la "connexion refusée" a quelques causes possibles:

https://riptutorial.com/fr/home 11

Vous pouvez utiliser le mauvais numéro de port pour vous connecter. Le numéro de port standard pour SSH est 22, mais certaines personnes exécutent le service ssh sur un autre port pour dissuader les tentatives d'accès non autorisées.

•

Vous pourriez essayer de vous connecter au mauvais ordinateur. Vous avez peut-être mal saisi le nom d'hôte ou l'adresse IP. Ou l'ordinateur peut utiliser une adresse attribuée dynamiquement qui a changé.

•

Le processus du serveur ssh n'est peut-être pas en cours d'exécution:

Il n'a peut-être pas encore démarré si le système est en cours de démarrage.○

Il a peut-être été désactivé par exemple lorsque le système est en mode mono-utilisateur.

○

Il a peut-être été mal configuré, ce qui l'a empêché de démarrer.○

L'ordinateur n'a peut-être pas de serveur SSH configuré. Les systèmes MS Windows n'incluent généralement pas de serveur SSH. Sur certains systèmes Linux, le serveur SSH peut être un composant facultatif. OS X inclut un serveur SSH, mais il est désactivé par défaut.

○

•

Le processus du serveur SSH n'écoute peut-être pas les connexions sur l'interface IP spécifique à laquelle vous essayez de vous connecter. La plupart des ordinateurs ont au moins deux interfaces IP, une interface "localhost" et une ou plusieurs interfaces réseau. Chaque interface active aura une adresse IP associée. Un serveur SSH est généralement configuré pour accepter les connexions sur toute interface IP. Mais il peut être configuré pour accepter des connexions uniquement sur des interfaces particulières. Dans ce cas, l'ordinateur refusera les connexions à une adresse IP que le serveur SSH n'écoute pas, même si la demande de connexion dispose du port correct.

•

Le serveur peut avoir un retard de demandes de connexion au même port. Ceci est rare et inhabituel, mais si l'hôte reçoit des demandes de connexion plus rapidement qu'il ne peut être traité, l'hôte finira par rejeter les nouvelles demandes de connexion.

•

Notez que, les pare - feu mis à part, « refus de connexion » signifie que vous communiquez avec l'ordinateur distant - il est tout simplement pas accepter votre demande de connexion.

La connexion a expiré

Une erreur "Connexion expirée" se produit lorsque le système distant ne répond pas à la tentative du client d'ouvrir une connexion TCP / IP. Les causes les plus courantes sont les suivantes:

Un pare-feu bloque la tentative de connexion sur le port que vous utilisez:Le pare-feu peut être côté client, en bloquant les connexions sortantes, côté serveur, en bloquant les connexions entrantes ou ailleurs sur le chemin.

○

Le problème de base pourrait être que vous utilisez le mauvais numéro de port.○

•

L'hôte auquel vous essayez de vous connecter peut être hors ligne.•Une partie du réseau entre le client et le serveur peut être interrompue ou interrompue.•Il pourrait y avoir un problème de routage réseau.•

https://riptutorial.com/fr/home 12

Le diagnostic de la cause racine des délais de connexion est difficile.

ssh_exchange_identification: lire: connexion réinitialisée par l'homologue

Ce message d'erreur peut être généré par le client OpenSSH ssh . Cela signifie que la connexion TCP entre le client et le serveur a été anormalement fermée par le serveur immédiatement après son acceptation. Les raisons courantes de ce message sont les suivantes:

Le processus du serveur SSH ne fonctionne pas correctement - par exemple, il a planté.•Un pare-feu, un routeur ou un autre périphérique réseau entre le client et le serveur interfère avec la connexion SSH.

•

Les phrases du message d'erreur indiquent précisément ce qui s'est passé:

ssh_exchange_identification: 1. Après qu'un client SSH se soit connecté à un serveur SSH, la première étape du démarrage du protocole SSH consiste pour le serveur à envoyer sa version du logiciel au client. Une erreur contenant "ssh_exchange_identification" indique que l'erreur s'est produite immédiatement après la connexion TCP, alors que le client attendait la version du logiciel du serveur.

Réinitialisation de la connexion: Une réinitialisation de la connexion signifie que la connexion TCP était "anormalement fermée". Vous pouvez l'obtenir si le processus logiciel contenant l'une des connexions TCP se bloque. Les pare-feu réseau peuvent être configurés pour utiliser les réinitialisations de connexion afin de bloquer les connexions TCP.

Par homologue signifie que la connexion TCP a été fermée de "l'autre extrémité" de la connexion. Dans ce cas, l’autre extrémité est le serveur SSH distant.

Notez que cette erreur n'indique aucun type d'échec d'authentification. Le serveur a fermé la connexion TCP immédiatement après l' avoir acceptée. Le client et le serveur n'ont encore échangé aucune donnée. Le serveur n'a pas encore envoyé de clé d'hôte au client et le client n'a pas encore essayé de s'authentifier auprès du serveur.

ssh_exchange_identification: connexion fermée par l'hôte distant

Ce message d'erreur peut être généré par le client OpenSSH ssh. Cela signifie que la connexion TCP entre le client et le serveur a été fermée par le serveur immédiatement après son acceptation. Ce message indique généralement que le serveur SSH a été configuré pour ne pas accepter les connexions du client pour une raison quelconque:

Le serveur peut être configuré pour refuser les connexions de l'adresse IP du client.•Le serveur peut être configuré avec une limite sur le nombre de connexions SSH actives.•Le client peut être connecté à quelque chose qui n'est pas un serveur SSH.•

Les phrases du message d'erreur indiquent précisément ce qui s'est passé:

ssh_exchange_identification: 1. Après qu'un client SSH se soit connecté à un serveur SSH, la première étape du démarrage du protocole SSH consiste pour le serveur à envoyer sa version du logiciel au client. Une erreur contenant "ssh_exchange_identification" indique que l'erreur s'est

https://riptutorial.com/fr/home 13

produite immédiatement après la connexion TCP, alors que le client attendait la version du logiciel du serveur.

Connexion fermée: Cela signifie que la connexion TCP a été fermée de manière normale. Cela indique que le serveur SSH a délibérément fermé la connexion. Cela contraste avec "Réinitialisation de la connexion", ce qui pourrait indiquer que le serveur SSH est tombé en panne ou a mal fonctionné.

par hôte distant signifie que la connexion TCP a été fermée de "l'autre extrémité" de la connexion. Dans ce cas, l’autre extrémité est le serveur SSH distant.

Notez que cette erreur n'indique aucun type d'échec d'authentification. Le serveur a fermé la connexion TCP immédiatement après l' avoir acceptée. Le client et le serveur n'ont encore échangé aucune donnée. Le serveur n'a pas encore envoyé de clé d'hôte au client et le client n'a pas encore essayé de s'authentifier auprès du serveur.

Lire Débogage des problèmes ssh en ligne: https://riptutorial.com/fr/ssh/topic/2926/debogage-des-problemes-ssh

https://riptutorial.com/fr/home 14

Chapitre 4: Gestion des fichiers distants via ssh

Introduction

cette rubrique doit décrire différentes manières d'utiliser ssh comme moyen sécurisé de gérer des fichiers sur des machines distantes

Examples

Montage du répertoire distant via ssh

Vous pouvez monter un répertoire distant via ssh en utilisant sshfs. Sshfs ne vient pas par défaut sur Ubuntu, vous devez donc d'abord l'installer en utilisant sudo apt-get install sshfs . Vous pouvez ensuite monter le répertoire distant sur votre machine locale comme ceci

sshfs user@xxx.xxx.xxx.xxx:/remotedir /localdir

Notez que le localdir doit être présent avant d'essayer de monter le remotedir. Si le répertoire local n'est pas vide, sshfs se plaindra et abandonnera. Vous pouvez le forcer à monter dans le répertoire non vide en utilisant une option non vide comme celle-ci

sshfs -o nonempty user@xxx.xxx.xxx.xxx:/remotedir /localdir

Une fois que vous avez démonté le localdir, les fichiers locaux seront à nouveau visibles.

Déplacement de fichiers entre serveurs via ssh

Une des façons de déplacer des fichiers entre serveurs consiste à utiliser la commande scp . La commande de copie sécurisée utilise ssh pour transférer des données. L’exemple simple de copie d’un fichier du serveur local vers le serveur distant est

scp /localdir/localfile user@xxx.xxx.xxx.xxx:/remotedir/remotefile

De même, copier un fichier d’un serveur distant vers un serveur local serait

scp user@xxx.xxx.xxx.xxx:/remotedir/remotefile /localdir/localfile

Lire Gestion des fichiers distants via ssh en ligne: https://riptutorial.com/fr/ssh/topic/9693/gestion-des-fichiers-distants-via-ssh

https://riptutorial.com/fr/home 15

Chapitre 5: Travailler avec des clés ssh

Examples

Convertir PPK (clé PuTTY) au format OpenSSH

Vous pourriez recevoir de votre clé privée pair au format PPK, qui semble ne pas fonctionner dans OpenSSH (ligne de commande ssh ). Le client demandera la phrase secrète à cause du bogue OpenSSH .

$ ssh -i mykey.ppk example.com Enter passphrase for mykey.ppk:

Vous devez convertir la clé au format OpenSSH à l'aide de PuTTYgen (version de ligne de commande):

puttygen mykey.ppk -o mykey.key -O private-openssh

Ou en version GUI:

Ouvrir PuttyGen•Cliquez sur Charger•Chargez votre clé privée•Aller aux conversions -> Exporter OpenSSH et exporter votre clé privée•Copiez votre clé privée dans ~/.ssh/id_rsa•

Source: réponse SO, réponse Unix SE

Lire Travailler avec des clés ssh en ligne: https://riptutorial.com/fr/ssh/topic/7861/travailler-avec-des-cles-ssh

https://riptutorial.com/fr/home 16

Chapitre 6: Tuer une session SSH sans réponse

Introduction

Parfois, votre session SSH ne répond plus. Vous pouvez facilement sortir de cette session en utilisant l'astuce suivante.

Examples

Tuer une session SSH en utilisant le caractère d'échappement

Par défaut, le caractère d'échappement est ~ .

Allez-y et tapez ~. dans votre session SSH ouverte.

Après avoir appuyé sur Entrer, votre session se terminera immédiatement.

Allez-y et essayez-le dans n'importe quelle session, cela fonctionne indépendamment de la réactivité de votre session.

Lire Tuer une session SSH sans réponse en ligne: https://riptutorial.com/fr/ssh/topic/8797/tuer-une-session-ssh-sans-reponse

https://riptutorial.com/fr/home 17

Chapitre 7: Tunnels inverses

Examples

OpenSSH

La création d'un tunnel ssh inversé ne prend qu'un seul commutateur -R vers la commande d'origine.

Ligne de commande

Supposons que vous vous connectiez à example.com tant guest utilisateur à l'aide d'une commande ssh guest@example.com . Ouvrir le tunnel inverse peut ressembler à ceci:

ssh -R 2222:localhost:22 guest@example.com

Il ouvrira un port 2222 sur le serveur distant (interface de bouclage uniquement) et chaque connexion à ce port sera transmise au serveur ssh de votre ordinateur local (port 22 ).

Cela suppose également que vous avez autorisé les options AllowTcpForwarding yes et PermitOpen any dans votre sshd_config sur votre serveur. Sinon, il échouera avec une erreur

open failed: administratively prohibited: open failed

Si vous souhaitez autoriser le port transféré à être accessible sur d'autres adresses réseau (que localhost ), vous devez également autoriser GatewayPorts yes et utiliser une adresse IP ou un nom d'hôte ou une adresse IP:

ssh -R 2222:example.com:22 guest@example.com

Configuration

De plus, vous pouvez spécifier le transfert de votre port distant dans votre ~/.ssh/config pour éviter de taper la même ligne chaque fois que vous vous connectez. Une bonne pratique pourrait être de configurer également un alias pour l'hôte, qui aura ce transfert, si vous vous connectez fréquemment à votre hôte et que vous ne voulez pas lancer le transfert de port à chaque fois:

Host example.com-R Hostname example.com User guest RemoteForward 2222 localhost:22

puis créez un transfert de port à distance en utilisant simplement ssh example.com-R

https://riptutorial.com/fr/home 18

Courir en arrière-plan

La redirection de port peut être simplement exécutée en arrière-plan à l'aide des commutateurs -N (ne pas exécuter la commande à distance, uniquement le transfert), -f (aller en arrière-plan après authentification), -T (désactiver l'allocation TTY distante). Mettre tous ensemble:

ssh -NTfR 2222:localhost:22 guest@example.com

Lire Tunnels inverses en ligne: https://riptutorial.com/fr/ssh/topic/5689/tunnels-inverses

https://riptutorial.com/fr/home 19

Crédits

S. No

Chapitres Contributeurs

1Démarrer avec Secure Shell

Community, dreftymac, Harikrishnan, Jakuje, jalanb, Joe Block, jPlatte, Lernkurve, Marek Skiba, mszymborski, Nasreddine, Osaka, Piotr Dobrysiak, ygram

2Commandes à distance

deepmax, Jakuje

3Débogage des problèmes ssh

Jakuje, Joe Block, Kenster, Martin Prikryl, Stephen C

4Gestion des fichiers distants via ssh

user

5Travailler avec des clés ssh

Jakuje

6Tuer une session SSH sans réponse

leifg

7 Tunnels inverses Jakuje

https://riptutorial.com/fr/home 20