WardtermClient SSH
FR
Télécharger

Comment partager un accès SSH sans partager sa clé privée

Demandez à chaque personne sa clé publique et ajoutez-la au serveur : dans son propre compte, ou sur une ligne à part dans le ~/.ssh/authorized_keys du compte partagé. Votre clé privée reste sur votre appareil, les journaux indiquent quelle clé a servi, et retirer une personne revient à supprimer une ligne. Pour un accès temporaire, ajoutez expiry-time= à la ligne ou signez un certificat SSH de courte durée.

Mis à jour le . Exécuté avec OpenSSH 10.0 sur Debian 13 dans un conteneur jetable : comptes individuels créés avec install, compte partagé avec une ligne par personne et expiry-time (une ligne expirée a été refusée), certificat utilisateur signé avec -V +8h et accepté via TrustedUserCAKeys, suppression d'une ligne, usermod --expiredate et pkill.

Pourquoi ne pas simplement partager la clé

Envoyer votre clé privée à un collègue, ou une copie d'une clé de déploiement que tout le monde utilise, fonctionne le premier jour et pose problème ensuite :

  • Le serveur ne voit qu'une clé, ses journaux ne peuvent donc pas dire qui a fait quoi.
  • Quand une personne part, le seul moyen de la retirer est une nouvelle clé pour tout le monde.
  • Chaque copie sur un portable, dans un historique de messagerie ou une sauvegarde est un endroit de plus d'où elle peut fuiter.

SSH est conçu pour l'inverse : chaque personne a sa propre paire de clés, garde la partie privée et ne distribue que la partie publique. Un serveur peut faire confiance à autant de clés publiques que vous le souhaitez.

Un compte par personne

La solution la plus propre donne à chacun son propre compte Linux. Demandez sa clé publique, puis sur le serveur :

sudo adduser --disabled-password --gecos "" bob
sudo install -d -m 700 -o bob -g bob /home/bob/.ssh
sudo install -m 600 -o bob -g bob bob.pub /home/bob/.ssh/authorized_keys

Sur RHEL et les systèmes proches, utilisez sudo useradd -m bob pour la première ligne. N'ajoutez le compte au groupe sudo ou wheel que si la personne a besoin de root, comme expliqué dans créer un utilisateur avec accès SSH et sudo. Chaque commande est alors liée à un nom, et les fichiers gardent leur propriétaire.

Plusieurs personnes sur un compte partagé

Parfois, tout le monde doit se connecter avec le même utilisateur, comme deploy ou l'utilisateur par défaut d'une image cloud. Donnez alors à chacun sa propre ligne dans le authorized_keys de ce compte, avec un commentaire qui le nomme :

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGk3... alice@laptop
expiry-time="20261231" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJq8... bob@laptop

L'option expiry-time désactive la ligne de Bob après cette date, sans rien avoir à retenir. D'autres options limitent une clé à certaines adresses ou à une seule commande, voir restreindre une clé SSH. Comme chacun a une clé différente, le journal du serveur les distingue toujours par empreinte :

Accepted publickey for deploy from 203.0.113.25 port 51234 ssh2: ED25519 SHA256:vsze5ORPbYF/MMM4TTtuyy6yiEAYV1CcI4FOF0dV9wI

Listez les empreintes du fichier pour savoir à qui appartient cette clé :

ssh-keygen -lf /home/deploy/.ssh/authorized_keys

Un accès de courte durée avec des certificats

Avec beaucoup de serveurs et des changements fréquents, modifier authorized_keys partout devient pénible. Une autorité de certification SSH règle le problème : les serveurs font confiance à l'AC une fois pour toutes, et vous signez la clé publique de chaque personne pour une durée donnée.

ssh-keygen -t ed25519 -f user_ca -C "team user CA"
ssh-keygen -s user_ca -I bob@example.com -n deploy -V +8h bob.pub

Cela crée bob-cert.pub, valable huit heures pour l'utilisateur deploy. Sur chaque serveur, copiez user_ca.pub vers /etc/ssh/user_ca.pub et ajoutez une ligne à sshd_config :

TrustedUserCAKeys /etc/ssh/user_ca.pub

Bob garde bob-cert.pub à côté de sa clé privée et se connecte comme d'habitude. À l'expiration, l'accès prend fin sans toucher aucun serveur. Gardez la clé de l'AC hors ligne ou dans un système dédié, puisqu'elle peut signer un accès à tout. La configuration complète est dans les certificats SSH expliqués.

Retirer un accès

Pour une ligne de clé, supprimez-la. Supprimer par commentaire est rapide ; pour un nettoyage complet, cherchez par empreinte, comme indiqué dans révoquer une clé SSH au départ d'un collaborateur :

sudo sed -i.bak '/ bob@laptop$/d' /home/deploy/.ssh/authorized_keys

Pour un compte personnel, verrouillez-le pour que ni clé ni mot de passe ne fonctionnent, puis arrêtez tout ce qui tourne encore :

sudo usermod --expiredate 1 bob
sudo pkill -KILL -u bob

Supprimer une clé ne ferme pas les sessions déjà ouvertes : ne sautez pas la deuxième commande. Changez ensuite tout mot de passe, jeton ou clé partagée que la personne connaissait.

Montrer son terminal en direct

Parfois, le besoin n'est pas un accès mais de l'aide : quelqu'un doit vous regarder travailler, ou taper une minute. Sur un serveur où vous avez tous deux un compte, tmux peut partager une session. Créez un groupe pour cela et lancez tmux sur un socket accessible à ce groupe :

sudo groupadd pair
sudo usermod -aG pair alice
sudo usermod -aG pair bob
tmux -S /tmp/pair new -s pair

Depuis une autre fenêtre, ouvrez le socket au groupe et autorisez Bob. tmux 3.3 et suivants refusent les autres utilisateurs tant que vous ne l'avez pas fait :

chgrp pair /tmp/pair
chmod 770 /tmp/pair
tmux -S /tmp/pair server-access -a bob
tmux -S /tmp/pair server-access -r bob

La dernière ligne met Bob en lecture seule ; omettez-la pour le laisser taper. Il rejoint la session avec tmux -S /tmp/pair attach -t pair. Quand vous avez fini, tmux -S /tmp/pair server-access -d bob le retire. Les deux personnes ont besoin d'un compte sur ce serveur, et tout ce que Bob tape s'exécute sous votre identité.

Mots de passe partagés et autres secrets

Certaines choses ne se répartissent pas par personne : un équipement réseau avec un seul mot de passe admin, le mot de passe root d'une base de données, une clé de déploiement pour un dépôt. Gardez-les dans un gestionnaire de mots de passe ou un coffre partagé par l'équipe, pas dans une messagerie ou une page de wiki, pour savoir qui peut les lire. Quand quelqu'un part, changez chaque secret qu'il pouvait voir, car lui retirer l'accès au coffre n'efface pas ce qu'il a déjà copié.

Questions

Deux personnes peuvent-elles utiliser la même clé privée SSH ?

Techniquement oui, mais le serveur ne peut plus les distinguer, et retirer l'accès à l'une oblige à changer la clé pour tout le monde. Donnez plutôt à chacun sa propre clé.

Peut-on envoyer une clé publique par e-mail ou messagerie ?

Oui. Une clé publique est faite pour être partagée. Seule la clé privée, le fichier sans .pub, doit rester sur l'appareil de son propriétaire.

Comment donner un accès pour quelques jours seulement ?

Placez expiry-time="20261231" devant sa clé dans authorized_keys, ou signez sa clé comme certificat avec ssh-keygen -s et une validité comme -V +3d. Les deux cessent de fonctionner d'eux-mêmes.

Peut-on laisser quelqu'un voir son terminal sans lui donner d'accès ?

Oui. Avec tmux, un socket partagé et server-access -r, la personne regarde en lecture seule. Elle doit quand même avoir un compte sur le même serveur pour se rattacher à la session.

Sources

Autres guides : Sécuriser un serveur

Tous les guides