Quelqu’un doit se connecter à un serveur ce soir, et l’identifiant doit lui parvenir maintenant. La tentation est de coller la clé privée ou le mot de passe root dans Slack. Chaque message par lequel passe cette clé en garde une copie. La meilleure voie est donc un lien à usage unique qui expire : le secret est récupéré une fois, puis il disparaît.
Le lien n’est toutefois que l’étape de livraison. Avant de le créer, choisissez le bon identifiant à envoyer, limitez-le à la tâche et décidez comment vous le retirerez. Ce guide couvre tout cela, y compris la question de ce qu’il faut mettre dans un lien à usage unique pour partager des accès à un serveur, et de ce qu’il faut laisser en dehors.
Quel identifiant SSH partagez-vous réellement ?
Un accès SSH peut reposer sur quatre éléments différents, et chacun obéit à des règles de partage très différentes.
| Identifiant | Ce que c’est | Doit-il circuler ? |
|---|---|---|
| Clé publique | La moitié que stocke le serveur | Oui, librement. Elle n’est pas secrète. |
| Clé privée | La moitié que détient l’utilisateur | Seulement si elle a été générée pour le destinataire, et une seule fois |
| Mot de passe | Une chaîne partagée que vérifie le serveur | Une fois, comme valeur temporaire que vous changerez |
| Certificat SSH | Une clé signée par votre autorité de certification, avec une période de validité | Le certificat n’est pas secret, la clé qui le sous-tend l’est |
La meilleure transmission est celle où rien de secret ne circule. Si le destinataire possède déjà une paire de clés SSH, demandez-lui sa clé publique, ajoutez-la à ~/.ssh/authorized_keys sur le bon compte et dites-lui de se connecter. Supprimer cette seule ligne plus tard met fin à son accès.
Générez une clé dédiée pour lui s’il n’en a pas et ne peut pas en créer. N’envoyez jamais votre propre clé privée de tous les jours. Une clé créée pour le destinataire peut être limitée, journalisée et supprimée sans toucher à rien d’autre.
Préférez les certificats ou un accès géré pour les besoins récurrents. Si la même personne aura besoin d’un accès à plusieurs reprises, des transmissions à usage unique répétées ne sont pas le bon outil. Un certificat SSH de courte validité, ou un outil d’accès comme Teleport ou Tailscale SSH, intègre l’expiration à l’identifiant lui-même au lieu de la greffer sur la livraison.
Limiter l’identifiant avant de le partager
Quoi que vous envoyiez, réduisez-le au strict nécessaire pour la tâche :
- Un compte, un hôte. Ajoutez la clé au compte de service chargé du travail, pas à root, et uniquement sur la machine concernée.
- Restreignez ce que la clé peut faire avec des options de
authorized_keyscommefrom="203.0.113.5",no-port-forwardingou une enveloppecommand=quand la tâche se résume à un seul script. - Donnez une durée de vie au mot de passe. Si vous partagez un mot de passe, utilisez
passwd -eou l’équivalent de la plateforme pour que le destinataire doive le changer à la première connexion, et prévoyez de désactiver le compte à une date fixée. - Notez la date de fin avant d’envoyer quoi que ce soit. « Quand le travail sera fini » n’est pas une date.
Partager des identifiants SSH avec un lien qui expire
- Confirmez l’identité du destinataire par un canal en qui vous avez déjà confiance : le ticket, un fil d’e-mails connu ou un appel. La plupart des identifiants envoyés à la mauvaise personne le sont à cause d’une adresse ressemblante ou d’un nom rempli automatiquement.
- Collez uniquement le secret dans l’outil de liens secrets à usage unique. Pour une clé privée, cela signifie le bloc PEM complet et rien d’autre. Avec LinkPilot, le texte est chiffré dans votre navigateur avant d’être stocké : le service ne détient jamais que du texte chiffré, et la clé qui permet de le déchiffrer se trouve dans la partie de l’URL que les navigateurs n’envoient pas aux serveurs.
- Réglez l’expiration sur la fenêtre réelle. Une heure si la personne attend, 24 heures si elle est dans un autre fuseau horaire, sept jours seulement s’il y a une vraie raison. Le lien est aussi détruit dès sa première ouverture : l’expiration est le filet de sécurité, pas le contrôle principal.
- Ajoutez une phrase de passe avec un compte Pro quand l’identifiant est sensible, et transmettez la phrase de passe par un autre canal. Avec le forfait Pro, l’historique d’audit vous indique aussi à quel moment l’affichage a eu lieu.
- Envoyez le lien avec une ligne expliquant son objet, sans aucun détail de connexion.
- Envoyez les détails de connexion dans un message séparé : hôte ou adresse, port, nom d’utilisateur et méthode d’authentification. Aucun de ces éléments n’est secret à lui seul, mais avec la clé, ils forment l’accès complet.
Si le lien indique qu’il a déjà été ouvert et que le destinataire dit ne pas l’avoir fait, ne discutez pas. Considérez l’identifiant comme exposé, supprimez la clé ou changez le mot de passe, et générez-en un nouveau.
Un lien à usage unique pour partager des accès à un serveur
La question de ce qui doit figurer dans le secret revient à chaque fois. Une bonne règle : le lien contient ce qu’un attaquant ne pourrait pas deviner, et le message ordinaire contient ce qu’il pourrait deviner.
Dans le lien à usage unique :
- La clé privée, ou le mot de passe temporaire
- La phrase de passe de la clé, si une phrase de passe a été définie à la génération
- Rien d’autre
Dans un message ordinaire, envoyé séparément :
- Le nom d’hôte ou l’adresse IP, et le port
- Le compte avec lequel se connecter
- L’utilisation d’une clé ou d’un mot de passe
- L’empreinte de la clé d’hôte, pour que le destinataire puisse vérifier le serveur à la première connexion
- Une courte note sur l’objet de l’accès et sa date de fin
Ne mettez de captures d’écran ou de journaux de terminal ni dans l’un ni dans l’autre. Une capture d’une session en cours contient souvent des jetons, des adresses internes et d’autres noms d’utilisateur qui n’étaient pas censés circuler.
Aider le destinataire à installer la clé en sécurité
Une transmission sécurisée échoue quand même si la clé finit dans le dossier Téléchargements, lisible par tout le monde. Envoyez ces instructions avec les détails de connexion :
# save the key, then lock it down
chmod 600 ~/.ssh/acme_deploy
ssh-add ~/.ssh/acme_deploy
# verify the host key fingerprint against the one you were sent
ssh -i ~/.ssh/acme_deploy deploy@203.0.113.5
Demandez-lui de n’ouvrir le lien secret qu’au moment de s’en servir, sur un appareil qu’il contrôle et avec une connexion de confiance. L’ouvrir sur une machine partagée « pour vérifier que ça marche » laisse une copie dans l’historique du presse-papiers de cette machine.
Vérifier, puis refermer la fenêtre
Tant que la fenêtre d’accès est ouverte, demandez au destinataire de tester la connexion exacte et de confirmer que la tâche s’exécute. N’élargissez pas les droits pour qu’un test réussisse ; corrigez plutôt le périmètre.
Une fois le travail terminé :
- Supprimez la clé publique de
authorized_keys, ou désactivez le compte, ou laissez le certificat expirer comme prévu. - Renouvelez tout ce qui a circulé avec l’identifiant, y compris un mot de passe temporaire qui devait être changé à la première connexion et ne l’a pas été.
- Examinez
auth.logou votre source d’audit SSH pour repérer les connexions en dehors de la période convenue ou depuis des adresses inattendues. - Notez qui a eu quoi, et de quand à quand. La trace reste ; l’identifiant, non.
L’expiration du lien limite la durée pendant laquelle le secret pouvait être récupéré. L’expiration de l’identifiant limite la durée pendant laquelle il peut servir. Il vous faut les deux, et c’est la seconde que l’on oublie.