Get best of the week

À propos de l'agent SSH

introduction


SSH-agent fait partie d'OpenSSH. Dans cet article, je vais vous expliquer ce qu'est un agent, comment l'utiliser et comment il fonctionne pour garder vos clés en sécurité. Je décrirai également le transfert d'agent et son fonctionnement. Je vous aiderai à réduire le risque d'utiliser le transfert d'agent et partagerai une alternative au transfert d'agent que vous pouvez utiliser lorsque vous accédez à vos hôtes internes via des bastions.

Qu'est-ce qu'un agent SSH


ssh-agentEst un gestionnaire de clés pour SSH. Il stocke vos clés et certificats en mémoire, non cryptés et prêts à l'emploi ssh. Cela élimine la nécessité de saisir un mot de passe chaque fois que vous vous connectez au serveur. Il s'exécute en arrière-plan sur votre système, distinct sshet démarre généralement au premier démarrage ssh.

L'agent SSH garde les clés secrètes en sécurité car il ne :

  • Il n'écrit aucune information clé sur le disque.
  • Il ne vous permet pas d'exporter vos clés privées.

Les clés secrètes stockées dans l'agent ne peuvent être utilisées que dans un seul but: signer un message.

Mais si un agent ne peut signer que des messages, comment SSH crypte-t-il et décrypte-t-il le trafic?

Dans la première étude des clés publiques et privées SSH, il est naturel de supposer que SSH utilise ces paires de clés pour chiffrer et déchiffrer le trafic. C'est exactement ce que je pensais. Mais ce n'est pas le cas. La paire de clés SSH est utilisée uniquement pour l'authentification lors de la connexion initiale.

Par exemple, voici comment vérifier une clé utilisateur lors d'une connexion SSH, du point de vue du serveur:

  • Le client fournit au serveur une clé publique.
  • Le serveur génère et envoie un court message aléatoire demandant au client de le signer à l'aide d'une clé privée.
  • Le client demande à l'agent SSH de signer le message et renvoie le résultat au serveur.
  • Le serveur vérifie la signature à l'aide de la clé publique du client.
  • Maintenant, le serveur a la preuve que le client possède la clé privée.

Plus tard, pendant le processus de connexion, un ensemble de nouvelles clés éphémères et symétriques sont générées et utilisées pour crypter le trafic de session SSH. Ces clés peuvent même ne pas durer une session entière; L'événement rekey se produit à intervalles réguliers.

Protocole d'agent


SSH utilise un socket de domaine Unix pour communiquer avec l'agent via le protocole d'agent SSH . La plupart des gens utilisent ssh-agentcelui fourni avec OpenSSH, mais il existe de nombreuses alternatives open source.

Le protocole de l'agent est si simple que vous pourriez écrire un agent SSH de base en un jour ou deux. Il n'a que quelques opérations de base:

  • Ajouter une paire de clés normale (clés privées publiques et déchiffrées)
  • Ajouter une paire de clés limitée (clés privées publiques et déchiffrées)
  • Ajouter une clé (régulière ou limitée) à partir de la carte à puce (clé publique uniquement)
  • Supprimer la clé
  • Liste des clés stockées dans l'agent
  • Signature d'un message avec une clé stockée dans l'agent
  • Verrouiller ou déverrouiller un agent entier avec un mot de passe

Qu'est-ce qu'une clé limitée? Il s'agit généralement d'une clé qui a une durée de vie limitée ou nécessite une confirmation explicite de l'utilisateur lors de son utilisation.

La commande ssh-addest votre passerelle vers l'agent SSH. Il effectue toutes ces opérations à l'exception de la signature. Lorsque vous exécutez ssh-add sans aucun paramètre, il recherchera dans votre répertoire personnel des clés standard et les ajoutera à votre agent. Par défaut, il recherche:

  • ~/.ssh/id_rsa
  • ~/.ssh/id_ed25519
  • ~/.ssh/id_dsa
  • ~/.ssh/id_ecdsa

Dès que vous ajoutez les clés au trousseau, elles seront automatiquement utilisées ssh.

ssh-et le trousseau macOS
ssh-agent , fourni avec macOS, peut stocker la phrase secrète des clés dans le trousseau macOS, ce qui facilite encore plus la réajout de clés à l'agent après un redémarrage. Selon vos paramètres de trousseau, vous devrez peut-être encore le déverrouiller après un redémarrage. Pour enregistrer les mots de passe clés dans le trousseau, exécutez la commande ssh-add -K [ ]. Les mots de passe sont généralement stockés dans des «éléments locaux». ssh-agentutilisera ces mots de passe enregistrés automatiquement si nécessaire.

Qu'est-ce que le transfert d'agent


La fonction de transfert d'agent permet à votre agent SSH local de communiquer via une connexion SSH existante et de s'authentifier de manière transparente sur un serveur plus distant. Par exemple, supposons que vous vous connectiez à EC2 via SSH et que vous souhaitiez cloner un référentiel GitHub privé à partir de là. Sans transfert d'agent, vous devrez stocker une copie de votre clé privée GitHub sur l'hôte EC2. Lorsque l'agent est redirigé, le client SSH sur EC2 peut utiliser les clés de votre ordinateur local pour l'authentification sur GitHub.

Fonctionnement du transfert d'agent


Tout d'abord, un peu d'histoire. Les connexions SSH peuvent avoir plusieurs canaux. Voici un exemple courant: une connexion interactive à l'hôte bastion (jump box) est effectuée sur un canal. Lorsque le transfert d'agent est activé pour la connexion (généralement en utilisant ssh -A), un deuxième canal s'ouvre en arrière-plan pour renvoyer toutes les demandes d'agent vers votre ordinateur local.

En termes de ssh, il n'y a pas de différence entre distant et local ssh-agent. SSH examine toujours la variable d'environnement $SSH_AUTH_SOCKpour trouver le socket de domaine Unix pour l'agent. Lors de la connexion à un hôte distant avec le transfert d'agent activé, SSHD crée un socket de domaine Unix distant qui est associé au canal de transfert d'agent et exporte $SSH_AUTH_SOCKqui pointe vers celui-ci.

image

Le transfert d'agent est associé à un certain risque


Lorsque vous redirigez un socket de domaine ssh-agentUnix vers un hôte distant, cela pose un risque pour la sécurité: toute personne disposant d'un accès root sur l'hôte distant peut accéder discrètement à votre agent SSH local via le socket. Ils peuvent utiliser vos clés pour vous faire passer pour d'autres machines du réseau.

Voici un exemple de ce à quoi cela pourrait ressembler:

image

Comment réduire vos risques avec le transfert d'agent


Voici quelques moyens de sécuriser la redirection d'agent:

  • Ne pas activer ForwardAgentpar défaut.


Bloquez votre agent ssh lorsque vous utilisez le transfert d'agent. ssh-add -xbloque l'agent avec un mot de passe et le ssh-add -Xdéverrouille. Lorsque vous êtes connecté à un hôte distant avec transfert d'agent, personne ne peut entrer dans votre agent sans mot de passe.

Ou utilisez un autre agent SSH qui vous demande quand il est utilisé. Sekey utilise Touch ID sur macOS pour stocker les clés dans l'enclave de sécurité MacBook Pro.

Ou n'utilisez pas du tout le transfert d'agent. Si vous essayez d'accéder aux hôtes internes via bastion, il ProxyJumpexiste une alternative beaucoup plus sûre pour ce cas d'utilisation. (voir ci-dessous)

Utilisation ProxyJump: une alternative plus sûre


Lorsque vous souhaitez passer par l'hôte bastion (jumpbox), vous n'avez vraiment pas besoin de la redirection d'agent. La meilleure approche consiste à utiliser la directive ProxyJump.

Au lieu de rediriger l'agent via un canal séparé, il ProxyJumpredirige l'entrée et la sortie standard de votre client SSH local via bastion et vers l'hôte distant. Voici comment ça fonctionne:

  1. Exécutez ssh -J bastion.example.com cloud.computer.internalpour vous connecter cloud.computer.internalvia votre hôte bastion bastion.example.com. cloud.computer.internalEst le nom d'hôte qui peut être trouvé en recherchant DNS sur bastion.example.com.
  2. Votre client SSH utilise les clés de votre agent pour se connecter bastion.example.com.
  3. Après avoir connecté SSHD à bastion, il se connecte cloud.computer.internalet transfère cette connexion à votre client SSH local.
  4. Votre client SSH local passe à nouveau par la connexion, cette fois avec cloud.computer.internal

Vous pouvez le considérer comme SSH dans une session SSH; sauf que ssh ne tourne jamais sur bastion. Au lieu de cela, il se sshdconnecte cloud.computer.internalet donne le contrôle de cette connexion (entrée et sortie standard) à votre SSH local, qui établit ensuite une deuxième connexion.

Configurer ProxyJump

Disons que bastion-host ceci bastion.example.com. Je peux configurer mon ~/.ssh/configcomme ceci:

Host bastion.example.com
	User carl

Host *.computer.internal
	ProxyJump bastion.example.com
	User carl

Ensuite, je cours ssh cloud.computer.internalpour me connecter à la destination interne via bastion - sans transfert d'agent.

Si ProxyJump ne fonctionne pas ...

Les anciennes versions de SSH et SSHD (antérieures à la version 7.2, publiées en 2016) ne prennent pas en charge ProxyJump. Mais vous pouvez effectuer une opération équivalente à l'aide de ProxyCommandet netcat . Voici un exemple:

ssh -o ProxyCommand="ssh bastion.example.com nc %h %p" cloud.computer.internal

La magie ici est que SSH lui-même est le serveur proxy que vous utilisez pour SSH. La partie nc %h %pouvre simplement la connexion de socket brute sur cloud.computer.internalle port 22. L'entrée / sortie standard de la commande parent ssh est passée directement à ProxyCommandafin que le parent ssh puisse s'authentifier auprès de l'hôte interne via une connexion proxy.


image
Apprenez en détail comment obtenir une profession recherchée à partir de zéro ou passer au niveau supérieur en compétences et en salaire en suivant les cours en ligne de SkillFactory:



Lire la suite


More articles:


All Articles