SSH Essentials : Travailler avec des serveurs, des clients et des clés SSH
Introduction
SSH est un protocole sécurisé utilisé comme principal moyen de connexion à distance aux serveurs Linux. Il fournit une interface textuelle en créant un shell distant. Après la connexion, toutes les commandes que vous tapez dans votre terminal local sont envoyées au serveur distant et y sont exécutées.
Dans ce guide de style feuille de triche, nous couvrirons quelques façons courantes de se connecter avec SSH pour atteindre vos objectifs. Cela peut être utilisé comme référence rapide lorsque vous avez besoin de savoir comment vous connecter ou configurer votre serveur de différentes manières.
Comment utiliser ce guide
- Lisez d'abord la section SSH Overview si vous n'êtes pas familiarisé avec SSH en général ou si vous débutez.
- Utilisez les sections suivantes qui s'appliquent à ce que vous essayez d'accomplir. La plupart des sections ne reposent sur aucune autre, vous pouvez donc utiliser les exemples suivants indépendamment.
- Utilisez le menu Contenu sur le côté gauche de cette page (pour les grandes largeurs de page) ou la fonction de recherche de votre navigateur pour localiser les sections dont vous avez besoin.
- Copiez et collez les exemples de ligne de commande donnés, en remplaçant les valeurs
highlightedpar vos propres valeurs.
Présentation de SSH
Le moyen le plus courant de se connecter à un serveur Linux distant est via SSH. SSH signifie Secure Shell et fournit un moyen sûr et sécurisé d'exécuter des commandes, d'apporter des modifications et de configurer des services à distance. Lorsque vous vous connectez via SSH, vous vous connectez à l'aide d'un compte qui existe sur le serveur distant.
Comment fonctionne SSH
Lorsque vous vous connectez via SSH, vous serez déposé dans une session shell, qui est une interface textuelle où vous pouvez interagir avec votre serveur. Pendant la durée de votre session SSH, toutes les commandes que vous saisissez dans votre terminal local sont envoyées via un tunnel SSH crypté et exécutées sur votre serveur.
La connexion SSH est implémentée à l'aide d'un modèle client-serveur. Cela signifie que pour qu'une connexion SSH soit établie, la machine distante doit exécuter un logiciel appelé démon SSH. Ce logiciel écoute les connexions sur un port réseau spécifique, authentifie les demandes de connexion et génère l'environnement approprié si l'utilisateur fournit les informations d'identification correctes.
L'ordinateur de l'utilisateur doit disposer d'un client SSH. Il s'agit d'un logiciel qui sait comment communiquer à l'aide du protocole SSH et qui peut recevoir des informations sur l'hôte distant auquel se connecter, le nom d'utilisateur à utiliser et les informations d'identification à transmettre pour s'authentifier. Le client peut également spécifier certains détails sur le type de connexion qu'il souhaite établir.
Comment SSH authentifie les utilisateurs
Les clients s'authentifient généralement soit à l'aide de mots de passe (moins sécurisés et déconseillés) soit de clés SSH, qui sont très sécurisées.
Les connexions par mot de passe sont cryptées et faciles à comprendre pour les nouveaux utilisateurs. Cependant, les robots automatisés et les utilisateurs malveillants essaient souvent à plusieurs reprises de s'authentifier sur des comptes qui autorisent les connexions par mot de passe, ce qui peut entraîner des compromis de sécurité. Pour cette raison, nous vous recommandons de toujours configurer l'authentification basée sur une clé SSH pour la plupart des configurations.
Les clés SSH sont un ensemble correspondant de clés cryptographiques qui peuvent être utilisées pour l'authentification. Chaque ensemble contient une clé publique et une clé privée. La clé publique peut être partagée librement sans souci, tandis que la clé privée doit être gardée avec vigilance et ne jamais être exposée à qui que ce soit.
Pour s'authentifier à l'aide de clés SSH, un utilisateur doit disposer d'une paire de clés SSH sur son ordinateur local. Sur le serveur distant, la clé publique doit être copiée dans un fichier du répertoire personnel de l'utilisateur à ~/.ssh/authorized_keys. Ce fichier contient une liste de clés publiques, une par ligne, autorisées à se connecter à ce compte.
Lorsqu'un client se connecte à l'hôte, souhaitant utiliser l'authentification par clé SSH, il informera le serveur de cette intention et indiquera au serveur quelle clé publique utiliser. Le serveur vérifie ensuite la clé publique dans son fichier authorized_keys, génère une chaîne aléatoire et la chiffre à l'aide de la clé publique. Ce message chiffré ne peut être déchiffré qu'avec la clé privée associée. Le serveur enverra ce message crypté au client pour tester s'il possède réellement la clé privée associée.
Dès réception de ce message, le client le déchiffrera à l'aide de la clé privée et combinera la chaîne aléatoire révélée avec un identifiant de session préalablement négocié. Il génère ensuite un hachage MD5 de cette valeur et le retransmet au serveur. Le serveur avait déjà le message d'origine et l'ID de session, il peut donc comparer un hachage MD5 généré par ces valeurs et déterminer que le client doit avoir la clé privée.
Maintenant que vous savez comment fonctionne SSH, nous pouvons commencer à discuter de quelques exemples pour démontrer différentes façons de travailler avec SSH.
Génération et utilisation de clés SSH
Cette section explique comment générer des clés SSH sur une machine cliente et distribuer la clé publique aux serveurs où elles doivent être utilisées. C'est une bonne section pour commencer si vous n'avez pas encore généré de clés en raison de la sécurité accrue qu'elle permet pour les connexions futures.
Génération d'une paire de clés SSH
La génération d'une nouvelle paire de clés publique et privée SSH sur votre ordinateur local est la première étape vers l'authentification auprès d'un serveur distant sans mot de passe. À moins qu'il n'y ait une bonne raison de ne pas le faire, vous devez toujours vous authentifier à l'aide de clés SSH.
Un certain nombre d'algorithmes cryptographiques peuvent être utilisés pour générer des clés SSH, notamment RSA, DSA et ECDSA. Les clés RSA sont généralement préférées et constituent le type de clé par défaut.
Pour générer une paire de clés RSA sur votre ordinateur local, tapez :
ssh-keygen
Generating public/private rsa key pair. Enter file in which to save the key (/home/demo/.ssh/id_rsa):
Cette invite vous permet de choisir l'emplacement de stockage de votre clé privée RSA. Appuyez sur ENTER pour laisser cela par défaut, ce qui les stockera dans le répertoire caché .ssh dans le répertoire personnel de votre utilisateur. Laisser l'emplacement par défaut sélectionné permettra à votre client SSH de trouver les clés automatiquement.
Enter passphrase (empty for no passphrase): Enter same passphrase again:
L'invite suivante vous permet d'entrer une phrase de passe d'une longueur arbitraire pour sécuriser votre clé privée. Par défaut, vous devrez entrer n'importe quelle phrase de passe que vous avez définie ici chaque fois que vous utilisez la clé privée, comme mesure de sécurité supplémentaire. N'hésitez pas à appuyer sur ENTER pour laisser ce champ vide si vous ne souhaitez pas de phrase secrète. Gardez cependant à l'esprit que cela permettra à quiconque prend le contrôle de votre clé privée de se connecter à vos serveurs.
Si vous choisissez d'entrer une phrase de passe, rien ne s'affichera lors de la saisie. Il s'agit d'une mesure de sécurité.
OutputYour identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is: 8c:e9:7c:fa:bf:c4:e5:9c:c9:b8:60:1f:fe:1c:d3:8a [email protected] The key's randomart image is: +--[ RSA 2048]----+ | | | | | | | + | | o S . | | o . * + | | o + = O . | | + = = + | | ....Eo+ | +-----------------+
Cette procédure a généré une paire de clés RSA SSH, située dans le répertoire caché .ssh du répertoire personnel de votre utilisateur. Ces fichiers sont :
~/.ssh/id_rsa: La clé privée. NE PARTAGEZ PAS CE FICHIER !~/.ssh/id_rsa.pub: La clé publique associée. Cela peut être partagé librement sans conséquence.
Générer une paire de clés SSH avec un plus grand nombre de bits
Les clés SSH sont de 2048 bits par défaut. Ceci est généralement considéré comme suffisant pour la sécurité, mais vous pouvez spécifier un plus grand nombre de bits pour une clé plus renforcée.
Pour ce faire, incluez l'argument -b avec le nombre de bits souhaité. La plupart des serveurs prennent en charge les clés d'une longueur d'au moins 4096 bits. Les clés plus longues peuvent ne pas être acceptées à des fins de protection DDOS :
ssh-keygen -b 4096
Si vous aviez précédemment créé une clé différente, il vous sera demandé si vous souhaitez écraser votre clé précédente :
Overwrite (y/n)?
Si vous choisissez "oui", votre clé précédente sera écrasée et vous ne pourrez plus vous connecter aux serveurs utilisant cette clé. Pour cette raison, veillez à écraser les clés avec prudence.
Suppression ou modification de la phrase secrète d'une clé privée
Si vous avez généré une phrase de passe pour votre clé privée et que vous souhaitez la modifier ou la supprimer, vous pouvez le faire facilement.
Remarque : Pour modifier ou supprimer la phrase secrète, vous devez connaître la phrase secrète d'origine. Si vous avez perdu la phrase secrète de la clé, il n'y a aucun recours et vous devrez générer une nouvelle paire de clés.
Pour modifier ou supprimer la phrase secrète, tapez simplement :
ssh-keygen -p
Enter file in which the key is (/root/.ssh/id_rsa):
Vous pouvez saisir l'emplacement de la clé que vous souhaitez modifier ou appuyer sur ENTER pour accepter la valeur par défaut :
Enter old passphrase:
Saisissez l'ancienne phrase de passe que vous souhaitez modifier. Vous serez alors invité à saisir une nouvelle phrase secrète :
Enter new passphrase (empty for no passphrase): Enter same passphrase again:
Ici, entrez votre nouvelle phrase de passe ou appuyez sur ENTER pour supprimer la phrase de passe.
Affichage de l'empreinte digitale de la clé SSH
Chaque paire de clés SSH partage une seule "empreinte digitale" cryptographique qui peut être utilisée pour identifier de manière unique les clés. Cela peut être utile dans diverses situations.
Pour connaître l'empreinte d'une clé SSH, tapez :
ssh-keygen -l
Enter file in which the key is (/root/.ssh/id_rsa):
Vous pouvez appuyer sur ENTER s'il s'agit de l'emplacement correct de la clé, sinon entrez l'emplacement révisé. Vous recevrez une chaîne contenant la longueur en bits de la clé, l'empreinte digitale, le compte et l'hôte pour lesquels elle a été créée, ainsi que l'algorithme utilisé :
Output4096 8e:c4:82:47:87:c2:26:4b:68:ff:96:1a:39:62:9e:4e [email protected] (RSA)
Copie de votre clé SSH publique sur un serveur avec SSH-Copy-ID
Pour copier votre clé publique sur un serveur, vous permettant de vous authentifier sans mot de passe, plusieurs approches peuvent être adoptées.
Si vous avez actuellement un accès SSH basé sur un mot de passe configuré sur votre serveur et que l'utilitaire ssh-copy-id est installé, il s'agit d'un processus simple. L'outil ssh-copy-id est inclus dans de nombreux packages OpenSSH de distributions Linux, il est donc très probable qu'il soit installé par défaut.
Si vous avez cette option, vous pouvez facilement transférer votre clé publique en tapant :
ssh-copy-id [email protected]_host
Cela vous demandera le mot de passe du compte utilisateur sur le système distant :
The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. Are you sure you want to continue connecting (yes/no)? yes /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys [email protected]'s password:
Après avoir saisi le mot de passe, le contenu de votre clé ~/.ssh/id_rsa.pub sera ajouté à la fin du fichier ~/.ssh/authorized_keys du compte utilisateur :
OutputNumber of key(s) added: 1 Now try logging into the machine, with: "ssh '[email protected]'" and check to make sure that only the key(s) you wanted were added.
Vous pouvez maintenant vous connecter à ce compte sans mot de passe :
ssh [email protected]_host
Copie de votre clé SSH publique sur un serveur sans SSH-Copy-ID
Si vous ne disposez pas de l'utilitaire ssh-copy-id, mais que vous disposez toujours d'un accès SSH basé sur un mot de passe au serveur distant, vous pouvez copier le contenu de votre clé publique d'une manière différente.
Vous pouvez afficher le contenu de la clé et le diriger vers la commande ssh. Du côté distant, vous pouvez vous assurer que le répertoire ~/.ssh existe, puis ajouter le contenu redirigé dans le fichier ~/.ssh/authorized_keys :
cat ~/.ssh/id_rsa.pub | ssh [email protected]_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
Il vous sera demandé de fournir le mot de passe du compte distant :
The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. Are you sure you want to continue connecting (yes/no)? yes [email protected]'s password:
Après avoir entré le mot de passe, votre clé sera copiée, vous permettant de vous connecter sans mot de passe :
ssh [email protected]_IP_host
Copie manuelle de votre clé SSH publique sur un serveur
Si vous ne disposez pas d'un accès SSH basé sur un mot de passe, vous devrez ajouter manuellement votre clé publique au serveur distant.
Sur votre ordinateur local, vous pouvez trouver le contenu de votre fichier de clé publique en tapant :
cat ~/.ssh/id_rsa.pub
Outputssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== [email protected]
Vous pouvez copier cette valeur et la coller manuellement à l'emplacement approprié sur le serveur distant. Vous devrez vous connecter au serveur distant par d'autres moyens (comme la console Web DigitalOcean).
Sur le serveur distant, créez le répertoire ~/.ssh s'il n'existe pas déjà :
mkdir -p ~/.ssh
Ensuite, vous pouvez créer ou ajouter le fichier ~/.ssh/authorized_keys en tapant :
echo public_key_string >> ~/.ssh/authorized_keys
Vous devriez maintenant pouvoir vous connecter au serveur distant sans mot de passe.
Instructions de connexion de base
La section suivante couvrira certaines des bases sur la façon de se connecter à un serveur avec SSH.
Connexion à un serveur distant
Pour vous connecter à un serveur distant et y ouvrir une session shell, vous pouvez utiliser la commande ssh.
La forme la plus simple suppose que votre nom d'utilisateur sur votre machine locale est le même que celui sur le serveur distant. Si tel est le cas, vous pouvez vous connecter en utilisant :
ssh remote_host
Si votre nom d'utilisateur est différent sur le serveur distant, vous devez transmettre le nom de l'utilisateur distant comme ceci :
ssh [email protected]_host
Lors de votre première connexion à un nouvel hôte, vous verrez un message qui ressemble à ceci :
The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. Are you sure you want to continue connecting (yes/no)? yes
Tapez yes pour accepter l'authenticité de l'hôte distant.
Si vous utilisez l'authentification par mot de passe, vous serez invité ici à saisir le mot de passe du compte distant. Si vous utilisez des clés SSH, vous serez invité à entrer la phrase de passe de votre clé privée si elle est définie, sinon vous serez connecté automatiquement.
Exécution d'une seule commande sur un serveur distant
Pour exécuter une seule commande sur un serveur distant au lieu de lancer une session shell, vous pouvez ajouter la commande après les informations de connexion, comme ceci :
ssh [email protected]_host command_to_run
Cela se connectera à l'hôte distant, s'authentifiera avec vos informations d'identification et exécutera la commande que vous avez spécifiée. La connexion se fermera immédiatement après.
Connexion à un serveur avec un port différent
Par défaut, le démon SSH sur un serveur s'exécute sur le port 22. Votre client SSH supposera que c'est le cas lors de la tentative de connexion. Si votre serveur SSH écoute sur un port non standard (ceci est démontré dans une section ultérieure), vous devrez spécifier le nouveau numéro de port lors de la connexion avec votre client.
Vous pouvez le faire en spécifiant le numéro de port avec l'option -p :
ssh -p port_num [email protected]_host
Pour éviter d'avoir à le faire chaque fois que vous vous connectez à votre serveur distant, vous pouvez créer ou modifier un fichier de configuration dans le répertoire ~/.ssh du répertoire d'accueil de votre ordinateur local.
Modifiez ou créez le fichier maintenant en saisissant :
nano ~/.ssh/config
Ici, vous pouvez définir des options de configuration spécifiques à l'hôte. Pour spécifier votre nouveau port, utilisez un format comme celui-ci :
~/.ssh/config
Host remote_alias
HostName remote_host
Port port_num
Cela vous permettra de vous connecter sans spécifier le numéro de port spécifique sur la ligne de commande.
Ajout de vos clés SSH à un agent SSH pour éviter de saisir la phrase secrète
Si vous avez une phrase secrète sur votre clé SSH privée, vous serez invité à saisir la phrase secrète chaque fois que vous l'utiliserez pour vous connecter à un hôte distant.
Pour éviter d'avoir à le faire à plusieurs reprises, vous pouvez exécuter un agent SSH. Ce petit utilitaire stocke votre clé privée après avoir entré la phrase de passe pour la première fois. Il sera disponible pendant toute la durée de votre session de terminal, vous permettant de vous connecter à l'avenir sans ressaisir la phrase de passe.
Ceci est également important si vous devez transférer vos informations d'identification SSH (voir plus loin).
Pour démarrer l'agent SSH, saisissez ce qui suit dans votre session de terminal locale :
eval $(ssh-agent)
OutputAgent pid 10891
Cela démarrera le programme de l'agent et le placera en arrière-plan. Maintenant, vous devez ajouter votre clé privée à l'agent, afin qu'il puisse gérer votre clé :
ssh-add
Enter passphrase for /home/demo/.ssh/id_rsa: Identity added: /home/demo/.ssh/id_rsa (/home/demo/.ssh/id_rsa)
Vous devrez saisir votre phrase de passe (si elle est définie). Ensuite, votre fichier d'identité est ajouté à l'agent, ce qui vous permet d'utiliser votre clé pour vous connecter sans avoir à ressaisir la phrase secrète.
Transfert de vos informations d'identification SSH à utiliser sur un serveur
Si vous souhaitez pouvoir vous connecter sans mot de passe à un serveur depuis un autre serveur, vous devrez transmettre vos informations de clé SSH. Cela vous permettra de vous authentifier auprès d'un autre serveur via le serveur auquel vous êtes connecté, en utilisant les informations d'identification sur votre ordinateur local.
Pour commencer, vous devez avoir votre agent SSH démarré et votre clé SSH ajoutée à l'agent (voir plus haut). Une fois cela fait, vous devez vous connecter à votre premier serveur en utilisant l'option -A. Cela transmet vos informations d'identification au serveur pour cette session :
ssh -A [email protected]_host
À partir de là, vous pouvez vous connecter en SSH à tout autre hôte auquel votre clé SSH est autorisée à accéder. Vous vous connecterez comme si votre clé SSH privée se trouvait sur ce serveur.
Options de configuration côté serveur
Cette section contient certaines options de configuration côté serveur courantes qui peuvent déterminer la manière dont votre serveur répond et quels types de connexions sont autorisés.
Désactivation de l'authentification par mot de passe
Si vous avez des clés SSH configurées, testées et fonctionnent correctement, il est probablement judicieux de désactiver l'authentification par mot de passe. Cela empêchera tout utilisateur de se connecter avec SSH à l'aide d'un mot de passe.
Pour cela, connectez-vous à votre serveur distant et ouvrez le fichier /etc/ssh/sshd_config avec les privilèges root ou sudo :
sudo nano /etc/ssh/sshd_config
À l'intérieur du fichier, recherchez la directive PasswordAuthentication. S'il est commenté, décommentez-le. Réglez-le sur no pour désactiver les connexions par mot de passe :
/etc/ssh/sshd_config
PasswordAuthentication no
Une fois la modification effectuée, enregistrez et fermez le fichier. Pour mettre en œuvre les modifications, vous devez redémarrer le service SSH.
Sur Ubuntu/Debian :
sudo service ssh restart
Sur CentOS/Fedora :
sudo service sshd restart
Désormais, tous les comptes du système ne pourront pas se connecter avec SSH à l'aide de mots de passe.
Modification du port sur lequel le démon SSH s'exécute
Certains administrateurs suggèrent de modifier le port par défaut sur lequel SSH s'exécute. Cela peut aider à réduire le nombre de tentatives d'authentification auxquelles votre serveur est soumis par des robots automatisés.
Pour changer le port sur lequel le démon SSH écoute, vous devrez vous connecter à votre serveur distant. Ouvrez le fichier sshd_config sur le système distant avec les privilèges root, soit en vous connectant avec cet utilisateur, soit en utilisant sudo :
sudo nano /etc/ssh/sshd_config
Une fois à l'intérieur, vous pouvez modifier le port sur lequel SSH s'exécute en trouvant la spécification Port 22 et en la modifiant pour refléter le port que vous souhaitez utiliser. Par exemple, pour changer le port en 4444, mettez ceci dans votre fichier :
/etc/ssh/sshd_config
#Port 22 Port 4444
Enregistrez et fermez le fichier lorsque vous avez terminé. Pour implémenter les modifications, vous devez redémarrer le démon SSH.
Sur Ubuntu/Debian :
sudo service ssh restart
Sur CentOS/Fedora :
sudo service sshd restart
Après le redémarrage du démon, vous devrez vous authentifier en spécifiant le numéro de port (illustré dans une section précédente).
Limitation des utilisateurs pouvant se connecter via SSH
Pour limiter explicitement les comptes d'utilisateurs pouvant se connecter via SSH, vous pouvez adopter différentes approches, chacune impliquant la modification du fichier de configuration du démon SSH.
Sur votre serveur distant, ouvrez ce fichier maintenant avec les privilèges root ou sudo :
sudo nano /etc/ssh/sshd_config
La première méthode de spécification des comptes autorisés à se connecter consiste à utiliser la directive AllowUsers. Recherchez la directive AllowUsers dans le fichier. S'il n'en existe pas, créez-le n'importe où. Après la directive, répertoriez les comptes d'utilisateurs qui devraient être autorisés à se connecter via SSH :
/etc/ssh/sshd_config
AllowUsers user1 user2
Enregistrez et fermez le fichier. Redémarrez le démon pour implémenter vos modifications.
Sur Ubuntu/Debian :
sudo service ssh restart
Sur CentOS/Fedora :
sudo service sshd restart
Si vous êtes plus à l'aise avec la gestion des groupes, vous pouvez utiliser la directive AllowGroups à la place. Si tel est le cas, ajoutez simplement un seul groupe qui devrait être autorisé à accéder en SSH (nous allons créer ce groupe et ajouter des membres momentanément) :
/etc/ssh/sshd_config
AllowGroups sshmembers
Enregistrez et fermez le fichier.
Maintenant, vous pouvez créer un groupe système (sans répertoire personnel) correspondant au groupe que vous avez spécifié en tapant :
sudo groupadd -r sshmembers
Assurez-vous d'ajouter les comptes d'utilisateurs dont vous avez besoin à ce groupe. Cela peut être fait en tapant :
sudo usermod -a -G sshmembers user1 sudo usermod -a -G sshmembers user2
Maintenant, redémarrez le démon SSH pour implémenter vos modifications.
Sur Ubuntu/Debian :
sudo service ssh restart
Sur CentOS/Fedora :
sudo service sshd restart
Désactivation de la connexion racine
Il est souvent conseillé de désactiver complètement la connexion root via SSH après avoir configuré un compte utilisateur SSH disposant des privilèges sudo.
Pour ce faire, ouvrez le fichier de configuration du démon SSH avec root ou sudo sur votre serveur distant.
sudo nano /etc/ssh/sshd_config
À l'intérieur, recherchez une directive appelée PermitRootLogin. S'il est commenté, décommentez-le. Changez la valeur en "non":
/etc/ssh/sshd_config
PermitRootLogin no
Enregistrez et fermez le fichier. Pour implémenter vos modifications, redémarrez le démon SSH.
Sur Ubuntu/Debian :
sudo service ssh restart
Sur CentOS/Fedora :
sudo service sshd restart
Autoriser l'accès root pour des commandes spécifiques
Dans certains cas, vous souhaiterez peut-être désactiver l'accès root en général, mais l'activer afin de permettre à certaines applications de s'exécuter correctement. Un exemple de ceci pourrait être une routine de sauvegarde.
Cela peut être accompli via le fichier authorized_keys de l'utilisateur racine, qui contient les clés SSH autorisées à utiliser le compte.
Ajoutez la clé de votre ordinateur local que vous souhaitez utiliser pour ce processus (nous vous recommandons de créer une nouvelle clé pour chaque processus automatique) au fichier authorized_keys de l'utilisateur racine sur le serveur. Nous ferons une démonstration avec la commande ssh-copy-id ici, mais vous pouvez utiliser n'importe laquelle des méthodes de copie de clés dont nous parlons dans d'autres sections :
ssh-copy-id [email protected]_host
Maintenant, connectez-vous au serveur distant. Nous devrons ajuster l'entrée dans le fichier authorized_keys, donc ouvrez-le avec un accès root ou sudo :
sudo nano /root/.ssh/authorized_keys
Au début de la ligne avec la clé que vous avez téléchargée, ajoutez une liste command= qui définit la commande pour laquelle cette clé est valide. Cela doit inclure le chemin d'accès complet à l'exécutable, ainsi que tous les arguments :
/root/.ssh/authorized_keys
command="/path/to/command arg1 arg2" ssh-rsa ...
Enregistrez et fermez le fichier lorsque vous avez terminé.
Maintenant, ouvrez le fichier sshd_config avec les privilèges root ou sudo :
sudo nano /etc/ssh/sshd_config
Trouvez la directive PermitRootLogin et modifiez la valeur en forced-commands-only. Cela permettra uniquement aux connexions par clé SSH d'utiliser root lorsqu'une commande a été spécifiée pour la clé :
/etc/ssh/sshd_config
PermitRootLogin forced-commands-only
Enregistrez et fermez le fichier. Redémarrez le démon SSH pour mettre en œuvre vos modifications.
Sur Ubuntu/Debian :
sudo service ssh restart
Sur CentOS/Fedora :
sudo service sshd restart
Transférer les écrans d'application X au client
Le démon SSH peut être configuré pour transférer automatiquement l'affichage des applications X sur le serveur vers la machine cliente. Pour que cela fonctionne correctement, le client doit avoir un système X windows configuré et activé.
Pour activer cette fonctionnalité, connectez-vous à votre serveur distant et modifiez le fichier sshd_config en tant que root ou avec les privilèges sudo :
sudo nano /etc/ssh/sshd_config
Recherchez la directive X11Forwarding. S'il est commenté, décommentez-le. Créez-le si nécessaire et définissez la valeur sur "oui":
/etc/ssh/sshd_config
X11Forwarding yes
Enregistrez et fermez le fichier. Redémarrez votre démon SSH pour mettre en œuvre ces modifications.
Sur Ubuntu/Debian :
sudo service ssh restart
Sur CentOS/Fedora :
sudo service sshd restart
Pour se connecter au serveur et rediriger l'affichage d'une application, il faut passer l'option -X du client lors de la connexion :
ssh -X [email protected]_host
Les applications graphiques lancées sur le serveur via cette session doivent être affichées sur l'ordinateur local. Les performances peuvent être un peu lentes, mais elles sont très utiles à la rigueur.
Options de configuration côté client
Dans la section suivante, nous nous concentrerons sur certains ajustements que vous pouvez effectuer du côté client de la connexion.
Définition des informations de connexion spécifiques au serveur
Sur votre ordinateur local, vous pouvez définir des configurations individuelles pour certains ou tous les serveurs auxquels vous vous connectez. Ceux-ci peuvent être stockés dans le fichier ~/.ssh/config, qui est lu par votre client SSH chaque fois qu'il est appelé.
Créez ou ouvrez ce fichier dans votre éditeur de texte sur votre ordinateur local :
nano ~/.ssh/config
À l'intérieur, vous pouvez définir des options de configuration individuelles en introduisant chacune avec un mot-clé Host, suivi d'un alias. En dessous et en retrait, vous pouvez définir n'importe laquelle des directives trouvées dans la page de manuel ssh_config :
man ssh_config
Un exemple de configuration serait :
~/.ssh/config
Host testhost
HostName your_domain
Port 4444
User demo
Vous pouvez ensuite vous connecter à your_domain sur le port 4444 en utilisant le nom d'utilisateur demo en tapant simplement :
ssh testhost
Vous pouvez également utiliser des caractères génériques pour correspondre à plusieurs hôtes. Gardez à l'esprit que les correspondances ultérieures peuvent remplacer les précédentes. Pour cette raison, vous devriez mettre vos matchs les plus généraux en haut. Par exemple, vous pouvez par défaut toutes les connexions pour ne pas autoriser le transfert X, avec un remplacement pour your_domain en ayant ceci dans votre fichier :
~/.ssh/config
Host *
ForwardX11 no
Host testhost
HostName your_domain
ForwardX11 yes
Port 4444
User demo
Enregistrez et fermez le fichier lorsque vous avez terminé.
Maintenir les connexions actives pour éviter l'expiration du délai
Si vous vous retrouvez déconnecté des sessions SSH avant d'être prêt, il est possible que votre connexion expire.
Vous pouvez configurer votre client pour envoyer un paquet au serveur de temps en temps afin d'éviter cette situation :
Sur votre ordinateur local, vous pouvez le configurer pour chaque connexion en éditant votre fichier ~/.ssh/config. Ouvrez-le maintenant :
nano ~/.ssh/config
S'il n'en existe pas déjà, en haut du fichier, définissez une section qui correspondra à tous les hôtes. Réglez le ServerAliveInterval sur "120" pour envoyer un paquet au serveur toutes les deux minutes. Cela devrait suffire à notifier au serveur de ne pas fermer la connexion :
~/.ssh/config
Host *
ServerAliveInterval 120
Enregistrez et fermez le fichier lorsque vous avez terminé.
Désactivation de la vérification de l'hôte
Par défaut, chaque fois que vous vous connectez à un nouveau serveur, l'empreinte digitale de la clé d'hôte du démon SSH distant s'affiche.
The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. Are you sure you want to continue connecting (yes/no)? yes
Ceci est configuré pour que vous puissiez vérifier l'authenticité de l'hôte auquel vous essayez de vous connecter et repérer les instances où un utilisateur malveillant peut essayer de se faire passer pour l'hôte distant.
Dans certaines circonstances, vous souhaiterez peut-être désactiver cette fonctionnalité. Remarque : Cela peut représenter un risque important pour la sécurité, alors assurez-vous de savoir ce que vous faites si vous configurez votre système de cette manière.
Pour effectuer la modification, ouvrez le fichier ~/.ssh/config sur votre ordinateur local :
nano ~/.ssh/config
S'il n'en existe pas déjà, en haut du fichier, définissez une section qui correspondra à tous les hôtes. Définissez la directive StrictHostKeyChecking sur no pour ajouter automatiquement de nouveaux hôtes au fichier known_hosts. Définissez UserKnownHostsFile sur /dev/null pour ne pas avertir sur les hôtes nouveaux ou modifiés :
~/.ssh/config
Host *
StrictHostKeyChecking no
UserKnownHostsFile /dev/null
Vous pouvez activer la vérification au cas par cas en inversant ces options pour les autres hôtes. La valeur par défaut pour StrictHostKeyChecking est ask :
~/.ssh/config
Host *
StrictHostKeyChecking no
UserKnownHostsFile /dev/null
Host testhost
HostName your_domain
StrictHostKeyChecking ask
UserKnownHostsFile /home/demo/.ssh/known_hosts
Multiplexage SSH sur une seule connexion TCP
Dans certaines situations, l'établissement d'une nouvelle connexion TCP peut prendre plus de temps que vous ne le souhaiteriez. Si vous établissez plusieurs connexions à la même machine, vous pouvez profiter du multiplexage.
Le multiplexage SSH réutilise la même connexion TCP pour plusieurs sessions SSH. Cela supprime une partie du travail nécessaire pour établir une nouvelle session, accélérant éventuellement les choses. Limiter le nombre de connexions peut également être utile pour d'autres raisons.
Pour configurer le multiplexage, vous pouvez configurer manuellement les connexions ou vous pouvez configurer votre client pour qu'il utilise automatiquement le multiplexage lorsqu'il est disponible. Nous allons démontrer la deuxième option ici.
Pour configurer le multiplexage, modifiez le fichier de configuration de votre client SSH sur votre machine locale :
nano ~/.ssh/config
Si vous n'avez pas encore de définition d'hôte générique en haut du fichier, ajoutez-en une maintenant (comme Host *). Nous allons définir les valeurs ControlMaster, ControlPath et ControlPersist pour établir notre configuration de multiplexage.
Le ControlMaster doit être réglé sur "auto" pour pouvoir autoriser automatiquement le multiplexage si possible. Le ControlPath établira le chemin pour contrôler la prise. La première session créera ce socket et les sessions suivantes pourront le trouver car il est étiqueté par nom d'utilisateur, hôte et port.
Le réglage de l'option ControlPersist sur 1 permettra à la connexion principale initiale d'être mise en arrière-plan. Le 1 spécifie que la connexion TCP doit automatiquement se terminer une seconde après la fermeture de la dernière session SSH :
/.ssh/config
Host *
ControlMaster auto
ControlPath ~/.ssh/multiplex/%r@%h:%p
ControlPersist 1
Enregistrez et fermez le fichier lorsque vous avez terminé. Maintenant, nous devons réellement créer le répertoire que nous avons spécifié dans le chemin de contrôle :
mkdir ~/.ssh/multiplex
Désormais, toutes les sessions établies avec la même machine tenteront d'utiliser le socket et la connexion TCP existants. Lorsque la dernière session existe, la connexion sera interrompue après une seconde.
Si pour une raison quelconque vous avez besoin de contourner temporairement la configuration de multiplexage, vous pouvez le faire en passant le drapeau -S avec none :
ssh -S none [email protected]_host
Configuration des tunnels SSH
Tunneling autre trafic via un tunnel SSH sécurisé est un excellent moyen de contourner les paramètres de pare-feu restrictifs. C'est également un excellent moyen de crypter le trafic réseau autrement non crypté.
Configuration de la tunnellisation locale vers un serveur
Les connexions SSH peuvent être utilisées pour tunneliser le trafic des ports de l'hôte local vers les ports d'un hôte distant.
Une connexion locale est un moyen d'accéder à un emplacement réseau à partir de votre ordinateur local via votre hôte distant. Tout d'abord, une connexion SSH est établie avec votre hôte distant. Sur le serveur distant, une connexion est établie à une adresse réseau externe (ou interne) fournie par l'utilisateur et le trafic vers cet emplacement est tunnellisé vers votre ordinateur local sur un port spécifié.
Ceci est souvent utilisé pour créer un tunnel vers un environnement réseau moins restreint en contournant un pare-feu. Une autre utilisation courante consiste à accéder à une interface Web "localhost uniquement" à partir d'un emplacement distant.
Pour établir un tunnel local vers votre serveur distant, vous devez utiliser le paramètre -L lors de la connexion et vous devez fournir trois informations supplémentaires :
- Le port local sur lequel vous souhaitez accéder à la connexion par tunnel.
- L'hôte auquel vous voulez que votre hôte distant se connecte.
- Le port auquel vous voulez que votre hôte distant se connecte.
Ceux-ci sont donnés, dans l'ordre ci-dessus (séparés par des deux-points), comme arguments du drapeau -L. Nous utiliserons également le drapeau -f, qui fait passer SSH en arrière-plan avant l'exécution et le drapeau -N, qui n'ouvre pas de shell ou n'exécute pas de programme du côté distant.
Par exemple, pour vous connecter à your_domain sur le port 80 de votre hôte distant, rendant la connexion disponible sur votre machine locale sur le port 8888, vous pouvez taper :
ssh -f -N -L 8888:your_domain:80 [email protected]_host
Maintenant, si vous pointez votre navigateur Web local vers 127.0.0.1:8888, vous devriez voir tout contenu se trouvant sur your_domain sur le port 80.
Un guide plus général de la syntaxe est :
ssh -L your_port:site_or_IP_to_access:site_port [email protected]
Puisque la connexion est en arrière-plan, vous devrez trouver son PID pour la tuer. Vous pouvez le faire en recherchant le port que vous avez redirigé :
ps aux | grep 8888
Output1001 5965 0.0 0.0 48168 1136 ? Ss 12:28 0:00 ssh -f -N -L 8888:your_domain:80 [email protected]_host 1001 6113 0.0 0.0 13648 952 pts/2 S+ 12:37 0:00 grep --colour=auto 8888
Vous pouvez ensuite tuer le processus en ciblant le PID, qui est le numéro dans la deuxième colonne de la ligne qui correspond à votre commande SSH :
kill 5965
Une autre option consiste à démarrer la connexion sans le drapeau -f. Cela gardera la connexion au premier plan, vous empêchant d'utiliser la fenêtre du terminal pendant la durée du transfert. L'avantage est que vous pouvez facilement tuer le tunnel en tapant CTRL-C.
Configuration de la tunnellisation à distance vers un serveur
Les connexions SSH peuvent être utilisées pour tunneliser le trafic des ports de l'hôte local vers les ports d'un hôte distant.
Dans un tunnel distant, une connexion est établie avec un hôte distant. Lors de la création du tunnel, un port distant est spécifié. Ce port, sur l'hôte distant, sera ensuite tunnellisé vers une combinaison d'hôte et de port qui est connectée à partir de l'ordinateur local. Cela permettra à l'ordinateur distant d'accéder à un hôte via votre ordinateur local.
Cela peut être utile si vous devez autoriser l'accès à un réseau interne qui est verrouillé sur les connexions externes. Si le pare-feu autorise les connexions out du réseau, cela vous permettra de vous connecter à une machine distante et de tunneliser le trafic de cette machine vers un emplacement sur le réseau interne.
Pour établir un tunnel distant vers votre serveur distant, vous devez utiliser le paramètre -R lors de la connexion et vous devez fournir trois informations supplémentaires :
- Port sur lequel l'hôte distant peut accéder à la connexion par tunnel.
- L'hôte auquel vous souhaitez que votre ordinateur local se connecte.
- Le port auquel vous voulez que votre ordinateur local se connecte.
Ceux-ci sont donnés, dans l'ordre ci-dessus (séparés par des deux-points), comme arguments du drapeau -R. Nous utiliserons également le drapeau -f, qui fait passer SSH en arrière-plan avant l'exécution et le drapeau -N, qui n'ouvre pas de shell ou n'exécute pas de programme du côté distant.
Par exemple, pour vous connecter à your_domain sur le port 80 de notre ordinateur local, rendant la connexion disponible sur notre hôte distant sur le port 8888, vous pouvez taper :
ssh -f -N -R 8888:your_domain:80 [email protected]_host
Maintenant, sur l'hôte distant, l'ouverture d'un navigateur Web sur 127.0.0.1:8888 vous permettrait de voir tout contenu se trouvant sur your_domain sur le port 80.
Un guide plus général de la syntaxe est :
ssh -R remote_port:site_or_IP_to_access:site_port [email protected]
Puisque la connexion est en arrière-plan, vous devrez trouver son PID pour la tuer. Vous pouvez le faire en recherchant le port que vous avez redirigé :
ps aux | grep 8888
Output1001 5965 0.0 0.0 48168 1136 ? Ss 12:28 0:00 ssh -f -N -R 8888:your_domain:80 [email protected]_host 1001 6113 0.0 0.0 13648 952 pts/2 S+ 12:37 0:00 grep --colour=auto 8888
Vous pouvez ensuite tuer le processus en ciblant le PID, qui est le numéro dans la deuxième colonne, de la ligne qui correspond à votre commande SSH :
kill 5965
Une autre option consiste à démarrer la connexion sans le drapeau -f. Cela gardera la connexion au premier plan, vous empêchant d'utiliser la fenêtre du terminal pendant la durée du transfert. L'avantage est que vous pouvez facilement tuer le tunnel en tapant CTRL-C.
Configuration de la tunnellisation dynamique vers un serveur distant
Les connexions SSH peuvent être utilisées pour tunneliser le trafic des ports de l'hôte local vers les ports d'un hôte distant.
Un tunnel dynamique est similaire à un tunnel local en ce sens qu'il permet à l'ordinateur local de se connecter à d'autres ressources via un hôte distant. Un tunnel dynamique le fait en spécifiant simplement un seul port local. Les applications qui souhaitent profiter de ce port pour le tunneling doivent pouvoir communiquer en utilisant le protocole SOCKS afin que les paquets puissent être correctement redirigés de l'autre côté du tunnel.
Le trafic transmis à ce port local sera envoyé à l'hôte distant. À partir de là, le protocole SOCKS sera interprété pour établir une connexion à l'emplacement final souhaité. Cette configuration permet à une application compatible SOCKS de se connecter à n'importe quel nombre d'emplacements via le serveur distant, sans plusieurs tunnels statiques.
Pour établir la connexion, nous passerons le drapeau -D avec le port local où nous souhaitons accéder au tunnel. Nous utiliserons également le drapeau -f, qui fait passer SSH en arrière-plan avant l'exécution et le drapeau -N, qui n'ouvre pas de shell ou n'exécute pas de programme du côté distant.
Par exemple, pour établir un tunnel sur le port 7777, vous pouvez taper :
ssh -f -N -D 7777 [email protected]_host
À partir de là, vous pouvez commencer à pointer votre application compatible SOCKS (comme un navigateur Web) vers le port que vous avez sélectionné. L'application enverra ses informations dans une socket associée au port.
La méthode de direction du trafic vers le port SOCKS diffère selon l'application. Par exemple, dans Firefox, l'emplacement général est Préférences > Avancé > Paramètres > Configurations manuelles du proxy. Dans Chrome, vous pouvez démarrer l'application avec l'indicateur --proxy-server= défini. Vous voudrez utiliser l'interface localhost et le port que vous avez redirigé.
Puisque la connexion est en arrière-plan, vous devrez trouver son PID pour la tuer. Vous pouvez le faire en recherchant le port que vous avez redirigé :
ps aux | grep 8888
Output1001 5965 0.0 0.0 48168 1136 ? Ss 12:28 0:00 ssh -f -N -D 7777 [email protected]_host 1001 6113 0.0 0.0 13648 952 pts/2 S+ 12:37 0:00 grep --colour=auto 8888
Vous pouvez ensuite tuer le processus en ciblant le PID, qui est le numéro dans la deuxième colonne, de la ligne qui correspond à votre commande SSH :
kill 5965
Une autre option consiste à démarrer la connexion sans le drapeau -f. Cela gardera la connexion au premier plan, vous empêchant d'utiliser la fenêtre du terminal pendant la durée du transfert. L'avantage est que vous pouvez facilement tuer le tunnel en tapant CTRL-C.
Utilisation des codes d'échappement SSH pour contrôler les connexions
Même après avoir établi une session SSH, il est possible d'exercer un contrôle sur la connexion depuis le terminal. Nous pouvons le faire avec quelque chose appelé codes d'échappement SSH, qui nous permettent d'interagir avec notre logiciel SSH local à partir d'une session.
Forcer une déconnexion du côté client (comment sortir d'une session bloquée ou gelée)
L'une des fonctionnalités les plus utiles d'OpenSSH qui passe largement inaperçue est la possibilité de contrôler certains aspects de la session de l'intérieur.
Ces commandes peuvent être exécutées en commençant par le caractère de contrôle ~ dans une session SSH. Les commandes de contrôle ne seront interprétées que si elles sont la première chose qui est tapée après une nouvelle ligne, donc appuyez toujours sur ENTREE une ou deux fois avant d'en utiliser une.
L'un des contrôles les plus utiles est la possibilité d'initier une déconnexion du client. Les connexions SSH sont généralement fermées par le serveur, mais cela peut être un problème si le serveur souffre de problèmes ou si la connexion a été interrompue. En utilisant une déconnexion côté client, la connexion peut être proprement fermée à partir du client.
Pour fermer une connexion depuis le client, utilisez le caractère de contrôle (~), avec un point. Si votre connexion rencontre des problèmes, vous serez probablement dans ce qui semble être une session de terminal bloquée. Tapez les commandes malgré l'absence de retour pour effectuer une déconnexion côté client :
[ENTER] ~.
La connexion devrait se fermer immédiatement, vous ramenant à votre session shell locale.
Placer une session SSH en arrière-plan
L'une des fonctionnalités les plus utiles d'OpenSSH qui passe largement inaperçue est la possibilité de contrôler certains aspects de la session depuis la connexion.
Ces commandes peuvent être exécutées en commençant par le caractère de contrôle ~ depuis une connexion SSH. Les commandes de contrôle ne seront interprétées que si elles sont la première chose qui est tapée après une nouvelle ligne, donc appuyez toujours sur ENTER une ou deux fois avant d'en utiliser une.
Une capacité que cela fournit est de mettre une session SSH en arrière-plan. Pour ce faire, nous devons fournir le caractère de contrôle (~) puis exécuter le raccourci clavier classique pour mettre en arrière-plan une tâche (CTRL-z) :
[ENTER] ~[CTRL-z]
Cela placera la connexion en arrière-plan, vous renvoyant à votre session shell locale. Pour revenir à votre session SSH, vous pouvez utiliser les mécanismes classiques de contrôle des tâches.
Vous pouvez immédiatement réactiver votre dernière tâche en arrière-plan en tapant :
fg
Si vous avez plusieurs tâches en arrière-plan, vous pouvez voir les travaux disponibles en tapant :
jobs
Output[1]+ Stopped ssh [email protected]_host [2] Stopped ssh [email protected]_host
Vous pouvez ensuite mettre n'importe laquelle des tâches au premier plan en utilisant l'index dans la première colonne avec un signe de pourcentage :
fg %2
Modification des options de transfert de port sur une connexion SSH existante
L'une des fonctionnalités les plus utiles d'OpenSSH qui passe largement inaperçue est la possibilité de contrôler certains aspects de la session depuis la connexion.
Ces commandes peuvent être exécutées en commençant par le caractère de contrôle ~ depuis une connexion SSH. Les commandes de contrôle ne seront interprétées que si elles sont la première chose qui est tapée après une nouvelle ligne, donc appuyez toujours sur ENTREE une ou deux fois avant d'en utiliser une.
Cela permet notamment à un utilisateur de modifier la configuration de la redirection de port après que la connexion a déjà été établie. Cela vous permet de créer ou de supprimer des règles de transfert de port à la volée.
Ces fonctionnalités font partie de l'interface de ligne de commande SSH, accessible pendant une session en utilisant le caractère de contrôle (~) et « C » :
[ENTER] ~C
ssh>
Vous recevrez une invite de commande SSH, qui contient un ensemble très limité de commandes valides. Pour voir les options disponibles, vous pouvez taper -h à partir de cette invite. Si rien n'est renvoyé, vous devrez peut-être augmenter la verbosité de votre sortie SSH en utilisant ~v plusieurs fois :
[ENTER] ~v ~v ~v ~C -h
Commands:
-L[bind_address:]port:host:hostport Request local forward
-R[bind_address:]port:host:hostport Request remote forward
-D[bind_address:]port Request dynamic forward
-KL[bind_address:]port Cancel local forward
-KR[bind_address:]port Cancel remote forward
-KD[bind_address:]port Cancel dynamic forward
Comme vous pouvez le voir, vous pouvez facilement mettre en œuvre l'une des options de transfert en utilisant les options appropriées (voir la section de transfert pour plus d'informations). Vous pouvez également détruire un tunnel avec la commande "kill" associée spécifiée avec un "K" avant la lettre de type de transfert. Par exemple, pour tuer un transfert local (-L), vous pouvez utiliser la commande -KL. Vous n'aurez qu'à fournir le port pour cela.
Ainsi, pour configurer un transfert de port local, vous pouvez taper :
[ENTER] ~C -L 8888:127.0.0.1:80
Le port 8888 de votre ordinateur local pourra désormais communiquer avec le serveur Web de l'hôte auquel vous vous connectez. Lorsque vous avez terminé, vous pouvez supprimer ce transfert en tapant :
[ENTER] ~C -KL 8888
Conclusion
Les instructions ci-dessus devraient couvrir la majorité des informations dont la plupart des utilisateurs auront besoin sur SSH au quotidien. Si vous avez d'autres conseils ou souhaitez partager vos configurations et méthodes préférées, n'hésitez pas à utiliser les commentaires ci-dessous.
