5 trucs et astuces SSH et plus

Dans cet article, nous parlerons d'astuces et de commandes utiles lorsque vous travaillez avec SSH. À savoir:

• Comment utiliser l'authentification à deux facteurs pour les connexions SSH.
• Utilisation sûre du "transfert d'agent".
• Mettre fin à une session bloquée.
• Nous laissons le terminal ouvert lors de la sortie ou de la déconnexion.
• ( Zoom!).

Il existe cinq façons de l'activer.



1. Nous mettons à jour OpenSSH et utilisons des jetons matériels. En février de cette année, la prise en charge des jetons FIDO U2F (Universal Second Factor) a été ajoutée à OpenSSH. Que puis-je dire - c'est génial, mais il y a une mise en garde.



Le fait est que la mise à jour ajoute de nouveaux types de clés pour prendre en charge les jetons. Cependant, cette fonctionnalité ne peut être utilisée que lors de la mise à jour du client et du serveur vers la version 8.2 ou ultérieure. Vous pouvez vérifier la version actuelle du client à l'aide de la commande ssh -V. En ce qui concerne le serveur distant, il vaut la peine d'utiliser nc [nom_serveur] 22.



De plus, deux nouveaux types de clés ont été ajoutés - ecdsa-sk et ed25519-sk. Il existe également des certificats pour eux. Afin de créer des fichiers clés, vous devez insérer un jeton et exécuter la commande



$ ssh-keygen -t ecdsa-sk -f ~ / .ssh / id_ecdsa_sk.



Ce qu'elle fait? Crée des clés publiques et privées liées au jeton U2F. La clé privée sur le jeton est utilisée pour déchiffrer la clé privée stockée sur le disque.



Une autre possibilité consiste à définir un mot de passe pour les fichiers clés comme deuxième facteur. Le fait est qu'OpenSSH fonctionne avec une autre option de génération - sk. Ainsi, les fichiers clés sont stockés sur un jeton matériel et sont toujours avec vous. Pour créer une clé résidente, vous devez utiliser la commande:

$ ssh-keygen -t ecdsa-sk -O resident -f ~/.ssh/id_ecdsa_sk.

Eh bien, pour transférer le fichier de clé sur une nouvelle machine, vous devez insérer le support et exécuter la commande $ ssh-add -K. N'oubliez pas que le jeton doit être activé lors de la connexion.



2. Nous utilisons PIV + PKCS11 et Yubikey. Si vous devez vous connecter à des machines sur lesquelles des versions antérieures du serveur SSH sont installées, il existe une autre option. Voici une instruction détaillée pour U2F + SSH avec PIV / PKCS11 . Un peu délicat mais ça vaut le coup.



3. La troisième méthode consiste à utiliser l'agent yubikey. Voici l' agent SSH pour les Yubikeys lui - même , créé par Filipo Valsorda.



4. Appuyez sur ID et touchez. Une autre façon est d'utiliser Sekey- un agent open source. Il stocke les clés privées dans le système d'enclave sécurisé pour MacOS et vous permet de déclencher la fonction de signature Touch ID.



5. Enfin, utilisez Single Sign On SSH. Voici les instructions de configuration. L'avantage de l'authentification unique SSH est que l'utilisateur peut appliquer la politique de sécurité du fournisseur de compte, y compris la prise en charge de l'authentification multifacteur.

Transfert de clé sécurisé (transfert d'agent)

À quoi sert le transfert de clé? Pour l'accès hôte distant à l'agent utilisateur SSH local. Le fait est que lorsque le client SSH utilise le transfert de clé (le plus souvent ssh -A est activé), il y a 2 canaux pendant la connexion. La première est une session utilisateur interactive, la seconde est un canal de transfert de clé.



L'agent SSH local crée un socket IPC qui se connecte via ce canal à l'hôte distant. Ceci est assez dangereux, car l'utilisateur root sur l'hôte distant a accès à l'agent SSH local de l'utilisateur qui se connecte. Ainsi, il peut être utilisé pour accéder aux ressources du réseau pour le compte de cet utilisateur. Et si vous travaillez avec un agent SSH standard, vous ne découvrirez pas le problème. Mais avec une clé U2F ou Sekey, ce problème peut être supprimé.



En général, vous pouvez transférer la clé, mais il est conseillé de ne pas utiliser cette méthode souvent et pour toutes vos connexions. Il est conseillé de ne l'utiliser que lorsque l'utilisateur est confiant dans la situation.

Déconnexion d'une session SSH bloquée

Les sessions SSH se bloquent souvent en raison de problèmes de réseau, de la perte de contrôle d'un programme en cours d'exécution ou de l'une des séquences d'échappement du terminal bloquant l'entrée au clavier. Il existe plusieurs façons de quitter une session bloquée:



1. Automatiquement lorsque le réseau est déconnecté. Pour ce faire, ajoutez ce qui suit au fichier de configuration SSH, .ssh / config:

ServerAliveInterval 5

ServerAliveCountMax 1



Dans ce cas, ssh vérifiera la connexion en envoyant des demandes d'écho à l'hôte distant à intervalles réguliers. Ils sont définis par le paramètre ServerAliveInterval. S'il y a plus de demandes sans réponse que ServerAliveCountMax, SSH ferme la connexion.



2. Interrompre la session. ssh utilise le caractère ~ comme séquence d'échappement par défaut. La commande ~ ferme la connexion actuelle et revient au terminal.



En outre, le ~? Affiche la liste complète des commandes pouvant être utilisées dans la session en cours. Si vous avez plusieurs mises en page installées, vous devrez appuyer deux fois sur le bouton ~ pour envoyer un caractère.

Laisser le terminal sur l'hôte distant ouvert

Il existe deux options pour enregistrer la session lors de la commutation entre les réseaux.



1. Utilisation de Mosh ou Eternal Terminal



Si vous avez besoin d'une connexion fiable et sans fermeture, même lors de la commutation entre les réseaux, il existe un moyen de sortir - vous devez utiliser Mosh - shell mobile. Mosh fait référence à un shell sécurisé qui utilise SSH pour initialiser une session (handshake). Après cela, elle passe à son propre canal crypté, qui est très stable. Par exemple, il peut gérer diverses situations, y compris les déconnexions, les changements d'adresse IP de l'appareil, les grands retards dans la transmission des données, etc. Tout cela grâce à UDP et au protocole de synchronisation utilisé par Mosh.



Pour travailler avec lui, vous devez tout d'abord l'installer sur le serveur et le client, en ouvrant les ports 60000 à 61000 pour le trafic UDP entrant sur votre hôte distant. Après cela, il vous suffit de taper mosh user @ server pour vous connecter.



Mosh fonctionne au niveau des écrans de terminal et des frappes au clavier, ce qui lui confère de nombreux avantages par rapport à SSH, qui transfère un flux de données binaires d'E / S normales entre les clients et le serveur. Si vous devez synchroniser uniquement l'écran du terminal et les frappes, la connexion interrompue est rétablie beaucoup plus rapidement. Le même SSH doit être stocké dans un tampon et envoyé tout, mais Mosh n'a besoin que de sauvegarder les frappes, synchronisant le dernier état de la fenêtre du terminal avec le client.



2. Utilisation de tmux. Afin de se connecter et de se déconnecter selon les besoins, tout en conservant la même session sur l'hôte distant, il vaut la peine d'utiliser un multiplexeur de terminal appelé tmux . Dans le cas où la connexion SSH tombe, vous devez vous reconnecter et taper tmux attach. L'utilisateur est ensuite renvoyé à la session tmux.



Il offre également plusieurs fonctionnalités supplémentaires, notamment des onglets, des panneaux, les mêmes que dans le terminal macOS, ainsi que la possibilité de travailler avec le terminal avec un autre utilisateur. Vous pouvez obtenir encore plus avec Byobu, un package qui ajoute de nombreuses fonctions pratiques et des raccourcis clavier. Il est livré avec Ubuntu et peut être exécuté sur macOS en utilisant Homebrew.

Partager un terminal distant

Dans certaines situations, vous devez partager une session SSH, par exemple, lors de la résolution de problèmes complexes avec des serveurs. La meilleure façon de procéder est d'utiliser tmux. Pour résoudre le problème, vous devez procéder comme suit:

• Assurez-vous que tmux est installé sur le serveur dans la DMZ (ou à l'emplacement auquel vous souhaitez vous connecter).
• Les deux utilisateurs doivent se connecter au serveur via SSH avec le même compte.
• L'un des utilisateurs doit exécuter tmux pour créer une session tmux.
• Le deuxième utilisateur exécute la commande tmux attach.
• Tout est prêt!

Si vous avez besoin d'affiner les sessions multi-utilisateurs, vous devez utiliser tmate . Il s'agit d'un fork amélioré de tmux.

Conseil d'Expert

Nous avons décidé de compléter la traduction avec nos propres conseils - nous espérons qu'ils seront également utiles. Maxim Klochkov , consultant senior au Network Solutions Center de Jet Infosystems et enseignant du cours Cybersecurity Profession à Skillbox, a partagé son expérience utile .

Redirection de port TCP

Ssh a deux options utiles: -L et -R.



Le paramètre -L organise un port TCP ouvert sur notre ordinateur local, lorsque nous essayons d'établir une connexion TCP à laquelle cette connexion est transmise de manière transparente au tunnel ssh, puis une connexion est établie à partir d'un ordinateur distant.



Le paramètre -L est suivi d'un argument de la forme suivante:

ssh -L XXX:server1:YYY login@server2

Ici, server2 est le serveur distant auquel nous accédons via ssh, login est le nom d'utilisateur sous lequel nous nous connectons au serveur distant, XXX est le numéro de port qui doit être organisé sur l'ordinateur local, server1 est l'hôte auquel nous devons transférer la connexion depuis ce port , et enfin YYY est le port vers lequel cette connexion doit être transmise.



Regardons deux exemples.



Exemple 1.

1. Nous sommes sur le serveur spb.company1.ru et nous voulons tester une application Web qui accède à la base de données à central-db.company1.ru
2. Cette base de données est disponible uniquement à partir du serveur moscow.company1.ru, sur le port 9999
3. Nous organiserons la redirection du port local 55555 vers la base de données via un tunnel ssh comme suit: ssh -L 55555: central-db.company1.ru: 9999 login@moscow.company1.ru
4. Après cela, nous déployons une application Web sur notre serveur local et nous spécifions non pas central-db.company1.ru:9999 comme base, mais localhost: 55555 - cette connexion sera transmise au serveur moscow.company1.ru, et ce serveur établira la connexion avec une base de données sur l'hôte central-db.company1.ru, port 9999

Exemple 2.

1. Nous sommes sur le serveur spb.company1.ru, et nous voulons montrer au client un site Web de test à moscow.company1.ru, port 5000.
2. Il n'y a pas d'accès à ce site depuis Internet, il n'y a qu'un accès interne depuis le même hôte où il est déployé, c'est-à-dire depuis moscow.company1.ru
3. Nous organiserons le transfert du port local 80 à travers le tunnel ssh comme suit ssh -L 80: localhost: 5000 login@moscow.company1.ru
4. Si l'utilisateur entre maintenant dans le navigateur en utilisant le lien spb.company1.ru , la connexion sera transmise via le tunnel ssh au serveur moscow.company1.ru, et ce serveur établira déjà une connexion à l'adresse localhost: 5000, c'est-à-dire à notre site Web de test -site.

Le paramètre -R organise un port TCP ouvert sur le serveur distant, lorsque vous essayez d'établir une connexion TCP, cette connexion est transférée de manière transparente vers le tunnel ssh, puis une connexion est établie à partir du serveur local.



Le paramètre -R est suivi d'un argument sous la forme suivante:

ssh -R XXX:server1:YYY login@server2

Ici, server2 est le serveur distant auquel nous nous connectons via ssh, login est le nom d'utilisateur sous lequel nous nous connectons au serveur distant, XXX est le numéro de port qui doit être organisé sur le serveur distant, server1 est l'hôte auquel nous devons transférer la connexion depuis le serveur distant , et enfin YYY est le port vers lequel cette connexion doit être transmise.



Regardons deux exemples.



Exemple 1.

• Nous sommes sur le serveur moscow.company1.ru, et à partir de ce serveur une base de données est disponible sur le serveur central-db.company1.ru, sur le port 9999.
• Nous déployons une application Web sur le serveur spb.company1.ru, et la base de données n'est pas accessible depuis ce serveur.
• Nous organiserons la redirection de port du serveur spb.company1.ru vers la base de données comme suit: ssh -R 55555: central-db.company1.ru: 9999 login@spb.company1.ru
• Après cela, nous déployons notre application Web sur le serveur spb.company1.ru, mais nous ne spécifions pas central-db.company1.ru:9999 comme base, car ce serveur n'est pas disponible pour nous, mais localhost: 55555 - cette connexion sera transmise à notre local machine via un tunnel ssh, puis la machine locale établira une connexion au serveur central-db.company1.ru, port 9999.

Exemple 2.

• Nous sommes sur le serveur moscow.company1.ru et avons un site Web de test déployé sur notre serveur, sur le port 5000.
• Ce site Web de test n'est disponible que localement, les connexions à partir d'Internet ne sont pas autorisées, mais nous voulons montrer ce site Web à un client qui peut utiliser un navigateur Web pour accéder au serveur spb.company1.ru
• Nous organiserons la redirection de port depuis le serveur spb.company1.ru comme suit: ssh -R 80: localhost: 5000 login@spb.company1.ru
• Si l'utilisateur entre maintenant dans le navigateur en utilisant le lien spb.company1.ru , la connexion sera transmise via le tunnel ssh à notre serveur local moscow.company1.ru, et une connexion sera établie à partir de celui-ci vers localhost: 5000 - c'est-à-dire vers notre site Web de test site.

Quelles astuces pouvez-vous partager?

Sur ce sujet:

• L'article " Comment utiliser Bash exécutera la tâche ";
• Cours pratique en ligne " Linux‌ OS Administration ".