Comment configurer des options de connexion personnalisées pour votre client SSH

Introduction

SSH, ou Secure Shell, est la manière la plus courante de se connecter à des serveurs Linux pour l'administration à distance. Bien que la connexion à un seul serveur via la ligne de commande soit relativement simple, il existe de nombreuses optimisations de flux de travail pour se connecter à plusieurs systèmes distants.

OpenSSH, le client SSH en ligne de commande le plus couramment utilisé sur la plupart des systèmes, vous permet de fournir des options de connexion personnalisées. Celles-ci peuvent être enregistrées dans un fichier de configuration qui contient différentes options par serveur. Cela peut aider à garder les différentes options de connexion que vous utilisez pour chaque hôte séparées et organisées, et évite d'avoir à fournir des options étendues sur la ligne de commande chaque fois que vous devez vous connecter.

Dans ce guide, nous aborderons la structure du fichier de configuration du client SSH et examinerons quelques options courantes.

Conditions préalables

Pour compléter ce guide, vous aurez besoin d'une connaissance de base de SSH et de certaines des options que vous pouvez fournir lors de la connexion. Vous devriez également configurer l'authentification par clé SSH pour certains de vos utilisateurs ou serveurs, au moins à des fins de test.

La structure du fichier de configuration SSH et l'algorithme d'interprétation

Chaque utilisateur de votre système peut maintenir son propre fichier de configuration SSH dans son répertoire personnel. Ceux-ci peuvent contenir toutes les options que vous utiliseriez en ligne de commande pour spécifier les paramètres de connexion. Il est toujours possible de remplacer les valeurs définies dans le fichier de configuration au moment de la connexion en ajoutant des options supplémentaires à la commande ssh.

L'emplacement du fichier de configuration du client SSH

Le fichier de configuration côté client est situé à ~/.ssh/config – le ~ est un raccourci universel vers votre répertoire personnel. Souvent, ce fichier n'est pas créé par défaut, donc vous devrez peut-être le créer vous-même. La commande touch le créera s'il n'existe pas (et mettra à jour l'horodatage de la dernière modification s'il existe).

touch ~/.ssh/config

Structure du fichier de configuration

Le fichier config est organisé par hôtes, c'est-à-dire par serveurs distants. Chaque définition d'hôte peut définir des options de connexion pour l'hôte correspondant. Des jokers sont également pris en charge pour les options qui devraient avoir une portée plus large.

Chacune des sections commence par un en-tête définissant les hôtes qui doivent correspondre aux options de configuration qui suivent. Les éléments de configuration spécifiques pour cet hôte correspondant sont ensuite définis ci-dessous. Seuls les éléments qui diffèrent des valeurs par défaut doivent être spécifiés, car chaque entrée hérite des valeurs par défaut pour tout élément non défini. Chaque section s'étend d'un en-tête Host à l'en-tête Host suivant.

Typiquement, pour des raisons organisationnelles et de lisibilité, les options définies pour chaque hôte sont en retrait. Ce n'est pas une exigence stricte, mais une convention utile qui permet une interprétation d'un coup d'œil.

Le format général ressemblera à ceci :

Host firsthost
    Hostname your-server.com
    User username-to-connect-as
    IdentityFile /path/to/non/default/keys.pem

Host secondhost
    ANOTHER_OPTION custom_value

Host *host
    ANOTHER_OPTION custom_value

Host *
    CHANGE_DEFAULT custom_value

Ici, nous avons quatre sections qui seront appliquées à chaque tentative de connexion en fonction de si l'hôte en question correspond.

Algorithme d'interprétation

Il est important de comprendre comment SSH interprétera le fichier pour appliquer les valeurs de configuration. Cela a des implications lors de l'utilisation de caractères génériques et de la définition d'hôte générique Host *.

SSH fera correspondre le nom d'hôte fourni sur la ligne de commande avec chacun des en-têtes Host qui définissent les sections de configuration.

Par exemple, considérons cette définition :

Host devel
    HostName devel.example.com
    User tom

Cet hôte nous permet de nous connecter en tant que tom@devel.example.com en tapant ceci dans la ligne de commande :

ssh devel

SSH commence en haut du fichier de configuration et vérifie chaque définition de Host pour voir si elle correspond à la valeur donnée sur la ligne de commande. Lorsque la première définition de Host correspondante est trouvée, chacune des options SSH associées est appliquée à la connexion à venir.

SSH descend ensuite dans le fichier, vérifiant si d'autres définitions de Host correspondent également. Si une autre définition est trouvée qui correspond au nom d'hôte actuel donné en ligne de commande, elle prendra en compte les options SSH associées à la nouvelle section. Elle appliquera ensuite toutes les options SSH définies pour la nouvelle section qui n'ont pas déjà été définies par les sections précédentes.

C'est un point important. SSH interprétera chacune des sections Host correspondant au nom d'hôte donné sur la ligne de commande, dans l'ordre. Au cours de ce processus, il utilisera toujours la première valeur donnée pour chaque option. Il n'y a aucun moyen de remplacer une valeur qui a déjà été donnée par une section précédemment correspondante.

Cela signifie que votre fichier config doit suivre la règle d'avoir les configurations les plus spécifiques en haut. Les définitions plus générales doivent venir plus tard afin d'appliquer des options qui n'ont pas été définies par les sections correspondantes précédentes.

Regardons de nouveau l'exemple de la section précédente :

Host firsthost
    Hostname your-server.com
    User username-to-connect-as
    IdentityFile /path/to/non/default/keys.pem

Host secondhost
    ANOTHER_OPTION custom_value

Host *host
    ANOTHER_OPTION custom_value

Host *
    CHANGE_DEFAULT custom_value

Ici, nous pouvons voir que les deux premières sections sont définies par des noms d'hôtes littéraux (ou des alias), ce qui signifie qu'elles n'utilisent aucun caractère générique. Si nous nous connectons en utilisant ssh firsthost, la toute première section sera la première à être appliquée. Cela définira Hostname, User, et IdentityFile pour cette connexion.

Il vérifiera la deuxième section et constatant qu'elle ne correspond pas, il passera à la suite. Il trouvera ensuite la troisième section et notera qu'elle correspond. Il vérifiera ANOTHER_OPTION pour voir s'il a déjà une valeur pour cela provenant des sections précédentes. constatant qu'il n'en a pas, il appliquera la valeur de cette section. Il correspondra ensuite à la dernière section, puisque la définition Host * correspond à chaque connexion. Comme il n'a pas de valeur pour l'option fictive CHANGE_DEFAULT des autres sections, il prendra la valeur de cette section. La connexion est alors établie avec les options collectées lors de ce processus.

Réessayons cela, en prétendant appeler ssh secondhost depuis la ligne de commande.

Encore une fois, cela commencera par la première section et vérifiera si elle correspond. Comme cela ne correspond qu'à une connexion à firsthost, cela ignorera cette section. Il passera à la deuxième section. En trouvant que cette section correspond à la requête, elle collectera la valeur de ANOTHER_OPTION pour cette connexion.

SSH examine ensuite la troisième définition et constate que le caractère générique correspond à la connexion actuelle. Il vérifie alors s'il a déjà une valeur pour ANOTHER_OPTION. Étant donné que cette option a été définie dans la deuxième section, qui a déjà été appariée, la valeur de la troisième section est abandonnée et n'a aucun effet.

SSH vérifie ensuite la quatrième section et applique les options qui n'ont pas été définies par les sections précédemment correspondantes. Il tente ensuite la connexion en utilisant les valeurs qu'il a rassemblées.

Options de connexion

Maintenant que vous avez une idée sur la façon d'écrire votre fichier de configuration, discutons de quelques options courantes et du format à utiliser pour les spécifier en ligne de commande.

Les premiers éléments que nous allons couvrir sont les paramètres minimaux nécessaires pour se connecter à un hôte distant. À savoir, le nom d'hôte, le nom d'utilisateur et le port sur lequel le serveur SSH fonctionne.

Pour se connecter en tant qu'utilisateur nommé apollo à un hôte appelé example.com qui exécute son démon SSH sur le port 4567 à partir de la ligne de commande, vous pouvez exécuter ssh comme ceci :

ssh -p 4567 apollo@example.com

Cependant, vous pouvez également utiliser les noms d'options complets avec le drapeau -o, comme ceci :

ssh -o "User=apollo" -o "Port=4567" -o "HostName=example.com"

Vous pouvez trouver une liste complète des options disponibles dans la page de manuel SSH.

Pour les définir dans votre fichier config, vous devez choisir un nom d'en-tête Host, comme home :

Host home
    HostName example.com
    User apollo
    Port 4567

Options de configuration SSH courantes

Jusqu'à présent, nous avons discuté de certaines des options nécessaires pour établir une connexion. Nous avons abordé ces options :

Nom d'hôte : Le nom d'hôte réel qui doit être utilisé pour établir la connexion. Cela remplace tout alias défini dans l'en-tête Host. Cette option n'est pas nécessaire si la définition Host spécifie la véritable adresse valide à laquelle se connecter.
Le nom d'utilisateur à utiliser pour la connexion.
Port : Le port sur lequel le démon SSH distant fonctionne. Cette option est uniquement nécessaire si l'instance SSH distante ne fonctionne pas sur le port par défaut 22.

Il existe de nombreuses autres options utiles qui méritent d'être explorées. Nous discuterons de certaines des options les plus courantes, séparées selon leur fonction.

Ajustements généraux et éléments de connexion

ServerAliveInterval : Cette option peut être configurée pour informer SSH quand envoyer un paquet pour tester la réponse du serveur. Cela peut être utile si votre connexion est instable et que vous voulez savoir si elle est toujours disponible.
NiveauDeJournalisation: Cela configure le niveau de détail avec lequel SSH va enregistrer côté client. Cela peut être utilisé pour désactiver l'enregistrement dans certaines situations ou augmenter la verbosité lors de l'essai de débogage. Du moins verbeux au plus verbeux, les niveaux sont SILENCIEUX, FATAL, ERREUR, INFO, VERBOSE, DEBUG1, DEBUG2 et DEBUG3.
StrictHostKeyChecking : Cette option configure si SSH ajoutera automatiquement des hôtes au fichier ~/.ssh/known_hosts. Par défaut, cela sera réglé sur « ask », ce qui signifie qu'il vous avertira si la clé d'hôte reçue du serveur distant ne correspond pas à celle trouvée dans le fichier known_hosts. Si vous vous connectez constamment à un grand nombre d'hôtes éphémères (comme des serveurs de tests), vous voudrez peut-être changer cela en « no ». SSH ajoutera alors automatiquement tous les hôtes au fichier. Cela peut avoir des implications en matière de sécurité si vos hôtes connus changent d'adresse alors qu'ils ne devraient pas, donc réfléchissez bien avant de l'activer.
UserKnownHostsFile : Cette option spécifie l'emplacement où SSH stockera les informations sur les hôtes auxquels il s'est connecté. En général, vous n'avez pas à vous soucier de ce paramètre, mais vous pouvez souhaiter le définir sur /dev/null afin qu'ils soient supprimés si vous avez désactivé la vérification stricte des hôtes ci-dessus.
VisualHostKey: Cette option peut indiquer à SSH d'afficher une représentation ASCII de la clé de l'hôte distant lors de la connexion. Activer cela peut être un moyen utile de se familiariser avec la clé de votre hôte, vous permettant de la reconnaître si vous devez vous connecter depuis un autre ordinateur à l'avenir.
Compression: Activer la compression peut être utile pour les connexions très lentes. La plupart des utilisateurs n'en auront pas besoin.

Avec les éléments de configuration ci-dessus à l'esprit, nous pourrions effectuer un certain nombre d'ajustements de configuration utiles.

Par exemple, si nous créons et détruisons des hôtes très rapidement chez un fournisseur de cloud, quelque chose comme cela peut être utile :

Host home
    VisualHostKey yes

Host cloud*
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null
    LogLevel QUIET

Host *
    StrictHostKeyChecking ask
    UserKnownHostsFile ~/.ssh/known_hosts
    LogLevel INFO
    ServerAliveInterval 120

Cela activera votre clé d'hôte visuelle pour votre connexion à domicile, vous permettant de vous familiariser avec elle afin de pouvoir reconnaître si elle change ou lorsque vous vous connectez à partir d'une autre machine. Nous avons également configuré tous les hôtes qui commencent par cloud* pour ne pas vérifier les hôtes et ne pas enregistrer les échecs. Pour les autres hôtes, nous avons des valeurs de repli raisonnables.

Transfert de connexion

Une utilisation courante de SSH est le transfert de connexions, soit permettant à une connexion locale de passer par l'hôte distant, soit permettant à la machine distante d'accéder à la machine locale. Cela est parfois nécessaire lorsque vous devez vous connecter à une machine distante derrière un pare-feu via un serveur "passerelle" désigné séparément. SSH peut également effectuer un transfert dynamique en utilisant des protocoles comme SOCKS5 qui incluent les informations de transfert pour l'hôte distant.

Les options qui contrôlent ce comportement sont :

LocalForward: Cette option est utilisée pour spécifier une connexion qui va transférer le trafic d'un port local vers la machine distante, le tunnelant dans le réseau distant. Le premier argument doit être le port local vers lequel vous souhaitez diriger le trafic et le deuxième argument doit être l'adresse et le port vers lesquels vous souhaitez diriger ce trafic à l'autre extrémité.
RemoteForward: Cette option est utilisée pour définir un port distant vers lequel le trafic peut être dirigé afin de créer un tunnel depuis la machine locale. Le premier argument doit être le port distant où le trafic sera dirigé sur le système distant. Le deuxième argument doit être l'adresse et le port vers lesquels le trafic doit être dirigé lorsqu'il arrive sur le système local.
DynamicForward : Ceci est utilisé pour configurer un port local qui peut être utilisé avec un protocole de transfert dynamique tel que SOCKS5. Le trafic utilisant le protocole de transfert dynamique peut alors être dirigé vers ce port sur la machine locale et, à l'autre bout, il sera routé selon les valeurs incluses.

Ces options peuvent être utilisées pour rediriger les ports dans les deux sens, comme vous pouvez le voir ici :

This will allow us to use port 8080 on the local machine
in order to access example.com at port 80 from the remote machine
Host local_to_remote
    LocalForward 8080 example.com:80

This will allow us to offer access to internal.com at port 443
to the remote machine through port 7777 on the other side
Host remote_to_local
    RemoteForward 7777 internal.com:443

C'est particulièrement utile lorsque vous devez ouvrir une fenêtre de navigateur vers un tableau de bord privé ou une autre application web fonctionnant sur un serveur qui n'est pas directement accessible sauf par SSH.

Autre réacheminement

En plus du transfert de connexion, SSH permet également d'autres types de transfert.

Vous pouvez transférer toutes les clés SSH stockées dans un agent sur votre machine locale, nous permettant ainsi de nous connecter depuis le système distant en utilisant des identifiants stockés sur votre système local. Vous pouvez également démarrer des applications sur un système distant et transférer l'affichage graphique vers notre système local en utilisant le transfert X11. X11 est un serveur d'affichage Linux et n'est pas très intuitif à utiliser sans un système de bureau Linux, mais peut être très utile si vous utilisez à la fois un environnement Linux distant et local.

Voici les directives qui sont associées à ces capacités :

ForwardAgent : Cette option permet d'envoyer les clés d'authentification stockées sur notre machine locale vers le système auquel vous vous connectez. Cela peut vous permettre de sauter d'un hôte à un autre en utilisant vos clés de chez vous.
ForwardX11 : Si vous souhaitez pouvoir transmettre un écran graphique d'une application exécutée sur le système distant, vous pouvez activer cette option.

Spécification des clés

Si vous avez des clés SSH configurées pour vos hôtes, ces options peuvent vous aider à gérer quelles clés utiliser pour chaque hôte.

IdentityFile: Cette option peut être utilisée pour spécifier l'emplacement de la clé à utiliser pour chaque hôte. Par défaut, SSH utilisera les clés situées dans ~/.ssh, mais si vous avez des clés assignées par serveur, cela peut être utilisé pour spécifier le chemin exact où elles peuvent être trouvées.
IdentitiesOnly: Cette option peut être utilisée pour forcer SSH à ne s'appuyer que sur les identités fournies dans le fichier config. Cela peut être nécessaire si un agent SSH a des clés alternatives en mémoire qui ne sont pas valides pour l'hôte en question.

Ces options sont particulièrement utiles si vous devez garder une trace d'un grand nombre de clés pour différents hôtes et utiliser un ou plusieurs agents SSH pour vous aider.

Conclusion

Tant que vous gardez à l'esprit la façon dont SSH interprétera les valeurs, vous pouvez établir des ensembles riches de valeurs spécifiques avec des alternatives raisonnables.

Si vous devez un jour utiliser SSH sur une connexion très mauvaise ou intermittente, comme le Wi-Fi dans un avion, vous pouvez également essayer d'utiliser mosh, qui est conçu pour faire fonctionner SSH dans des conditions défavorables.