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

introduction

SSH, ou shell sécurisé, est le moyen le plus courant de se connecter à des hôtes Linux pour une administration à distance. Bien que les bases de la connexion à un seul hôte soient souvent simples, cette tâche peut devenir lourde et beaucoup plus compliquée lorsque vous commencez à travailler avec un grand nombre de systèmes distants.

Heureusement, OpenSSH vous permet de fournir des options de connexion personnalisées côté client. Celles-ci peuvent être enregistrées dans un fichier de configuration qui peut être utilisé pour définir des valeurs par hôte. Cela peut vous aider à séparer et organiser les différentes options de connexion que vous utilisez pour chaque hôte et vous éviter d’avoir à fournir des options étendues sur la ligne de commande chaque fois que vous devez vous connecter.

Dans ce guide, nous aborderons les bases du fichier de configuration du client SSH, ainsi que quelques options communes.

Conditions préalables

Pour compléter ce guide, vous aurez besoin d’une connaissance pratique de SSH et de certaines des options que vous pouvez fournir lors de la connexion. Vous pouvez également souhaiter configurer l’authentification par clé SSH pour certains de vos utilisateurs ou hôtes, à tout le moins à des fins de test.

Structure de fichier SSH et algorithme d’interprétation

Chaque utilisateur de votre système local peut gérer un fichier de configuration SSH côté client. Ceux-ci peuvent contenir toutes les options que vous utiliseriez sur la ligne de commande pour spécifier les paramètres de connexion, vous permettant ainsi de stocker vos éléments de connexion communs et de les traiter automatiquement lors de la connexion. Il est toujours possible de remplacer les valeurs définies dans le fichier de configuration lors de la connexion via des indicateurs normaux à la commande + ssh +.

L’emplacement du fichier de configuration du client SSH

Le fichier de configuration côté client s’appelle + config + et se trouve dans le répertoire de base de votre utilisateur, dans le répertoire de configuration + .ssh +. Souvent, ce fichier n’est pas créé par défaut. Vous devrez donc peut-être le créer vous-même:

touch ~/.ssh/config

Structure du fichier de configuration

Le fichier + config + est organisé par les hôtes. Chaque définition d’hôte peut définir des options de connexion pour l’hôte correspondant spécifique. Les caractères génériques sont également disponibles pour permettre des options qui devraient avoir une portée plus large.

Chacune des sections commence par un en-tête définissant les hôtes devant correspondre aux options de configuration qui vont suivre. 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 l’hôte héritera des valeurs par défaut pour tous les éléments non définis. Une section est définie à partir de l’en-tête + Host + et à l’en-tête + Host + suivant.

En règle générale, pour des raisons d’organisation et de lisibilité, les options définies pour chaque hôte sont en retrait. Ce n’est pas une exigence absolue, mais une convention utile qui permet une interprétation plus facile en un coup d’œil.

Le format général ressemblera à ceci:

Host




Host


Host


Host *

Ici, nous avons quatre sections qui seront appliquées à chaque tentative de connexion, selon que l’hôte en question correspond ou non.

Algorithme d’interprétation

Il est très important de comprendre la façon dont SSH interprétera le fichier pour appliquer les valeurs de configuration définies dans. Cela a des implications importantes 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 indiqué sur la ligne de commande à chacun des en-têtes + Host + qui définissent les sections de configuration. Cela se fera de haut en bas du dossier, l’ordre est donc extrêmement important.

C’est un bon moment pour souligner que les modèles de la définition + hôte + ne doivent pas nécessairement correspondre à l’hôte auquel vous allez vous connecter. Vous pouvez essentiellement utiliser ces définitions pour configurer des alias pour des hôtes pouvant être utilisés à la place du nom d’hôte réel.

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 sur la ligne de commande:

ssh devel

En gardant cela à l’esprit, nous pouvons maintenant discuter de la manière dont SSH applique chaque option de configuration au fur et à mesure qu’elle avance dans le fichier. Il commence en haut et vérifie chaque définition + hôte + pour voir si elle correspond à la valeur indiquée sur la ligne de commande.

Lorsque la première définition + hôte + correspondante est trouvée, chacune des options SSH associées est appliquée à la connexion à venir. L’interprétation ne s’arrête pas là cependant.

SSH déplace ensuite le fichier vers le bas, vérifiant si les autres définitions + Host + correspondent également. Si une autre définition correspondant au nom d’hôte actuel indiqué sur la ligne de commande est trouvée, il considérera les options SSH associées à la nouvelle section. Il appliquera ensuite les options SSH définies pour la nouvelle section * qui n’ont pas déjà été définies par les sections précédentes *.

Ce dernier point est extrêmement important à intérioriser. SSH interprétera chacune des sections + Host + correspondant au nom d’hôte indiqué sur la ligne de commande, dans l’ordre. Au cours de ce processus, il utilisera toujours la valeur first 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 appariée.

Cela signifie que votre fichier + config + doit suivre la règle simple consistant à avoir les configurations les plus spécifiques en haut. Des définitions plus générales devraient venir plus tard afin d’appliquer des options qui n’étaient pas définies par les sections correspondantes précédentes.

Examinons à nouveau le fichier de maquette + config + que nous avons utilisé dans la dernière section:

Host




Host


Host


Host *

Nous pouvons voir ici que les deux premières sections sont définies par des noms d’hôte (ou alias) littéraux, 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 + SSH_OPTION_1 +, + SSH_OPTION_2 + et + SSH_OPTION_3 + pour cette connexion.

Il va vérifier la deuxième section et constater qu’il ne correspond pas et aller de l’avant. Il trouvera ensuite la troisième section et constatera que celle-ci correspond. Il va vérifier + ANOTHER_OPTION + pour voir s’il a déjà une valeur pour cela des sections précédentes. Constatant que ce n’est pas le cas, la valeur de cette section sera appliquée. Il correspondra alors à la dernière section puisque la définition + hôte * + correspond à chaque connexion. Puisqu’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 ensuite établie avec les options collectées à partir de ce processus.

Essayons à nouveau, en prétendant appeler + ssh secondhost + depuis la ligne de commande.

Encore une fois, il commencera à la première section et vérifiera si cela correspond. Comme cela correspond uniquement à une connexion à + firsthost +, il ignorera cette section. Nous passerons à la deuxième section. Après avoir constaté que cette section correspond à la demande, il collectera la valeur + 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érifiera ensuite 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 correspondait déjà, la valeur de la troisième section est supprimé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 appariées. Il tente ensuite la connexion en utilisant les valeurs qu’il a rassemblées.

Options de connexion de base

Maintenant que vous avez une idée du format général à utiliser lors de la conception de votre fichier de configuration, voyons quelques options communes et le format à utiliser pour les spécifier sur la ligne de commande.

Les premiers que nous aborderons sont les informations de base 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 démon SSH est exécuté.

Pour vous connecter en tant qu’utilisateur + apollo + à un hôte appelé + example.com + qui exécute son démon SSH sur le port + 4567 + à partir de la ligne de commande, nous pourrions donner les informations de variable de différentes manières. Le plus commun serait probablement:

ssh -p 4567 [email protected]

Cependant, nous pourrions aussi utiliser les noms d’option complets avec l’indicateur + -o +, comme ceci:

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

Ici, nous avons défini toutes les options que nous souhaitons utiliser avec le drapeau + -o +. Nous avons même spécifié l’hôte comme “n’importe quoi” comme un alias, comme nous pourrions le faire dans le fichier de configuration décrit précédemment. Le nom d’hôte réel provient de l’option + HostName + que nous définissons.

Les noms d’option en majuscule que nous utilisons dans la seconde forme sont les mêmes que nous devons utiliser dans notre fichier + config +. Vous pouvez trouver une liste complète des options disponibles en tapant:

man ssh_config

Pour les définir dans notre fichier + config +, nous devons d’abord choisir les hôtes pour lesquels nous voulons utiliser ces options. Puisque nous discutons d’options spécifiques à l’hôte en question, nous devrions probablement utiliser une correspondance d’hôte littérale.

Nous avons également la possibilité à ce stade d’attribuer un alias pour cette connexion. Profitons-en pour ne pas avoir à taper le nom d’hôte au complet à chaque fois. Nous utiliserons l’alias «home» pour faire référence à cette connexion et aux options associées:

Host home

Maintenant, nous pouvons définir les détails de connexion pour cet hôte. Nous pouvons utiliser le deuxième format que nous avons utilisé ci-dessus pour nous informer de ce que nous devrions mettre dans cette section.

Host home
   HostName example.com
   User apollo
   Port 4567

Nous définissons les options en utilisant un système clé-valeur. Chaque paire devrait être sur une ligne séparée. Les clés peuvent être séparées de leurs valeurs associées soit par un espace blanc, soit par un signe égal avec un espace blanc optionnel. Ainsi, ils sont tous identiques à ceux interprétés par notre client SSH:

Port 4567
Port=4567
Port = 4567

La seule différence est que, selon l’option et la valeur, l’utilisation du signe égal sans espace peut vous permettre de spécifier une option sur la ligne de commande sans faire de devis. Puisque nous nous concentrons sur notre fichier + config +, cela dépend entièrement de vos préférences.

Configuration des options partagées

Jusqu’à présent, la configuration que nous avons conçue est incroyablement simple. Dans son intégralité, cela ressemble à ceci:

Host home
   HostName example.com
   User apollo
   Port 4567

Et si nous utilisions le même nom d’utilisateur sur nos ordinateurs de travail et à la maison? Nous pourrions ajouter des options redondantes avec notre section définissant la machine de travail comme ceci:

Host home
   HostName example.com
   User apollo
   Port 4567

Host work
   HostName company.com
   User apollo

Cela fonctionne, mais nous répétons des valeurs. Ce n’est qu’une option, ce n’est donc pas une grosse affaire, mais nous souhaitons parfois partager un grand nombre d’options. La meilleure façon de le faire est de diviser les options partagées en sections distinctes.

Si nous utilisons le nom d’utilisateur «apollo» sur toutes les machines auxquelles nous nous connectons, nous pourrions l’insérer dans notre définition générique «d’hôte», marquée par un seul + * + correspondant à chaque connexion. Rappelez-vous que les sections plus génériques devraient aller plus loin vers le bas:

Host home
   HostName example.com
   Port 4567

Host work
   HostName company.com

Host *
   User apollo

Cela élimine le problème de la répétition dans notre configuration et fonctionnera si «apollo» est votre nom d’utilisateur par défaut pour la majorité des nouveaux systèmes auxquels vous vous connectez.

Que se passe-t-il si certains systèmes n’utilisent pas ce nom d’utilisateur? Vous pouvez aborder ce problème de différentes manières, en fonction de l’étendue du partage du nom d’utilisateur.

Si le nom d’utilisateur «apollo» est utilisé sur presque tous vos hôtes, il est probablement préférable de le laisser dans la section générique + Host * +. Ceci s’appliquera à tous les hôtes qui n’ont pas reçu de nom d’utilisateur des sections ci-dessus. Pour nos machines anormales qui utilisent un nom d’utilisateur différent, nous pouvons remplacer la valeur par défaut en fournissant une alternative. Cela aura la priorité tant qu’il est défini avant la section générique:

Host home
   HostName example.com
   Port 4567

Host work
   HostName company.com

Host oddity
   HostName weird.com
   User zeus

Host *
   User apollo

Pour l’hôte + oddity +, SSH se connectera à l’aide du nom d’utilisateur «zeus». Toutes les autres connexions ne recevront pas leur nom d’utilisateur tant qu’elles n’auront pas atteint la définition générique `+ hôte * + '.

Que se passe-t-il si le nom d’utilisateur «apollo» est partagé par quelques connexions, mais qu’il n’est pas assez commun pour l’utiliser comme valeur par défaut? Si nous souhaitons renommer les alias que nous utilisons pour avoir un format plus courant, nous pouvons utiliser un caractère générique pour appliquer des options supplémentaires à ces deux hôtes.

Nous pouvons changer l’alias + home + en quelque chose comme + hapollo + et la connexion de travail à quelque chose comme + wapollo +. De cette façon, les deux hôtes partagent la partie + apollo + de leur alias, ce qui nous permet de la cibler avec une section différente en utilisant des caractères génériques:

Host hapollo
   HostName example.com
   Port 4567

Host wapollo
   HostName company.com

Host *apollo
   User apollo

Host *
   User diffdefault

Ici, nous avons déplacé la définition + utilisateur + partagée vers une section d’hôte qui correspond aux connexions SSH essayant de se connecter aux hôtes se terminant par + apollo +. Toute connexion ne se terminant pas par + apollo + (et sans sa propre section + Host + définissant un + utilisateur) recevra le nom d’utilisateur` + diff default`.

Notez que nous avons conservé les commandes du plus spécifique au moins spécifique dans notre fichier. Il est préférable de considérer les sections d’hôte moins spécifiques comme des solutions de repli par opposition aux valeurs par défaut en raison de l’ordre dans lequel le fichier est interprété.

Options de configuration SSH communes

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

* Nom d’hôte *: Le nom d’hôte à utiliser pour établir la connexion. Ceci remplace tout alias défini dans l’en-tête + Host +. Cette option n’est pas nécessaire si la définition + hôte + spécifie le nom d’hôte valide auquel se connecter.
* Utilisateur *: Le nom d’utilisateur à utiliser pour la connexion.
* Port *: port sur lequel le démon SSH distant est en cours d’exécution. Cette option est nécessaire uniquement si l’instance SSH distante ne s’exécute pas sur le port par défaut + 22 +.

Il existe de nombreuses autres options utiles qui méritent d’être explorées. Nous allons discuter de certaines des options les plus courantes, séparées en fonction de la fonction.

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

Vous trouverez ci-dessous d’autres réglages que vous souhaiterez peut-être configurer à un niveau plus large, par exemple dans la section + Host * +.

* + ServerAliveInterval + *: Cette option peut être configurée pour permettre à SSH de savoir quand envoyer un paquet pour tester la réponse du serveur. Cela peut être utile si votre connexion n’est pas fiable et que vous souhaitez savoir si elle est toujours disponible.
* + LogLevel + *: Ceci configure le niveau de détail dans lequel SSH se connectera du côté client. Cela peut être utilisé pour désactiver la journalisation dans certaines situations ou pour augmenter la verbosité lorsque vous essayez de déboguer. Du moins au plus verbeux, les niveaux sont QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG1, DEBUG2 et DEBUG3.
* + StrictHostKeyChecking + *: Cette option permet de configurer si SSH SSH ajoutera jamais automatiquement des hôtes au fichier + ~ / .ssh / known_hosts +. Par défaut, il sera défini 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, vous pouvez définir ce paramètre sur «non». SSH ajoutera alors automatiquement les hôtes au fichier. Cela peut avoir des implications sur la sécurité, 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é. Généralement, vous n’avez pas à vous soucier de ce paramètre, mais vous pouvez définir ce paramètre sur + / dev / null + si vous avez désactivé la vérification stricte de l’hôte 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 cette option peut être un moyen simple de se familiariser avec la clé de votre hôte, vous permettant ainsi de la reconnaître facilement si vous devez vous connecter à partir d’un autre ordinateur à un moment donné.
* + Compression + *: L’activation de la compression peut être utile pour les connexions très lentes. La plupart des utilisateurs n’en auront pas besoin.

En gardant à l’esprit les éléments de configuration ci-dessus, nous pourrions effectuer un certain nombre de modifications de configuration utiles.

Par exemple, si nous créons et détruisons très rapidement des hôtes chez un fournisseur de cloud, 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

Ceci activera votre clé d’hôte visuel pour votre connexion domestique, vous permettant ainsi de vous familiariser avec elle afin que vous puissiez reconnaître si elle change ou si vous vous connectez à partir d’une autre machine. Nous avons également configuré tout hôte commençant 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 saines.

Transfert de connexion

Une utilisation courante de SSH est le transfert de connexions, permettant une connexion locale vers un tunnel via l’hôte distant ou permettant à la machine distante d’accéder à un tunnel via la machine locale. SSH peut également effectuer un transfert dynamique à l’aide de protocoles tels que SOCKS5, qui incluent les informations de transfert pour l’hôte distant.

Les options qui contrôlent ce comportement sont les suivantes:

* + LocalForward + *: cette option est utilisée pour spécifier une connexion qui transférera le trafic d’un port local vers la machine distante, en le canalisant vers le réseau distant. Le premier argument doit être le port local vers lequel vous souhaitez diriger le trafic et le second argument doit être l’adresse et le port vers lesquels vous souhaitez diriger ce trafic sur l’extrémité distante.
* + RemoteForward + *: Cette option est utilisée pour définir un port distant vers lequel le trafic peut être dirigé afin de permettre un tunnel en dehors de 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 devrait ê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 pouvant être utilisé avec un protocole de transfert dynamique tel que SOCKS5. Le trafic utilisant le protocole de transfert dynamique peut ensuite être dirigé vers ce port de la machine locale et de l’extrémité distante, il sera routé en fonction des valeurs incluses.

Ces options peuvent être utilisées pour transférer des 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

Autre transmission

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

Nous pouvons transférer toutes les clés SSH stockées dans un agent de notre ordinateur local, nous permettant ainsi de nous connecter à partir du système distant en utilisant les informations d’identification stockées sur notre système local. Nous pouvons également démarrer des applications sur un système distant et transmettre l’affichage graphique à notre système local à l’aide du transfert X11.

Voici les directives associées à ces fonctionnalités:

* + ForwardAgent + *: Cette option permet aux clés d’authentification stockées sur notre ordinateur local d’être transférées sur le système auquel vous vous connectez. Cela peut vous permettre de passer d’hôte en hôte à l’aide de vos clés d’accueil.
* + ForwardX11 + *: Si vous souhaitez pouvoir transférer un écran graphique d’une application s’exécutant sur le système distant, vous pouvez activer cette option.

Ces deux options sont «oui» ou «non».

Spécification des clés

Si vous avez configuré des clés SSH pour vos hôtes, ces options peuvent vous aider à gérer les 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. Si vos clés sont dans les emplacements par défaut, chacune d’elles sera essayée et vous n’aurez pas besoin de l’ajuster. Si vous disposez d’un certain nombre de clés, chacune étant affectée à des objectifs différents, vous pouvez utiliser le chemin exact pour trouver la clé correcte.
* + 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 en mémoire des clés alternatives non valides pour l’hôte en question.

Ces options sont particulièrement utiles si vous devez suivre un grand nombre de clés pour différents hôtes et utiliser un ou plusieurs agents SSH pour vous assister.

Multiplexer SSH sur une seule connexion TCP

SSH peut utiliser une seule connexion TCP pour plusieurs connexions SSH au même ordinateur hôte. Cela peut être utile s’il faut un certain temps pour établir une liaison TCP avec l’extrémité distante, ce qui supprime cette surcharge des connexions SSH supplémentaires.

Les options suivantes peuvent être utilisées pour configurer le multiplexage avec SSH:

* + ControlMaster + *: cette option indique à SSH d’autoriser ou non le multiplexage dans la mesure du possible. En règle générale, si vous souhaitez utiliser cette option, vous devez la définir sur «auto» dans la section hôte qui est lente à se connecter ou dans la section générique + Host * +.
* + ControlPath + *: Cette option permet de spécifier le fichier de socket utilisé pour contrôler les connexions. Il devrait être à un emplacement sur le système de fichiers. Généralement, ceci est donné en utilisant des variables SSH pour étiqueter facilement le socket par hôte. Pour nommer la socket en fonction du nom d’utilisateur, de l’hôte distant et du port, vous pouvez utiliser + / path / to / socket / +.
* + ControlPersist + *: Cette option établit le délai en secondes pendant lequel la connexion TCP doit rester ouverte après la fermeture de la connexion SSH finale. Définir ce nombre sur un nombre élevé vous permettra d’ouvrir de nouvelles connexions après la fermeture de la première, mais vous pouvez généralement le définir sur un niveau bas, tel que «1», pour éviter de laisser ouverte une connexion TCP non utilisée.

Généralement, vous pouvez configurer ceci en utilisant une section qui ressemble à ceci:

Host *
   ControlMaster auto
   ControlPath ~/.ssh/multiplex/%r@%h:%p
   ControlPersist 1

Ensuite, vous devez vous assurer que le répertoire est créé:

mkdir -p ~/.ssh/multiplex

Si vous ne souhaitez pas utiliser le multiplexage pour une connexion spécifique, vous pouvez sélectionner aucun multiplexage sur la ligne de commande, comme ceci:

ssh -S none @

Conclusion

À présent, il devrait être clair que vous pouvez fortement personnaliser les options que vous utilisez pour vous connecter à des hôtes distants. Tant que vous gardez à l’esprit la façon dont SSH interprétera les valeurs, vous pouvez établir de riches ensembles de valeurs spécifiques avec des solutions de remplacement raisonnables.

TOC