Essentiels de SSH : Travailler avec des serveurs, des clients et des clés SSH

Introduction

SSH est un protocole sécurisé utilisé comme principal moyen de se connecter à des serveurs Linux à distance. Il offre une interface textuelle en ouvrant un shell distant. Après la connexion, toutes les commandes que vous tapez dans votre terminal local sont envoyées au serveur distant et exécutées là-bas.

Dans ce guide de style fiche de triche, nous allons aborder quelques méthodes courantes de connexion avec SSH pour atteindre vos objectifs. Cela peut être utilisé comme référence rapide lorsque vous devez savoir comment vous connecter à votre serveur ou le configurer de différentes manières.

Déployez vos applications frontend depuis GitHub en utilisant DigitalOcean App Platform. Laissez DigitalOcean se concentrer sur la mise à l'échelle de votre application.

Comment utiliser ce guide

Lisez d'abord la section Aperçu de SSH si vous n'êtes pas familiarisé avec SSH en général ou si vous débutez.
Utilisez les sections suivantes qui sont applicables à ce que vous essayez d'accomplir. La plupart des sections ne dépendent d'aucune autre, vous pouvez donc utiliser les exemples suivants de manière indépendante.
Utilisez le menu des contenus sur le côté gauche de cette page (à des largeurs de page larges) ou la fonction de recherche de votre navigateur pour trouver les sections dont vous avez besoin.
Copiez et collez les exemples de ligne de commande donnés, en substituant les valeurs soulignées par vos propres valeurs.

Aperçu de SSH

La manière la plus courante de se connecter à un serveur Linux distant est via SSH. SSH signifie Secure Shell et fournit un moyen 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 en utilisant un compte qui existe sur le serveur distant.

Comment fonctionne SSH

Lorsque vous vous connectez via SSH, vous êtes plongé dans une session de 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 tapez dans votre terminal local sont envoyées à travers un tunnel SSH chiffré et exécutées sur votre serveur.

La connexion SSH est implémentée en utilisant un modèle client-serveur. Cela signifie que pour qu'une connexion SSH soit établie, la machine distante doit exécuter un logiciel appelé un démon SSH. Ce logiciel écoute les connexions sur un port réseau spécifique, authentifie les demandes de connexion et crée l'environnement approprié si l'utilisateur fournit les bonnes informations d'identification.

L'ordinateur de l'utilisateur doit disposer d'un client SSH. C'est un logiciel qui sait comment communiquer en utilisant le 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 qui doivent être fournies pour s'authentifier. Le client peut également spécifier certains détails concernant le type de connexion qu'il souhaite établir.

Comment SSH authentifie les utilisateurs

Les clients s'authentifient généralement soit en utilisant des mots de passe (moins sécurisés et non recommandés), soit des clés SSH, qui sont très sécurisées.

Les connexions par mot de passe sont chiffrées et sont faciles à comprendre pour les nouveaux utilisateurs. Cependant, les bots automatisés et les utilisateurs malveillants essaieront souvent de s'authentifier à plusieurs reprises sur des comptes qui permettent des connexions par mot de passe, ce qui peut entraîner des compromis de sécurité. Pour cette raison, nous recommandons toujours de configurer l'authentification par clé SSH pour la plupart des configurations.

Les clés SSH sont un ensemble de clés cryptographiques appariées 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 soucis, tandis que la clé privée doit être soigneusement gardée et ne doit jamais être exposée à quiconque.

Pour s'authentifier à l'aide de clés SSH, un utilisateur doit avoir une paire de clés SSH sur son ordinateur local. Sur le serveur distant, la clé publique doit être copiée dans un fichier situé dans le répertoire personnel de l'utilisateur à ~/.ssh/authorized_keys. Ce fichier contient une liste de clés publiques, une par ligne, qui sont 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 son fichier authorized_keys pour la clé publique, génère une chaîne aléatoire et l'enclave en utilisant la clé publique. Ce message chiffré ne peut être déchiffré qu'avec la clé privée associée. Le serveur enverra ce message chiffré au client pour tester s'il possède réellement la clé privée associée.

Dès la 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 ID de session précédemment négocié. Il génère ensuite un hachage MD5 de cette valeur et le transmet au serveur. Le serveur avait déjà le message original et l'ID de session, donc il peut 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érer et travailler avec des clés SSH

Cette section traitera de la manière de générer des clés SSH sur une machine cliente et de distribuer la clé publique aux serveurs où elles doivent être utilisées. C'est une bonne section à lire si vous n'avez pas précédemment 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

Générer une nouvelle paire de clés SSH publique et privée sur votre ordinateur local est la première étape pour s'authentifier 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 devriez toujours vous authentifier en utilisant des 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 sont 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 pour stocker votre clé privée RSA. Appuyez sur ENTRÉE pour laisser cela par défaut, ce qui les stockera dans le répertoire caché .ssh du 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:

Le prochain prompt vous permet d'entrer une passphrase de longueur arbitraire pour sécuriser votre clé privée. Comme mesure de sécurité supplémentaire, vous devrez entrer toute passphrase que vous avez définie ici chaque fois que vous utilisez la clé privée. N'hésitez pas à appuyer sur ENTRER pour laisser ce champ vide si vous ne souhaitez pas de passphrase. Gardez à l'esprit, cependant, que cela permettra à quiconque prenant le contrôle de votre clé privée de se connecter à vos serveurs.

Si vous choisissez d'entrer une phrase de passe, rien ne sera affiché pendant que vous tapez. C'est une mesure de sécurité.

Your 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 root@here
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 SSH RSA située dans le répertoire caché .ssh dans le 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. Celle-ci peut être partagée librement sans conséquence.

Remarque : Vous pouvez consulter notre guide sur la création de clés SSH avec OpenSSH sur macOS ou Windows Subsystem.

Générez une paire de clés SSH avec un nombre de bits plus élevé

Les clés SSH sont de 2048 bits par défaut. Cela est généralement considéré comme suffisant pour la sécurité, mais vous pouvez spécifier un nombre de bits plus élevé pour une clé plus sécurisée.

Pour ce faire, ajoutez l'argument -b avec le nombre de bits que vous souhaitez. La plupart des serveurs acceptent des clés d'une longueur d'au moins 4096 bits. Les clés plus longues peuvent ne pas être acceptées pour des raisons de protection contre les DDOS.

ssh-keygen -b 4096

Si vous avez précédemment créé une autre clé, vous serez invité à indiquer 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 en utilisant cette clé. Pour cette raison, assurez-vous d'écraser les clés avec prudence.

Retrait ou changement de la phrase de passe sur une clé privée

Si vous avez généré une phrase de passe pour votre clé privée et souhaitez la changer ou la supprimer, vous pouvez le faire facilement.

Note: Pour changer ou supprimer la phrase de passe, vous devez connaître la phrase de passe d'origine. Si vous avez perdu la phrase de passe de la clé, il n'y a pas de recours et vous devrez générer une nouvelle paire de clés.

Pour changer ou supprimer la phrase de passe, il suffit de taper :

ssh-keygen -p

Enter file in which the key is (/root/.ssh/id_rsa):

Vous pouvez taper l'emplacement de la clé que vous souhaitez modifier ou appuyer sur ENTRER pour accepter la valeur par défaut :

Enter old passphrase:

Entrez l'ancien mot de passe que vous souhaitez changer. Vous serez ensuite invité à entrer un nouveau mot de passe :

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

Ici, entrez votre nouvelle phrase de passe ou appuyez sur ENTRÉE pour supprimer la phrase de passe.

Affichage de l'empreinte de la clé SSH

Chaque paire de clés SSH partage une unique empreinte cryptographique qui peut être utilisée pour identifier les clés de manière unique. Cela peut être utile dans diverses situations.

Pour trouver 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 ENTRÉE si c'est le bon emplacement de la clé, sinon entrez le nouvel emplacement. Vous recevrez une chaîne contenant la longueur en bits de la clé, l'empreinte digitale, le compte et l'hôte pour lequel elle a été créée, ainsi que l'algorithme utilisé :

4096 8e:c4:82:47:87:c2:26:4b:68:ff:96:1a:39:62:9e:4e  demo@test (RSA)

Copier votre clé SSH publique vers 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é pour votre serveur, et que vous avez l'utilitaire ssh-copy-id installé, c'est un processus simple. L'outil ssh-copy-id est inclus dans les packages OpenSSH de nombreuses distributions Linux, donc il est 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 username@remote_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
demo@111.111.11.111'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 :

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'demo@111.111.11.111'"
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 username@remote_host

Copier votre clé SSH publique sur un serveur sans SSH-Copy-ID

Si vous n'avez pas l'utilitaire ssh-copy-id disponible, mais que vous avez toujours un accès SSH par mot de passe au serveur distant, vous pouvez copier le contenu de votre clé publique d'une autre manière.

Vous pouvez afficher le contenu de la clé et le rediriger dans la commande ssh. Du côté distant, vous pouvez vous assurer que le répertoire ~/.ssh existe, puis y ajouter le contenu redirigé dans le fichier ~/.ssh/authorized_keys :

cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Vous serez invité à fournir le mot de passe pour le 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
demo@111.111.11.111'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 username@remote_IP_host

Copier manuellement votre clé SSH publique vers un serveur

Si vous n'avez pas accès SSH basé sur un mot de passe, vous devrez ajouter votre clé publique manuellement au serveur distant.

Sur votre machine locale, vous pouvez trouver le contenu de votre fichier de clé publique en tapant :

cat ~/.ssh/id_rsa.pub

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== demo@test

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 de 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 au fichier ~/.ssh/authorized_keys en tapant :

echo public_key_string >> ~/.ssh/authorized_keys

Vous devriez maintenant être en mesure de 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.

Se connecter à un serveur distant

Pour se connecter à un serveur distant et 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 du serveur distant. Si c'est vrai, vous pouvez vous connecter en utilisant :

ssh remote_host

Si votre nom d'utilisateur est différent sur le serveur distant, vous devez passer le nom de l'utilisateur distant comme ceci :

ssh username@remote_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 oui pour accepter l'authenticité de l'hôte distant.

Si vous utilisez l'authentification par mot de passe, vous serez invité à entrer le mot de passe du compte distant ici. 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écuter une commande unique sur un serveur distant

Pour exécuter une seule commande sur un serveur distant au lieu de démarrer une session shell, vous pouvez ajouter la commande après les informations de connexion, comme ceci :

ssh username@remote_host command_to_run

Cela se connectera à l'hôte distant, s'authentifiera avec vos identifiants et exécutera la commande que vous avez spécifiée. La connexion se fermera immédiatement après.

Se connecter à un serveur avec un port différent

Par défaut, le démon SSH sur un serveur fonctionne 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 username@remote_host

Pour éviter de devoir faire cela chaque fois que vous vous connectez à votre serveur distant, vous pouvez créer ou modifier un fichier de configuration dans le répertoire ~/.ssh dans le répertoire personnel de votre ordinateur local.

Modifiez ou créez le fichier maintenant en tapant :

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 :

Host remote_alias
    HostName remote_host
    Port port_num

Cela vous permettra de vous connecter sans spécifier le numéro de port exact dans la ligne de commande.

Ajouter vos clés SSH à un agent SSH pour éviter de taper la phrase de passe

Si vous avez une phrase de passe sur votre clé SSH privée, vous serez invité à entrer la phrase de passe chaque fois que vous l'utilisez pour vous connecter à un hôte distant.

Pour éviter d'avoir à le faire plusieurs fois, vous pouvez exécuter un agent SSH. Cette petite utilité stocke votre clé privée après que vous ayez saisi le mot de passe pour la première fois. Elle sera disponible pendant la durée de votre session de terminal, vous permettant de vous connecter à l'avenir sans avoir à saisir à nouveau le mot de passe.

C'est également important si vous devez transférer vos identifiants SSH (indiqués plus tard).

Pour démarrer l'agent SSH, tapez ce qui suit dans votre session terminal locale :

eval $(ssh-agent)

Agent pid 10891

Cela va démarrer le programme de l'agent et le placer 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 entrer votre phrase secrète (si elle est définie). Ensuite, votre fichier d'identité est ajouté à l'agent, vous permettant d'utiliser votre clé pour vous connecter sans avoir à entrer à nouveau la phrase secrète.

Transférer vos identifiants SSH à utiliser sur un serveur

Si vous souhaitez pouvoir vous connecter sans mot de passe à un serveur depuis un autre serveur, vous devrez transférer 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 identifiants de votre ordinateur local.

Pour commencer, vous devez avoir votre agent SSH démarré et votre clé SSH ajoutée à l'agent (voir plus tôt). Une fois cela fait, vous devez vous connecter à votre premier serveur en utilisant l'option -A. Cela transfère vos informations d'identification au serveur pour cette session :

ssh -A username@remote_host

Depuis ici, 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 quelques options de configuration courantes côté serveur qui peuvent influencer la façon dont votre serveur répond et quels types de connexions sont autorisées.

Désactivation de l'authentification par mot de passe

Si vous avez des clés SSH configurées, testées et fonctionnant correctement, il est probablement judicieux de désactiver l'authentification par mot de passe. Cela empêchera tout utilisateur de se connecter avec SSH en utilisant un mot de passe.

Pour ce faire, connectez-vous à votre serveur distant et ouvrez le fichier /etc/ssh/sshd_config avec des privilèges root ou sudo :

sudo nano /etc/ssh/sshd_config

À l'intérieur du fichier, recherchez la directive PasswordAuthentication. Si elle est commentée, décommentez-la. Réglez-la sur no pour désactiver les connexions par mot de passe :

PasswordAuthentication no

Après avoir effectué la modification, enregistrez et fermez le fichier. Pour appliquer les modifications, vous devez redémarrer le service SSH.

Sur Ubuntu/Debian:

sudo service ssh restart

Sur CentOS/Fedora:

sudo service sshd restart

Maintenant, tous les comptes du système ne pourront pas se connecter avec SSH en utilisant des mots de passe.

Changer le port sur lequel le démon SSH s'exécute

Certains administrateurs suggèrent de changer le port par défaut sur lequel SSH fonctionne. Cela peut aider à réduire le nombre de tentatives d'authentification auxquelles votre serveur est soumis par des bots 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 des privilèges root, soit en vous connectant avec cet utilisateur, soit en utilisant sudo :

sudo nano /etc/ssh/sshd_config

Une fois que vous êtes à l'intérieur, vous pouvez changer le port sur lequel SSH fonctionne 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 :

#Port 22
Port 4444

Enregistrez et fermez le fichier lorsque vous avez terminé. Pour appliquer les changements, 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 (décrit dans une section précédente).

Limiter les utilisateurs qui peuvent se connecter via SSH

Pour limiter explicitement les comptes utilisateurs qui peuvent se connecter par SSH, vous pouvez adopter quelques approches différentes, chacune impliquant la modification du fichier de configuration du démon SSH.

Sur votre serveur distant, ouvrez ce fichier maintenant avec des privilèges root ou sudo :

sudo nano /etc/ssh/sshd_config

La première méthode pour spécifier les comptes autorisés à se connecter est d'utiliser la directive AllowUsers. Recherchez la directive AllowUsers dans le fichier. Si elle n'existe pas, créez-la à n'importe quel endroit. Après la directive, listez les comptes utilisateurs qui devraient être autorisés à se connecter via SSH :

AllowUsers user1 user2

Enregistrez et fermez le fichier. Redémarrez le démon pour appliquer vos modifications.

Sur Ubuntu/Debian:

sudo service ssh restart

Sur CentOS/Fedora:

sudo service sshd restart

Si vous vous sentez plus à l'aise avec la gestion des groupes, vous pouvez utiliser la directive AllowGroups à la place. Dans ce cas, ajoutez simplement un seul groupe qui devrait avoir accès SSH (nous allons créer ce groupe et y ajouter des membres sous peu):

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 tous les comptes utilisateurs dont vous avez besoin à ce groupe. Cela peut se faire en tapant :

sudo usermod -a -G sshmembers user1
sudo usermod -a -G sshmembers user2

Maintenant, redémarrez le démon SSH pour appliquer vos modifications.

Sur Ubuntu/Debian:

sudo service ssh restart

Sur CentOS/Fedora:

sudo service sshd restart

Désactivation de la connexion root

Il est souvent conseillé de désactiver complètement la connexion root via SSH après avoir configuré un compte utilisateur SSH ayant 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. Si elle est commentée, décommentez-la. Changez la valeur en "non" :

PermitRootLogin no

Enregistrez et fermez le fichier. Pour appliquer vos modifications, redémarrez le daemon 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

Il y a des cas où vous pourriez vouloir désactiver l'accès root en général, mais l'activer pour permettre à certaines applications de fonctionner correctement. Un exemple de cela pourrait être une routine de sauvegarde.

Cela peut être réalisé via le fichier authorized_keys de l'utilisateur root, 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 recommandons de créer une nouvelle clé pour chaque processus automatique) au fichier authorized_keys de l'utilisateur root sur le serveur. Nous allons démontrer avec la commande ssh-copy-id ici, mais vous pouvez utiliser n'importe quelle méthode de copie de clés que nous discutons dans d'autres sections :

ssh-copy-id root@remote_host

Maintenant, connectez-vous au serveur distant. Nous devrons ajuster l'entrée dans le fichier authorized_keys, alors 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 un command= qui définit la commande pour laquelle cette clé est valide. Cela devrait inclure le chemin complet vers l'exécutable, ainsi que tous les arguments :

command="/path/to/command arg1 arg2" ssh-rsa ...

Enregistrez et fermez le fichier lorsque vous avez terminé.

Maintenant, ouvrez le fichier sshd_config avec des privilèges root ou sudo :

sudo nano /etc/ssh/sshd_config

Trouvez la directive PermitRootLogin et changez la valeur en forced-commands-only. Cela n'autorisera les connexions SSH avec des clés à utiliser le compte root que lorsque qu'une commande a été spécifiée pour la clé :

PermitRootLogin forced-commands-only

Enregistrez et fermez le fichier. Redémarrez le démon SSH pour appliquer vos modifications.

Sur Ubuntu/Debian:

sudo service ssh restart

Sur CentOS/Fedora:

sudo service sshd restart

Transfert des affichages de l'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 de fenêtres X configuré et activé.

Pour activer cette fonctionnalité, connectez-vous à votre serveur distant et éditez le fichier sshd_config en tant que root ou avec des privilèges sudo :

sudo nano /etc/ssh/sshd_config

Recherchez la directive X11Forwarding. Si elle est commentée, décommentez-la. Créez-la si nécessaire et définissez sa valeur sur « oui » :

X11Forwarding yes

Enregistrez et fermez le fichier. Redémarrez votre démon SSH pour appliquer ces modifications.

Sur Ubuntu/Debian:

sudo service ssh restart

Sur CentOS/Fedora:

sudo service sshd restart

Pour se connecter au serveur et transférer l'affichage d'une application, vous devez passer l'option -X depuis le client lors de la connexion :

ssh -X username@remote_host

Les applications graphiques lancées sur le serveur par cette session doivent être affichées sur l'ordinateur local. Les performances peuvent être un peu lentes, mais c'est très utile en cas de besoin.

Options de configuration côté client

Dans la section suivante, nous nous concentrerons sur certains ajustements que vous pouvez apporter du côté client de la connexion.

Définir les 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. Celles-ci peuvent être stockées 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 de cela et en retrait, vous pouvez définir toutes les directives trouvées dans la page de manuel ssh_config :

man ssh_config

Une configuration d'exemple serait :

Host testhost
    HostName your_domain
    Port 4444
    User demo

Vous pouvez ensuite vous connecter à votre_domaine 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 à plus d'un hôte. Gardez à l'esprit que les correspondances ultérieures peuvent écraser les précédentes. En raison de cela, vous devriez mettre vos correspondances les plus générales en premier. Par exemple, vous pourriez définir par défaut que toutes les connexions ne permettent pas le transfert X, avec une exception pour votre_domaine en ayant ceci dans votre fichier :

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 le timeout

Si vous constatez que vous êtes déconnecté des sessions SSH avant d'être prêt, il est possible que votre connexion soit en train d'expirer.

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 configurer cela pour chaque connexion en modifiant votre fichier ~/.ssh/config. Ouvrez-le maintenant :

nano ~/.ssh/config

S'il n'existe pas déjà, au début du fichier, définissez une section qui correspondra à tous les hôtes. Réglez le ServerAliveInterval à "120" pour envoyer un paquet au serveur toutes les deux minutes. Cela devrait suffire à informer le serveur de ne pas fermer la connexion:

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 clé hôte du daemon SSH distant vous sera affichée.

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

Cela est configuré de manière à ce que vous puissiez vérifier l'authenticité de l'hôte auquel vous essayez de vous connecter et détecter les cas où un utilisateur malveillant pourrait 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 grand risque pour la sécurité, donc assurez-vous de savoir ce que vous faites si vous configurez votre système de cette manière.

Pour effectuer le changement, ouvrez le fichier ~/.ssh/config sur votre ordinateur local :

nano ~/.ssh/config

S'il n'existe pas déjà, en haut du fichier, définissez une section qui correspondra à tous les hôtes. Réglez la directive StrictHostKeyChecking sur no pour ajouter automatiquement de nouveaux hôtes au fichier known_hosts. Réglez le UserKnownHostsFile sur /dev/null pour ne pas recevoir d'avertissement sur les hôtes nouveaux ou modifiés:

Host *
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null

Vous pouvez activer la vérification au cas par cas en inversant ces options pour d'autres hôtes. La valeur par défaut de StrictHostKeyChecking est ask :

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

Il existe des situations où établir une nouvelle connexion TCP peut prendre plus de temps que souhaité. Si vous établissez plusieurs connexions avec la même machine, vous pouvez tirer parti du multiplexage.

Le multiplexage SSH réutilise la même connexion TCP pour plusieurs sessions SSH. Cela élimine une partie du travail nécessaire pour établir une nouvelle session, ce qui peut accélérer les choses. Limiter le nombre de connexions peut également être utile pour d'autres raisons.

Pour configurer le multiplexage, vous pouvez établir manuellement les connexions, ou vous pouvez configurer votre client pour utiliser automatiquement le multiplexage lorsque c'est disponible. Nous démontrerons 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 déjà une définition d'hôte générique en haut du fichier, ajoutez-en une maintenant (comme Host *). Nous allons définir les valeurs de ControlMaster, ControlPath et ControlPersist pour établir notre configuration de multiplexage.

Le ControlMaster doit être défini sur « auto » afin de permettre automatiquement le multiplexage si possible. Le ControlPath établira le chemin vers le socket de contrôle. La première session créera ce socket et les sessions suivantes pourront le trouver car il est étiqueté par le nom d'utilisateur, l'hôte et le port.

Configurer l'option ControlPersist sur 1 permettra à la connexion maître initiale d'être mise en arrière-plan. Le 1 précise que la connexion TCP doit automatiquement se terminer une seconde après la fermeture de la dernière session SSH.

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

Maintenant, toutes les sessions qui sont é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 supprimée après une seconde.

Si pour une raison quelconque vous devez contourner temporairement la configuration de multiplexage, vous pouvez le faire en passant le drapeau -S avec none :

ssh -S none username@remote_host

Configuration des tunnels SSH

Faire passer d'autres types de trafic à travers un tunnel SSH sécurisé est un excellent moyen de contourner les paramètres de pare-feu restrictifs. C'est aussi un moyen efficace de chiffrer un trafic réseau autrement non chiffré.

Configurer le tunneling local vers un serveur

Les connexions SSH peuvent être utilisées pour tunneliser le trafic des ports sur l'hôte local vers les ports sur un hôte distant.

Une connexion locale est un moyen d'accéder à un emplacement réseau depuis 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 tunnelé 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 est d'accéder à une interface web "local uniquement" depuis 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 où vous souhaitez accéder à la connexion tunnelée.
L'hôte auquel vous souhaitez que votre hôte distant se connecte.
Le port sur lequel vous souhaitez 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 au drapeau -L. Nous utiliserons également le drapeau -f, qui fait en sorte que SSH passe en arrière-plan avant d'exécuter, et le drapeau -N, qui n'ouvre pas de shell ni n'exécute un programme sur le côté distant.

Par exemple, pour vous connecter à votre_domaine sur le port 80 de votre hôte distant, rendant la connexion disponible sur votre machine locale sur le port 8888, vous pourriez taper :

ssh -f -N -L 8888:your_domain:80 username@remote_host

Maintenant, si vous pointez votre navigateur web local vers 127.0.0.1:8888, vous devriez voir le contenu qui se trouve à votre_domaine sur le port 80.

Un guide plus général sur la syntaxe est :

ssh -L your_port:site_or_IP_to_access:site_port username@host

Étant donné que la connexion est en arrière-plan, vous devrez trouver son PID pour le tuer. Vous pouvez le faire en recherchant le port que vous avez transféré :

ps aux | grep 8888

1001      5965  0.0  0.0  48168  1136 ?        Ss   12:28   0:00 ssh -f -N -L 8888:your_domain:80 username@remote_host
1001      6113  0.0  0.0  13648   952 pts/2    S+   12:37   0:00 grep --colour=auto 8888

Vous pouvez alors 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 est de démarrer la connexion sans le drapeau -f. Cela maintiendra la connexion au premier plan, vous empêchant d'utiliser la fenêtre du terminal pendant la durée du transfert. L'avantage de cela est que vous pouvez facilement tuer le tunnel en tapant CTRL-C.

Configurer le tunneling à distance vers un serveur

Les connexions SSH peuvent être utilisées pour tunneliser le trafic des ports sur l'hôte local vers les ports sur un hôte distant.

Dans un tunnel éloigné, 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 transféré vers une combinaison d'hôte et de port à laquelle l'ordinateur local est connecté. Cela permettra à l'ordinateur distant d'accéder à un hôte via votre ordinateur local.

Ceci peut être utile si vous devez permettre l'accès à un réseau interne qui est restreint aux connexions externes. Si le pare-feu autorise les connexions sortantes du réseau, cela vous permettra de vous connecter à une machine distante et de transférer 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 :

Le port par lequel l'hôte distant peut accéder à la connexion tunnelée.
L'hôte auquel vous souhaitez que votre ordinateur local se connecte.
Le port auquel vous souhaitez 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 au drapeau -R. Nous utiliserons également le drapeau -f, qui fait en sorte que SSH passe en arrière-plan avant d'exécuter, et le drapeau -N, qui n'ouvre pas de shell ni n'exécute un programme sur le côté distant.

Par exemple, pour se 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 pourriez taper :

ssh -f -N -R 8888:your_domain:80 username@remote_host

Maintenant, sur l'hôte distant, ouvrir un navigateur web à 127.0.0.1:8888 vous permettrait de voir tout le contenu de votre_domaine sur le port 80.

Un guide plus général sur la syntaxe est :

ssh -R remote_port:site_or_IP_to_access:site_port username@host

Étant donné que la connexion est en arrière-plan, vous devrez trouver son PID pour le tuer. Vous pouvez le faire en recherchant le port que vous avez transféré :

ps aux | grep 8888

1001      5965  0.0  0.0  48168  1136 ?        Ss   12:28   0:00 ssh -f -N -R 8888:your_domain:80 username@remote_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

Configurer le tunnel dynamique vers un serveur distant

Les connexions SSH peuvent être utilisées pour tunneliser le trafic des ports sur l'hôte local vers les ports sur 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 simplement en spécifiant un seul port local. Les applications qui souhaitent tirer parti de ce port pour le tunneling doivent être capables de communiquer en utilisant le protocole SOCKS afin que les paquets puissent être correctement redirigés de l'autre côté du tunnel.

Le trafic qui est envoyé à ce port local sera transmis à l'hôte distant. De là, le protocole SOCKS sera interprété pour établir une connexion avec 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 nécessiter de multiples tunnels statiques.

Pour établir la connexion, nous passerons le drapeau -D ainsi que le port local où nous souhaitons accéder au tunnel. Nous utiliserons également le drapeau -f, qui fait en sorte que SSH s'exécute en arrière-plan avant l'exécution, et le drapeau -N, qui n'ouvre pas de shell ni n'exécute de programme du côté distant.

Par exemple, pour établir un tunnel sur le port 7777, vous pouvez taper :

ssh -f -N -D 7777 username@remote_host

À partir de là, vous pouvez commencer à diriger votre application compatible SOCKS (comme un navigateur web) vers le port que vous avez sélectionné. L'application enverra ses informations dans un socket associé au port.

La méthode pour diriger le trafic vers le port SOCKS variera selon l'application. Par exemple, dans Firefox, l'emplacement général est Préférences > Avancé > Paramètres > Configurations de proxy manuelles. Dans Chrome, vous pouvez démarrer l'application avec le drapeau --proxy-server= défini. Vous voudrez utiliser l'interface localhost et le port que vous avez transféré.

Étant donné que la connexion est en arrière-plan, vous devrez trouver son PID pour le tuer. Vous pouvez le faire en recherchant le port que vous avez transféré :

ps aux | grep 8888

1001      5965  0.0  0.0  48168  1136 ?        Ss   12:28   0:00 ssh -f -N -D 7777 username@remote_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

Utiliser les 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 depuis 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 capacité 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 ~ lors d'une session SSH. Les commandes de contrôle ne seront interprétées que si elles sont les premières à être tapées après un retour à la ligne, donc appuyez toujours sur ENTRER 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 poser problème si le serveur rencontre des problèmes ou si la connexion a été rompue. En utilisant une déconnexion côté client, la connexion peut être fermée proprement depuis le 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 terminal bloquée. Tapez les commandes malgré le manque de retour pour effectuer une déconnexion côté client :

[ENTER]
~.

La connexion doit se fermer immédiatement, vous renvoyant à votre session de 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 capacité de contrôler certains aspects de la session depuis l'intérieur de 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 tapée après un saut de ligne, donc appuyez toujours sur ENTER une ou deux fois avant d'en utiliser une.

Une des capacités que cela offre est de mettre une session SSH en arrière-plan. Pour ce faire, nous devons fournir le caractère de contrôle (~) et ensuite exécuter le raccourci clavier conventionnel pour mettre une tâche en arrière-plan (CTRL-z) :

[ENTER]
~[CTRL-z]

Cela placera la connexion en arrière-plan, vous ramenant à votre session shell locale. Pour revenir à votre session SSH, vous pouvez utiliser les mécanismes de contrôle des jobs conventionnels.

Vous pouvez immédiatement réactiver votre tâche en arrière-plan la plus récente en tapant :

fg

Si vous avez plusieurs tâches en arrière-plan, vous pouvez voir les emplois disponibles en tapant :

jobs

[1]+  Stopped                 ssh username@some_host
[2]   Stopped                 ssh username@another_host

Vous pouvez ensuite amener l'une des tâches au premier plan en utilisant l'index dans la première colonne suivi d'un signe de pourcentage :

fg %2

Modifier les options de redirection de port sur une connexion SSH existante

L'une des fonctionnalités les plus utiles d'OpenSSH, qui passe largement inaperçue, est la capacité de contrôler certains aspects de la session depuis l'intérieur de la connexion.

Ces commandes peuvent être exécutées en commençant par le caractère de contrôle ~ à partir d'une connexion SSH. Les commandes de contrôle ne seront interprétées que si elles sont les premières choses tapées après un saut de ligne, donc appuyez toujours sur ENTRÉE une ou deux fois avant d'en utiliser une.

Une chose que cela permet est de permettre à un utilisateur de modifier la configuration de 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 redirection de port à la volée.

Ces capacités font partie de l'interface de ligne de commande SSH, qui peut être 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 a un ensemble très limité de commandes valides. Pour voir les options disponibles, vous pouvez taper -h depuis cette invite. Si rien n'est retourné, 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 implémenter chacune des options de redirection en utilisant les options appropriées (voir la section de redirection 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 du type de redirection. Par exemple, pour tuer une redirection locale (-L), vous pourriez utiliser la commande -KL. Vous n'aurez besoin de fournir que le port pour cela.

Donc, 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 maintenant communiquer avec le serveur web de l'hôte auquel vous vous connectez. Lorsque vous aurez terminé, vous pouvez supprimer cette redirection en tapant :

[ENTER]
~C
-KL 8888

Conclusion

Les instructions ci-dessus devraient couvrir la majorité des informations dont la plupart des utilisateurs auront besoin concernant 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.