Introduction
SSH est un protocole sécurisé utilisé comme principal moyen de se connecter aux serveurs Linux à distance. Il fournit une interface en texte brut en lançant un shell distant. Après la connexion, toutes les commandes que vous saisissez dans votre terminal local sont envoyées au serveur distant et exécutées là-bas.
Dans ce guide de style aide-mémoire, nous couvrirons quelques méthodes courantes de connexion avec SSH pour atteindre vos objectifs. Cela peut être utilisé comme référence rapide lorsque vous avez besoin de savoir comment vous connecter à votre serveur ou le configurer de différentes manières.
Déployez vos applications frontend depuis GitHub en utilisant la plateforme d’applications DigitalOcean. Laissez DigitalOcean se concentrer sur le dimensionnement de votre application.
Comment Utiliser Ce Guide
- Lisez d’abord la section Présentation de SSH si vous n’êtes pas familier avec SSH en général ou si vous débutez tout juste.
- Utilisez les sections suivantes qui sont applicables à ce que vous essayez d’accomplir. La plupart des sections ne dépendent pas d’autres sections, vous pouvez donc utiliser les exemples suivants indépendamment.
- Utilisez le menu de contenu situé sur la gauche de cette page (pour les larges 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
en surbrillancepar vos propres valeurs.
Présentation 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û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 en utilisant un compte qui existe sur le serveur distant.
Fonctionnement de SSH
Lorsque vous vous connectez via SSH, vous serez placé dans une session shell, qui est une interface basée sur du texte 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 via 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 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 en utilisant le protocole SSH et auquel des informations sur l’hôte distant, le nom d’utilisateur à utiliser et les informations d’identification à transmettre pour l’authentification peuvent être fournies. 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 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 cryptées et sont faciles à comprendre pour les nouveaux utilisateurs. Cependant, les robots automatisés et les utilisateurs malveillants essaient souvent de s’authentifier à plusieurs reprises auprès de comptes autorisant les connexions basées sur des mots de passe, ce qui peut entraîner des compromis de sécurité. Pour cette raison, nous recommandons toujours de configurer l’authentification basée sur les clés SSH pour la plupart des configurations.
Les clés SSH sont un ensemble de clés cryptographiques correspondantes 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 vigilamment et jamais exposée à quiconque.
Pour s’authentifier en utilisant des 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’encrypte en utilisant la clé publique. Ce message encrypté ne peut être déchiffré qu’avec la clé privée associée. Le serveur envoie ensuite ce message encrypté au client pour tester s’ils possèdent effectivement la clé privée associée.
À la réception de ce message, le client le déchiffre en utilisant la clé privée et combine la chaîne aléatoire révélée avec un identifiant de session précédemment négocié. Il génère ensuite un hash MD5 de cette valeur et le transmet de nouveau au serveur. Le serveur avait déjà le message original et l’identifiant de session, il peut donc comparer un hash MD5 généré par ces valeurs et déterminer que le client doit posséder 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 des Clés SSH
Cette section couvrira 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 généré de clés auparavant en raison de la sécurité accrue qu’elle permet pour les futures connexions.
Génération d’une Paire de Clés SSH
Générer une nouvelle paire de clés publique et privée SSH sur votre ordinateur local est la première étape vers l’authentification avec 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.
A number of cryptographic algorithms can be used to generate SSH keys, including RSA, DSA, and ECDSA. RSA keys are generally preferred and are the default key type.
Pour générer une paire de clés RSA sur votre ordinateur local, tapez:
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 dans le répertoire personnel de votre utilisateur. Laisser l’emplacement par défaut sélectionné permettra à votre client SSH de trouver automatiquement les clés.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
La prochaine invite vous permet de saisir une phrase secrète d’une longueur arbitraire pour sécuriser votre clé privée. Par défaut, vous devrez saisir une phrase secrète que vous définissez ici chaque fois que vous utilisez la clé privée, en tant que mesure de sécurité supplémentaire. N’hésitez pas à appuyer sur ENTRÉE pour laisser ce champ vide si vous ne souhaitez pas de phrase secrète. Gardez à l’esprit cependant que cela permettra à quiconque prend le contrôle de votre clé privée de se connecter à vos serveurs.
Si vous choisissez de saisir une phrase secrète, rien ne sera affiché lorsque vous la tapez. Il s’agit d’une précaution 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 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 à l’intérieur 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. Celle-ci peut être partagée librement sans conséquence.
Générer une paire de clés SSH avec un nombre de bits plus élevé
Les clés SSH sont par défaut de 2048 bits. Cela est généralement considéré comme suffisant pour la sécurité, mais vous pouvez spécifier un nombre plus élevé de bits pour obtenir une clé plus renforcée.
Pour ce faire, incluez l’argument -b avec le nombre de bits souhaité. La plupart des serveurs acceptent des clés d’une longueur d’au moins 4096 bits. Des clés plus longues peuvent ne pas être acceptées à des fins de protection contre les attaques par déni de service distribué (DDoS) :
Si vous aviez précédemment créé une clé différente, on vous demandera 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é. En raison de cela, assurez-vous d’écraser les clés avec prudence.
Suppression ou modification de la phrase secrète sur une clé privée
Si vous avez généré une phrase secrète pour votre clé privée et que vous souhaitez la modifier ou la supprimer, vous pouvez le faire facilement.
Note: Pour changer 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 changer ou supprimer la phrase secrète, il suffit de taper:
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 ENTRÉE pour accepter la valeur par défaut:
Enter old passphrase:
Entrez l’ancienne phrase secrète que vous souhaitez changer. Vous serez alors invité à saisir une nouvelle phrase secrète:
Enter new passphrase (empty for no passphrase):
Enter same passphrase again:
Ici, saisissez votre nouvelle phrase secrète ou appuyez sur ENTRÉE pour supprimer la phrase secrète.
Affichage de l’empreinte de la clé SSH
Chaque paire de clés SSH partage une seule « empreinte » cryptographique qui peut être utilisée pour identifier de manière unique les clés. Cela peut être utile dans diverses situations.
Pour trouver l’empreinte d’une clé SSH, tapez :
Enter file in which the key is (/root/.ssh/id_rsa):
Vous pouvez appuyer sur ENTRÉE si c’est l’emplacement correct de la clé, sinon entrez l’emplacement révisé. Vous obtiendrez une chaîne qui contient la longueur en bits de la clé, l’empreinte, 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 demo@test (RSA)
Copier votre clé publique SSH 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 utilisées.
Si vous avez actuellement configuré l’accès SSH basé sur un mot de passe à 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 de nombreux packages OpenSSH des 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 :
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 désormais vous connecter à ce compte sans mot de passe :
Copier votre clé publique SSH vers un serveur sans SSH-Copy-ID
Si vous n’avez pas l’utilitaire ssh-copy-id disponible, mais avez toujours 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 rediriger 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 :
On vous demandera 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 saisi le mot de passe, votre clé sera copiée, vous permettant de vous connecter sans mot de passe :
Copier votre clé publique SSH vers un serveur manuellement
Si vous n’avez pas accès SSH basé sur un mot de passe disponible, vous devrez ajouter votre clé publique au serveur distant manuellement.
Sur votre machine locale, vous pouvez trouver le contenu de votre fichier de clé publique en tapant :
Outputssh-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 DigitalOcean).
Sur le serveur distant, créez le répertoire ~/.ssh s’il n’existe pas déjà:
Ensuite, vous pouvez créer ou ajouter au fichier ~/.ssh/authorized_keys en tapant:
Vous devriez maintenant pouvoir vous connecter au serveur distant sans mot de passe.
Instructions de Connexion Basiques
La section suivante couvrira quelques bases sur la manière de se connecter à un serveur avec SSH.
Connexion à un Serveur Distant
Pour vous connecter à un serveur distant et ouvrir une session shell là-bas, 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 c’est le cas, vous pouvez vous connecter en utilisant:
Si votre nom d’utilisateur est différent sur le serveur distant, vous devez passer le nom d’utilisateur distant comme ceci:
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é à saisir le mot de passe du compte distant ici. Si vous utilisez des clés SSH, on vous demandera la phrase secrète de votre clé privée si elle est définie, sinon vous serez connecté automatiquement.
Exécuter une seule commande sur un serveur distant
Pour exécuter une seule commande sur un serveur distant au lieu de créer une session shell, vous pouvez ajouter la commande après les informations de connexion, comme ceci :
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 ensuite.
Connexion à 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:
Pour éviter d’avoir à le faire à chaque fois que vous vous connectez à votre serveur distant, vous pouvez créer ou éditer un fichier de configuration dans le répertoire ~/.ssh situé dans le répertoire personnel de votre ordinateur local.
Éditez ou créez le fichier maintenant en tapant:
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 spécifique à la ligne de commande.
Ajout de vos clés SSH à un agent SSH pour éviter de taper 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. Cette petite utilité stocke votre clé privée après avoir entré la phrase secrète la première fois. Elle sera disponible pendant la durée de votre session de terminal, ce qui vous permettra de vous connecter à l’avenir sans avoir à saisir à nouveau la phrase secrète.
C’est également important si vous avez besoin de transférer vos informations d’identification SSH (comme expliqué plus tard).
Pour démarrer l’Agent SSH, tapez ce qui suit dans votre session de terminal local:
OutputAgent pid 10891
Cela démarrera le programme 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é :
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 à saisir à nouveau la phrase secrète.
Transfert de vos informations d’identification SSH pour les utiliser sur un serveur
Si vous souhaitez pouvoir vous connecter à un serveur sans mot de passe depuis un autre serveur, vous devrez transférer les informations de votre clé SSH. Cela vous permettra de vous authentifier sur 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 démarré votre agent SSH et ajouté votre clé SSH à l’agent (voir plus haut). 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 :
À 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 était située sur ce serveur.
Options de configuration côté serveur
Cette section contient quelques options de configuration côté serveur courantes qui peuvent façonner la manière dont votre serveur répond et quels types de connexions sont autorisés.
Désactiver l’authentification par mot de passe
Si vous avez configuré, testé et que vos clés SSH fonctionnent correctement, il est probablement judicieux de désactiver l’authentification par mot de passe. Cela empêchera tout utilisateur de se connecter via 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 :
Dans le 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 apporté la modification, enregistrez et fermez le fichier. Pour mettre en œuvre les changements, vous devriez redémarrer le service SSH.
Sur Ubuntu/Debian :
Sur CentOS/Fedora :
Désormais, tous les comptes sur le système ne pourront pas se connecter via 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 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:
Une fois à l’intérieur, vous pouvez modifier le port sur lequel SSH fonctionne en recherchant 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 mettre en œuvre les modifications, vous devez redémarrer le démon SSH.
Sur Ubuntu/Debian:
Sur CentOS/Fedora:
Après le redémarrage du démon, vous devrez vous authentifier en spécifiant le numéro de port (démontré dans une section précédente).
Limite des utilisateurs pouvant se connecter via SSH
Pour limiter explicitement les comptes d’utilisateur 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 maintenant ce fichier avec les privilèges root ou sudo:
La première méthode pour spécifier les comptes autorisés à se connecter consiste à utiliser la directive AllowUsers. Recherchez la directive AllowUsers dans le fichier. Si elle n’existe pas, créez-la n’importe où. Après la directive, listez les comptes d’utilisateurs qui devraient être autorisés à se connecter via SSH :
AllowUsers user1 user2
Enregistrez et fermez le fichier. Redémarrez le démon pour mettre en œuvre vos modifications.
Sous Ubuntu/Debian :
Sous CentOS/Fedora :
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 avoir accès SSH (nous allons créer ce groupe et ajouter des membres dans un instant) :
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 :
Assurez-vous d’ajouter les comptes d’utilisateurs nécessaires à ce groupe. Cela peut être fait en tapant :
Ensuite, redémarrez le démon SSH pour mettre en œuvre vos modifications.
Sous Ubuntu/Debian :
Sous CentOS/Fedora :
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 l’utilisateur root ou sudo sur votre serveur distant.
À l’intérieur, recherchez une directive appelée PermitRootLogin. Si elle est commentée, décommentez-la. Changez la valeur en « no » :
PermitRootLogin no
Enregistrez et fermez le fichier. Pour mettre en œuvre vos modifications, redémarrez le démon SSH.
Sous Ubuntu/Debian :
Sous CentOS/Fedora :
Autoriser l’accès root pour des commandes spécifiques
Il existe des cas où vous voudrez peut-être désactiver généralement l’accès root, mais l’activer pour permettre à certaines applications de s’exécuter correctement. Un exemple en est une routine de sauvegarde.
Cela peut être accompli 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 vous 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 dont nous discutons dans d’autres sections :
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 :
Au début de la ligne avec la clé que vous avez téléchargée, ajoutez un command= répertoriant la commande pour laquelle cette clé est valide. Cela doit inclure le chemin complet vers l’exécutable, ainsi que les éventuels 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 :
Recherchez la directive PermitRootLogin et changez la valeur en forced-commands-only. Cela ne permettra aux connexions SSH avec clé d’utiliser le compte root que lorsqu’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 implémenter vos modifications.
Sur Ubuntu/Debian :
Sur CentOS/Fedora :
Transfert d’affichages d’applications X vers le 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 :
Recherchez la directive X11Forwarding. Si elle est commentée, décommentez-la. Créez-la si nécessaire et définissez la valeur sur « yes » :
X11Forwarding yes
Enregistrez et fermez le fichier. Redémarrez votre démon SSH pour mettre en œuvre ces modifications.
Sous Ubuntu/Debian :
Sous CentOS/Fedora :
Pour vous connecter au serveur et transmettre l’affichage d’une application, vous devez passer l’option -X depuis le client lors de la connexion :
Les applications graphiques lancées sur le serveur via cette session devraient s’afficher sur l’ordinateur local. Les performances peuvent être un peu lentes, mais cela peut être très utile en cas de besoin.
Options de configuration côté client
Dans la prochaine section, nous nous concentrerons sur quelques 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. 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 :
À 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 indenté, vous pouvez définir n’importe laquelle des directives trouvées dans la page de manuel ssh_config :
Un exemple de configuration serait :
Host testhost
HostName your_domain
Port 4444
User demo
Vous pourriez alors vous connecter à your_domain sur le port 4444 en utilisant le nom d’utilisateur demo en tapant simplement :
Vous pouvez également utiliser des jokers pour faire correspondre plus d’un hôte. Gardez à l’esprit que les correspondances ultérieures peuvent remplacer les précédentes. Pour cette raison, vous devriez mettre vos correspondances les plus générales en haut. Par exemple, vous pourriez définir par défaut toutes les connexions pour ne pas autoriser le transfert X, avec une substitution pour your_domain 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 les déconnexions
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 configurer cela pour chaque connexion en éditant votre fichier ~/.ssh/config. Ouvrez-le maintenant :
Si elle n’existe pas déjà, en haut du fichier, définissez une section qui correspondra à tous les hôtes. Définissez ServerAliveInterval sur « 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 fini.
Désactivation de la vérification de l’hôte
Par défaut, chaque fois que vous vous connectez à un nouveau serveur, vous verrez l’empreinte digitale de la clé hôte du démon SSH 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
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 cas où un utilisateur malveillant pourrait essayer de se faire passer pour l’hôte distant.
Dans certaines circonstances, vous pouvez souhaiter désactiver cette fonctionnalité. Remarque: Cela peut constituer un gros 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 apporter la modification, ouvrez le fichier ~/.ssh/config sur votre ordinateur local :
Si elle n’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 des 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 vous ne le souhaiteriez. Si vous établissez de multiples connexions vers la même machine, vous pouvez profiter 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 configurer manuellement les connexions ou configurer votre client pour utiliser automatiquement le multiplexage lorsqu’il est disponible. Nous allons ici démontrer la deuxième option.
Pour configurer le multiplexage, modifiez le fichier de configuration de votre client SSH sur votre machine locale:
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 ControlMaster, ControlPath et ControlPersist pour établir notre configuration de multiplexage.
Le ControlMaster doit être réglé sur « auto » pour permettre automatiquement le multiplexage si possible. Le ControlPath établira le chemin vers la prise de contrôle. La première session créera cette prise et les sessions ultérieures pourront la trouver car elle est étiquetée par nom d’utilisateur, hôte et port.
Le réglage de l’option ControlPersist sur 1 permettra à la connexion maître initiale d’être en arrière-plan. Le 1 spécifie que la connexion TCP doit se terminer automatiquement 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 :
Maintenant, toutes les sessions établies avec la même machine tenteront d’utiliser la prise et la connexion TCP existantes. Lorsque la dernière session est terminée, la connexion sera coupé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 :
Configuration des tunnels SSH
Le tunnelage d’autres flux de trafic via un tunnel SSH sécurisé est un excellent moyen de contourner les paramètres restrictifs du pare-feu. C’est également un excellent moyen de crypter le trafic réseau autrement non crypté.
Configuration du tunnelage local vers un serveur
Les connexions SSH peuvent être utilisées pour faire transiter le trafic des ports de l’hôte local vers des ports d’un hôte distant.
A local connection is a way of accessing a network location from your local computer through your remote host. First, an SSH connection is established to your remote host. On the remote server, a connection is made to an external (or internal) network address provided by the user and traffic to this location is tunneled to your local computer on a specified port.
Ceci est souvent utilisé pour se connecter à un environnement réseau moins restreint en contournant un pare-feu. Une autre utilisation courante est d’accéder à une interface web accessible uniquement en local 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 fournir trois éléments d’information supplémentaires:
- Le port local sur lequel vous souhaitez accéder à la connexion tunnelisé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.
Ces éléments 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 permet à SSH de passer en arrière-plan avant d’exécuter et le drapeau -N, qui n’ouvre pas de shell ni n’exécute de programme 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:
Maintenant, si vous pointez votre navigateur web local vers 127.0.0.1:8888, vous devriez voir le contenu de votre_domaine sur le port 80.
A more general guide to the syntax is:
Étant donné que la connexion s’effectue en arrière-plan, vous devrez trouver son PID pour la terminer. Vous pouvez le faire en recherchant le port que vous avez redirigé :
Output1001 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
Ensuite, vous pouvez arrêter le processus en ciblant le PID, qui est le numéro dans la deuxième colonne de la ligne correspondant à votre commande SSH :
Une autre option est de démarrer la connexion sans le drapeau -f. Cela maintiendra la connexion en avant-plan, vous empêchant d’utiliser la fenêtre du terminal pendant la durée du transfert. L’avantage est que vous pouvez facilement arrêter le tunnel en tapant CTRL-C.
Configuration du transfert à distance vers un serveur
Les connexions SSH peuvent être utilisées pour transférer le trafic des ports de l’hôte local vers des ports d’un hôte distant.
Dans un tunnel distant, une connexion est établie vers un hôte distant. Pendant la création du tunnel, un port distant est spécifié. Ce port, sur l’hôte distant, sera ensuite tunnelisé vers une combinaison d’hôte et de port connectée depuis 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 permettre l’accès à un réseau interne verrouillé 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 fournir trois informations supplémentaires:
- Le port où l’hôte distant peut accéder à la connexion tunnélisée.
- L’hôte auquel vous souhaitez que votre ordinateur local se connecte.
- Le port auquel vous souhaitez que votre ordinateur local se connecte.
Ces informations sont fournies, dans l’ordre ci-dessus (séparées par des deux-points), en tant qu’arguments du drapeau -R. Nous utiliserons également le drapeau -f, qui permet à SSH de passer en arrière-plan avant l’exécution, et le drapeau -N, qui n’ouvre pas de shell ni n’exécute de programme côté distant.
Par exemple, pour vous connecter à your_domain sur le port 80 sur notre ordinateur local, rendant la connexion disponible sur notre hôte distant sur le port 8888, vous pourriez taper:
Maintenant, sur l’hôte distant, en ouvrant un navigateur web vers 127.0.0.1:8888, vous pourriez voir le contenu se trouvant à your_domain sur le port 80.
A more general guide to the syntax is:
Étant donné que la connexion est en arrière-plan, vous devrez trouver son PID pour la terminer. Vous pouvez le faire en recherchant le port que vous avez redirigé:
Output1001 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 arrêter le processus en ciblant le PID, qui est le numéro dans la deuxième colonne, de la ligne correspondant à votre commande SSH:
Une autre option est de démarrer la connexion sans le drapeau -f. Cela maintiendra la connexion en 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 arrêter le tunnel en tapant CTRL-C.
Configuration du tunneling dynamique vers un serveur distant
Les connexions SSH peuvent être utilisées pour faire transiter le trafic des ports sur l’hôte local vers des ports sur un hôte distant.
A dynamic tunnel is similar to a local tunnel in that it allows the local computer to connect to other resources through a remote host. A dynamic tunnel does this by simply specifying a single local port. Applications that wish to take advantage of this port for tunneling must be able to communicate using the SOCKS protocol so that the packets can be correctly redirected at the other side of the tunnel.
Le trafic transmis à ce port local sera envoyé vers l’hôte distant. À partir de là, le protocole SOCKS sera interprété pour établir une connexion vers l’emplacement final souhaité. Cette configuration permet à une application compatible SOCKS de se connecter à plusieurs emplacements via le serveur distant, sans avoir besoin de plusieurs 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 passer SSH en arrière-plan avant l’exécution et le drapeau -N, qui n’ouvre pas de shell ni n’exécute de programme côté distant.
Par exemple, pour établir un tunnel sur le port 7777, vous pouvez taper :
À 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 un socket associé au port.
La méthode de rediriger le trafic vers le port SOCKS différera 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 le drapeau --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 terminer. Vous pouvez le faire en recherchant le port que vous avez redirigé :
Output1001 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 correspondant à votre commande SSH :
Une autre option est de démarrer la connexion sans le drapeau -f. Cela gardera la connexion en premier plan, vous empêchant d’utiliser la fenêtre du terminal pendant la redirection. L’avantage est que vous pouvez facilement arrêter 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é des codes d’échappement SSH, qui nous permettent d’interagir avec notre logiciel SSH local depuis une session.
Forcer une déconnexion côté client (Comment sortir d’une session bloquée ou gelée)
Une des fonctionnalités les plus utiles d’OpenSSH qui passe largement inaperçue est la capacité à contrôler certains aspects de la session depuis l’intérieur.
Ces commandes peuvent être exécutées en commençant par le caractère de contrôle ~ à l’intérieur d’une session 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, alors appuyez toujours sur ENTRÉE une ou deux fois avant d’en utiliser une.
Un des contrôles les plus utiles est la capacité d’initier une déconnexion depuis le 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 est interrompue. En utilisant une déconnexion côté client, la connexion peut être proprement fermée depuis le client.
Pour fermer une connexion depuis le client, utilisez le caractère de contrôle (~), suivi d’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:
La connexion devrait se fermer immédiatement, vous ramenant à votre session de shell locale.
Mettre une session SSH en arrière-plan
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 la connexion elle-même.
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 retour à la ligne, donc appuyez toujours sur ENTRÉE une ou deux fois avant d’en utiliser une.
Une des fonctionnalité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) :
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 de tâche conventionnels.
Vous pouvez réactiver immédiatement votre tâche mise en arrière-plan la plus récente en tapant :
Si vous avez plusieurs tâches en arrière-plan, vous pouvez voir les tâches disponibles en tapant :
Output[1]+ Stopped ssh username@some_host
[2] Stopped ssh username@another_host
Vous pouvez ensuite ramener n’importe quelle tâche au premier plan en utilisant l’indice dans la première colonne avec un pourcentage :
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 possibilité de contrôler certains aspects de la session depuis la connexion elle-même.
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 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.
Cela permet notamment à un utilisateur de modifier la configuration de redirection de port après que la connexion ait 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 en ligne de commande SSH, qui peut être accédée pendant une session en utilisant le caractère de contrôle (~) suivi de « C » :
ssh>
Vous obtiendrez un invite de commande SSH, qui dispose d’un ensemble très limité de commandes valides. Pour voir les options disponibles, vous pouvez taper -h à partir de cet invite. Si rien n’est renvoyé, vous devrez peut-être augmenter la verbosité de votre sortie SSH en utilisant ~v quelques fois :
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 l’une des options de redirection en utilisant les options appropriées (consultez la section sur la redirection pour plus d’informations). Vous pouvez également détruire un tunnel avec la commande associée « kill » spécifiée par 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 qu’à fournir le port pour cela.
Donc, pour configurer une redirection de port local, vous pouvez taper :
Le port 8888 sur votre ordinateur local pourra maintenant communiquer avec le serveur web sur l’hôte auquel vous vous connectez. Lorsque vous avez terminé, vous pouvez démanteler cette redirection en tapant :
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.