Configurer l'agent SSH et gérer plusieurs clés SSH sur un VPS Linux

Pourquoi plusieurs cles SSH et un agent

Le protocole Secure Shell (SSH) utilise un chiffrement asymetrique : une cle privee reste sur votre machine locale et une cle publique est deposee sur chaque serveur SSH distant dans le fichier ~/.ssh/authorized_keys. Pour se connecter en SSH a la machine distante, le client SSH prouve la possession de la cle privee par un echange cryptographique. Utiliser une seule paire de cles pour tous vos VPS Linux et serveurs dedies presente un risque : si la cle privee est compromise, toutes vos machines distantes sont exposees.

La bonne pratique est de generer une cle privee distincte par serveur SSH distant (ou par role) et de les proteger toutes avec une passphrase de chiffrement robuste. Sans agent, vous retapez la passphrase a chaque commande pour se connecter en SSH, sftp ou rsync vers le serveur.

ssh-agent retient les cles privees dechiffrees en memoire pendant la session. Une fois la cle ajoutee avec ssh-add, la commande SSH interroge l'agent sur la machine locale plutot que de redemander la passphrase a chaque connexion SSH vers la machine distante. Vous ne tapez la passphrase qu'une seule fois par session de travail.

~/.ssh/config complete l'agent : il associe chaque alias de connexion SSH a son HostName, son nom d'utilisateur, son port TCP et sa cle privee (IdentityFile). Il transforme ssh -i ~/.ssh/cle_vps1 user@1.2.3.4 -p 2222 en simple ssh vps1. Les clients sftp, rsync et scp respectent aussi ce fichier de configuration.

Generer plusieurs paires de cles SSH

Pour se connecter en SSH a chaque serveur distant avec une cle distincte, generez une paire de cles Ed25519 par serveur. Ed25519 est l'algorithme de chiffrement recommande : cles courtes, cryptographie moderne, supporte sur toutes les distributions Linux actuelles (Ubuntu 22.04, Debian 12, Rocky Linux 9).

# Cle privee pour se connecter en SSH au VPS de jeu
ssh-keygen -t ed25519 -f ~/.ssh/id_vps_jeu -C "vps-jeu@elypsecloud"

# Cle privee pour le serveur dedie d'administration
ssh-keygen -t ed25519 -f ~/.ssh/id_dedie_admin -C "dedie-admin@elypsecloud"

# Cle privee pour le serveur de sauvegarde distant (SFTP ou rsync)
ssh-keygen -t ed25519 -f ~/.ssh/id_backup_distant -C "backup@elypsecloud"

Choisissez une passphrase de chiffrement differente et robuste pour chaque cle privee. L'option -f specifie le chemin du fichier (cle publique generee avec le suffixe .pub). L'option -C est un commentaire lisible dans les logs SSH du serveur distant pour identifier la cle lors d'un audit.

Copiez chaque cle publique sur le serveur SSH distant correspondant :

# Copie via ssh-copy-id (ecrit dans ~/.ssh/authorized_keys sur la machine distante)
ssh-copy-id -i ~/.ssh/id_vps_jeu.pub user@adresse_ip_vps

# Ou ajout manuel de la cle publique a authorized_keys sur le serveur SSH distant
cat ~/.ssh/id_vps_jeu.pub | ssh user@adresse_ip_vps "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Demarrer ssh-agent et se connecter en SSH

Sur Ubuntu et Debian, un agent SSH est souvent demarre automatiquement via la session graphique ou PAM. Pour verifier si un agent est actif sur la machine locale :

echo $SSH_AUTH_SOCK

Si la variable retourne un chemin de socket Unix (ex. /tmp/ssh-XXXXXXXX/agent.1234), l'agent est actif. Sinon, demarrez-en un sur la machine locale :

eval "$(ssh-agent -s)"

La commande suivante lance l'agent et exporte ses variables d'environnement dans le shell courant :

• SSH_AUTH_SOCK : chemin du socket Unix sur la machine locale via lequel le client SSH contacte l'agent pour les authentifications vers le serveur SSH distant.
• SSH_AGENT_PID : PID du processus agent sur la machine locale. Utilisez kill $SSH_AGENT_PID ou ssh-agent -k pour arreter l'agent proprement.

Verifiez que l'agent fonctionne et listez les cles privees chargees :

ssh-add -l

La reponse The agent has no identities confirme que l'agent est operationnel mais ne contient encore aucune cle pour se connecter en SSH.

Charger des cles privees dans l'agent avec ssh-add

Ajoutez les cles privees que vous utiliserez pour vous connecter en SSH dans la session courante :

# Ajouter une cle privee pour se connecter au serveur SSH distant
ssh-add ~/.ssh/id_vps_jeu

# Ajouter une cle privee avec expiration automatique apres 8 heures
ssh-add -t 28800 ~/.ssh/id_dedie_admin

# Lister les cles privees chargees dans l'agent avec empreinte SHA256
ssh-add -E sha256 -l

# Retirer une cle privee specifique de l'agent
ssh-add -d ~/.ssh/id_vps_jeu

# Retirer toutes les cles privees de l'agent (deconnexion SSH impossible ensuite)
ssh-add -D

L'option -t definit une duree de vie en secondes pour la cle privee dans l'agent. La cle expire automatiquement, ce qui limite la fenetre de risque si votre machine locale est laissee sans surveillance. Pour l'administration de serveurs dedies critiques, 3600 secondes (1 heure) est recommande. Pour les VPS de jeu et transferts SFTP frequents, 28800 secondes (8 heures) couvre une journee de travail.

Fichier ~/.ssh/config : un serveur SSH distant, une cle

Le fichier de configuration ~/.ssh/config sur la machine locale associe chaque alias de connexion SSH a son HostName, son nom d'utilisateur, son port TCP et sa cle privee (IdentityFile). La commande suivante ssh vps-jeu remplace ssh -i ~/.ssh/id_vps_jeu ubuntu@1.2.3.4 pour se connecter en SSH a la machine distante.

# VPS de jeu principal
Host vps-jeu
    HostName 1.2.3.4
    User ubuntu
    IdentityFile ~/.ssh/id_vps_jeu
    IdentitiesOnly yes
    AddKeysToAgent yes

# Serveur dedie d'administration (port TCP change)
Host dedie-admin
    HostName 5.6.7.8
    User root
    Port 2222
    IdentityFile ~/.ssh/id_dedie_admin
    IdentitiesOnly yes
    AddKeysToAgent yes

# Serveur de sauvegarde distant (SFTP et rsync)
Host backup-server
    HostName backup.exemple.com
    User backup
    IdentityFile ~/.ssh/id_backup_distant
    IdentitiesOnly yes

Directives de configuration SSH :

• IdentitiesOnly yes : le client SSH n'utilise que la cle privee specifiee dans IdentityFile pour se connecter a la machine distante, ignorant les autres cles de l'agent. Evite les erreurs Too many authentication failures.
• AddKeysToAgent yes : ajoute automatiquement la cle privee a ssh-agent a la premiere connexion SSH reussie. La commande suivante ssh vps-jeu depuis un nouveau terminal charge la cle et ne demande la passphrase qu'une fois.
• Port : port TCP du serveur SSH distant, a changer pour ameliorer la securite (voir securiser SSH sur VPS Linux).

Appliquez les permissions correctes sur le fichier de configuration SSH sur la machine locale :

chmod 600 ~/.ssh/config && chmod 700 ~/.ssh && chmod 600 ~/.ssh/id_*

Demarrage automatique de l'agent au login

Pour que l'agent SSH soit automatiquement actif sur la machine locale sans intervention, ajoutez dans ~/.bashrc ou ~/.zshrc :

if [ -z "$SSH_AUTH_SOCK" ]; then
    eval "$(ssh-agent -s)" > /dev/null
fi

Ce script verifie si la variable SSH_AUTH_SOCK est vide avant de demarrer un nouvel agent sur la machine locale, evitant les processus orphelins. Sur Ubuntu 22.04 et Debian 12, un agent SSH systeme est souvent deja actif et ce script n'est pas necessaire.

SFTP et rsync avec l'agent SSH

Avec l'agent SSH actif et le fichier de configuration en place, les transferts de fichiers vers le serveur SSH distant se font sans saisir de passphrase. Les commandes sftp, rsync et scp lisent le fichier ~/.ssh/config et interrogent l'agent via SSH_AUTH_SOCK :

# Connexion SFTP au VPS de jeu configure dans ~/.ssh/config
sftp vps-jeu:/home/ubuntu/scripts/ ./scripts/

# Synchronisation rsync vers le serveur de sauvegarde distant
rsync -avz /var/data/ backup-server:/backups/

# Copie de fichier vers le serveur dedie via scp
scp ./config.yml dedie-admin:/etc/app/

Pour les scripts automatises qui transferent des fichiers via sftp ou rsync sans interaction humaine (cron ou systemd timers), utilisez une cle privee sans passphrase dediee a cette tache. Voir notre guide sur les tunnels SSH pour les connexions automatisees securisees.

Transfert de l'agent vers une machine distante

Le transfert d'agent (ForwardAgent) permet d'utiliser les cles privees de votre agent local depuis un serveur SSH intermediaire (bastion), sans deposer de cle privee sur la machine distante intermediaire :

Host bastion
    HostName bastion.exemple.com
    User ubuntu
    IdentityFile ~/.ssh/id_bastion
    ForwardAgent yes

Pour se connecter en SSH depuis le bastion a un VPS du reseau local interne, votre agent local repond aux demandes d'authentification SSH a travers le tunnel. Activez ForwardAgent uniquement vers des serveurs SSH de confiance que vous administrez directement.

Bonnes pratiques de securite SSH

• Toujours chiffrer les cles privees SSH avec une passphrase. Une cle privee sans chiffrement est un mot de passe en clair sur la machine locale. ssh-agent evite de retaper la passphrase, pas de la supprimer.
• Permissions strictes sur les fichiers : chmod 600 ~/.ssh/id_*, chmod 600 ~/.ssh/config. Le client SSH refuse les cles privees avec des permissions trop larges.
• Durees de vie courtes pour les cles d'administration : ssh-add -t 3600 pour les serveurs SSH distants critiques, pour limiter la fenetre de risque si la machine locale est compromise.
• Ne jamais deposer de cle privee sur un VPS ou serveur SSH distant. Seules les cles publiques (.pub) vont dans ~/.ssh/authorized_keys sur la machine distante.
• Auditer les cles autorisees sur chaque serveur SSH distant : verifiez ~/.ssh/authorized_keys regulierement. Voir notre guide sur l'analyse des echecs de connexion SSH dans les logs.

Pour approfondir la securisation de votre VPS Linux : consultez notre guide sur la securisation SSH, notre guide sur la limitation des tentatives SSH, notre guide sur configurer une cle SSH sans perdre l'acces, et notre guide sur creer un tunnel SSH.