Créer une clé SSH pour se connecter sans mot de passe

SSH permet de se connecter à un serveur distant de manière chiffrée. Par défaut, vous pouvez vous authentifier avec un mot de passe. Cependant, pour administrer un serveur, lancer des sauvegardes ou automatiser des transferts, les clés SSH sont plus propres, plus rapides et plus fiables.

Dans ce guide, nous allons créer une clé SSH moderne avec Ed25519, copier la clé publique sur un serveur distant, puis ouvrir une session sans mot de passe interactif.

Attention toutefois au vocabulaire : “sans mot de passe” ne veut pas forcément dire “sans sécurité”. Dans beaucoup de cas, la meilleure pratique consiste à utiliser une clé protégée par une passphrase, puis à la charger dans ssh-agent. Pour les scripts automatisés, on peut utiliser une clé sans passphrase, mais il faut alors la restreindre côté serveur. Sinon, c’est une porte automatique. Et les portes automatiques, c’est formidable dans les supermarchés, moins sur un serveur root.

Comment fonctionne une clé SSH ?

Une clé SSH repose sur une paire de fichiers :

• la clé privée, qui reste sur votre machine ;
• la clé publique, que vous copiez sur les serveurs où vous voulez vous connecter.

Lors de la connexion, le serveur vérifie que votre client possède bien la clé privée correspondant à la clé publique autorisée. La clé privée ne doit jamais être transmise, copiée sur un serveur tiers, envoyée par email ou collée dans un ticket support. Jamais. Même si le ticket dit “urgent”. Surtout s’il dit “urgent”.

La clé publique, elle, peut être ajoutée dans le fichier ~/.ssh/authorized_keys du compte distant.

Clé avec passphrase ou sans passphrase ?

Avant de générer la clé, choisissez le bon modèle.

Cas d’usage	Recommandation
Connexion depuis votre ordinateur personnel	Clé avec passphrase + ssh-agent
Administration serveur régulière	Clé avec passphrase + agent
Git, déploiements depuis votre poste	Clé avec passphrase + agent
Cron, sauvegarde automatisée, rsync nocturne	Clé dédiée sans passphrase, mais restreinte côté serveur
Accès root direct	À éviter. Préférez un utilisateur sudo.

Pour un poste de travail, une passphrase protège la clé privée si votre machine est compromise. Grâce à ssh-agent, vous ne la saisissez pas à chaque connexion.

Pour un script cron, personne ne sera là pour saisir la passphrase. Dans ce cas, une clé sans passphrase peut se justifier, mais elle doit être dédiée à une seule tâche et limitée côté serveur.

Créer une clé SSH Ed25519

Depuis votre machine locale, ouvrez un terminal et lancez :

ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519 -C "matt@skyminds"Code language: JavaScript (javascript)

Explication rapide :

• -t ed25519 crée une clé Ed25519 ;
• -a 100 augmente le nombre de tours de dérivation de clé pour protéger la clé privée ;
• -f ~/.ssh/id_ed25519 définit le chemin du fichier ;
• -C ajoute un commentaire utile pour identifier la clé.

Quand ssh-keygen demande une passphrase, vous avez deux options :

• entrez une passphrase solide pour un usage humain ;
• appuyez deux fois sur Entrée pour une clé sans passphrase, réservée à une automatisation contrôlée.

Vous obtenez deux fichiers :

• ~/.ssh/id_ed25519 : clé privée ;
• ~/.ssh/id_ed25519.pub : clé publique.

Ne confondez pas les deux. La clé privée reste chez vous. La clé publique va sur le serveur.

Créer une clé sans passphrase pour un script automatisé

Pour une sauvegarde automatisée, un rsync nocturne ou un déploiement non interactif, créez une clé dédiée, avec un nom explicite.

ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519_backup -C "backup@$(hostname)-$(date +%F)" -N ""Code language: JavaScript (javascript)

Ici, -N "" indique une passphrase vide. C’est pratique pour l’automatisation, mais cela rend la clé privée beaucoup plus sensible. Si quelqu’un vole cette clé, il peut l’utiliser sans obstacle. Il faut donc la restreindre côté serveur, comme nous le verrons plus bas.

Évitez de réutiliser votre clé personnelle pour les tâches automatiques. Une clé par usage, c’est plus simple à révoquer, plus lisible dans les logs et beaucoup moins dangereux.

Vérifier les permissions du dossier .ssh

OpenSSH refuse parfois une clé si les permissions sont trop ouvertes. C’est une bonne chose : une clé privée lisible par tout le monde n’est plus vraiment privée.

Sur votre machine locale :

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

Pour une clé dédiée aux sauvegardes :

chmod 600 ~/.ssh/id_ed25519_backup
chmod 644 ~/.ssh/id_ed25519_backup.pubCode language: JavaScript (javascript)

Sur le serveur distant, le dossier ~/.ssh et le fichier authorized_keys doivent aussi avoir des permissions strictes.

Copier la clé publique sur le serveur avec ssh-copy-id

La méthode la plus simple consiste à utiliser ssh-copy-id. Elle ajoute votre clé publique dans ~/.ssh/authorized_keys sur le serveur distant.

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@example.comCode language: JavaScript (javascript)

Pour une clé dédiée aux sauvegardes :

ssh-copy-id -i ~/.ssh/id_ed25519_backup.pub backup@example.comCode language: JavaScript (javascript)

Lors de cette commande, le serveur demande encore le mot de passe du compte distant. C’est normal : vous installez la clé. Les connexions suivantes pourront utiliser la clé SSH.

Testez ensuite la connexion :

ssh user@example.comCode language: CSS (css)

Ou avec une clé spécifique :

ssh -i ~/.ssh/id_ed25519_backup backup@example.comCode language: JavaScript (javascript)

Copier la clé manuellement si ssh-copy-id n’est pas disponible

Sur certaines machines, ssh-copy-id n’est pas disponible. Vous pouvez copier la clé publique à la main.

cat ~/.ssh/id_ed25519.pub | ssh user@example.com '
  mkdir -p ~/.ssh
  chmod 700 ~/.ssh
  cat >> ~/.ssh/authorized_keys
  chmod 600 ~/.ssh/authorized_keys
'Code language: PHP (php)

Cette commande ajoute la clé publique au fichier authorized_keys, puis corrige les permissions.

Si vous utilisez la clé de sauvegarde :

cat ~/.ssh/id_ed25519_backup.pub | ssh backup@example.com '
  mkdir -p ~/.ssh
  chmod 700 ~/.ssh
  cat >> ~/.ssh/authorized_keys
  chmod 600 ~/.ssh/authorized_keys
'Code language: PHP (php)

Configurer un alias SSH propre

Au lieu de taper l’utilisateur, le serveur et le chemin de clé à chaque fois, créez une entrée dans ~/.ssh/config.

nano ~/.ssh/configCode language: JavaScript (javascript)

Ajoutez :

Host production
    HostName example.com
    User user
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yesCode language: JavaScript (javascript)

Ensuite, connectez-vous simplement avec :

ssh production

Pour une clé de sauvegarde :

Host backup-server
    HostName example.com
    User backup
    IdentityFile ~/.ssh/id_ed25519_backup
    IdentitiesOnly yesCode language: JavaScript (javascript)

IdentitiesOnly yes évite que le client SSH essaie toutes les clés chargées dans l’agent. C’est plus rapide et cela évite parfois un refus après trop de tentatives d’authentification.

Utiliser ssh-agent pour ne pas retaper la passphrase

Si votre clé est protégée par une passphrase, utilisez ssh-agent. Vous saisissez la passphrase une fois, puis l’agent garde la clé déverrouillée pendant votre session.

Démarrer l’agent :

eval "$(ssh-agent -s)"Code language: JavaScript (javascript)

Ajouter la clé :

ssh-add ~/.ssh/id_ed25519Code language: JavaScript (javascript)

Lister les clés chargées :

ssh-add -l

Sur macOS et beaucoup d’environnements Linux desktop, l’agent est déjà intégré au système ou au trousseau de clés. Vous n’avez donc pas toujours besoin de lancer ssh-agent manuellement.

Restreindre une clé SSH sans passphrase côté serveur

Une clé sans passphrase doit être traitée comme un jeton d’accès. Pour limiter les dégâts en cas de fuite, restreignez-la dans ~/.ssh/authorized_keys sur le serveur distant.

Ouvrez le fichier :

nano ~/.ssh/authorized_keysCode language: JavaScript (javascript)

Une ligne classique ressemble à ceci :

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... backup@serverCode language: CSS (css)

Pour une sauvegarde rsync, vous pouvez ajouter des restrictions avant la clé :

from="203.0.113.10",restrict,no-pty,no-agent-forwarding,no-X11-forwarding ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... backup@serverCode language: JavaScript (javascript)

Cette ligne limite l’usage de la clé à l’adresse IP 203.0.113.10 et désactive plusieurs fonctionnalités inutiles pour une tâche automatisée.

Pour aller plus loin, vous pouvez forcer une commande précise :

from="203.0.113.10",command="/usr/local/sbin/run-backup-receiver",restrict,no-pty,no-agent-forwarding,no-X11-forwarding ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... backup@serverCode language: JavaScript (javascript)

Dans ce modèle, même si la clé est volée, elle ne donne pas un shell complet. Elle lance seulement la commande autorisée. C’est exactement ce que vous voulez pour un compte de sauvegarde.

Exemple : utiliser la clé avec rsync

Voici un exemple simple de synchronisation avec une clé dédiée :

rsync -avz \
  -e "ssh -i ~/.ssh/id_ed25519_backup -o IdentitiesOnly=yes" \
  /home/www/example.com/public_html/ \
  backup@example.com:/srv/backups/example.com/Code language: JavaScript (javascript)

Pour un cron, utilisez toujours les chemins absolus quand c’est possible, et loggez la sortie.

0 3 * * * /usr/bin/rsync -az -e "/usr/bin/ssh -i /home/user/.ssh/id_ed25519_backup -o IdentitiesOnly=yes" /home/www/example.com/public_html/ backup@example.com:/srv/backups/example.com/ >> /var/log/rsync-backup.log 2>&1Code language: JavaScript (javascript)

Si la commande fonctionne en shell mais pas en cron, pensez à l’environnement minimal de cron. PATH, agent SSH, variables et dossier courant ne sont pas les mêmes. Cron n’est pas méchant. Il est juste très littéral.

Désactiver l’authentification par mot de passe côté serveur

Une fois la connexion par clé validée, vous pouvez durcir le serveur SSH en désactivant l’authentification par mot de passe. Faites-le seulement après avoir testé la connexion par clé dans une seconde session ouverte.

Sur Debian ou Ubuntu, créez un fichier dédié :

sudo nano /etc/ssh/sshd_config.d/99-hardening.conf

Ajoutez par exemple :

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Vérifiez la configuration avant de recharger SSH :

sudo sshd -t

Puis rechargez le service :

sudo systemctl reload ssh

Selon la distribution, le service peut s’appeler ssh ou sshd :

systemctl status ssh --no-pager
systemctl status sshd --no-pager

Gardez votre session SSH actuelle ouverte pendant le test. Ouvrez une deuxième connexion pour vérifier. Fermer la seule session fonctionnelle juste après avoir touché à sshd_config, c’est une forme très pure d’optimisme.

Diagnostiquer une connexion SSH par clé qui échoue

Si la connexion demande encore le mot de passe ou affiche Permission denied (publickey), lancez SSH en mode verbeux :

ssh -vvv user@example.comCode language: CSS (css)

Pour forcer une clé précise :

ssh -vvv -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes user@example.comCode language: JavaScript (javascript)

Sur le serveur, consultez les logs :

sudo journalctl -u ssh -n 100 --no-pager
sudo journalctl -u sshd -n 100 --no-pager

Selon la distribution, vous pouvez aussi regarder :

sudo tail -n 100 /var/log/auth.log
sudo tail -n 100 /var/log/secureCode language: JavaScript (javascript)

Checklist des erreurs fréquentes

• La clé publique n’est pas dans le bon fichier authorized_keys.
• Le dossier ~/.ssh du serveur n’est pas en 700.
• Le fichier authorized_keys n’est pas en 600.
• Le propriétaire du dossier home ou .ssh est incorrect.
• Le client SSH utilise une autre clé que celle attendue.
• IdentitiesOnly yes manque dans ~/.ssh/config.
• PubkeyAuthentication est désactivé côté serveur.
• AllowUsers ou AllowGroups bloque l’utilisateur.
• Vous essayez de vous connecter en root alors que PermitRootLogin l’interdit.
• Votre hébergeur impose une configuration SSH spécifique.

Supprimer ou révoquer une clé SSH

Pour révoquer l’accès, supprimez simplement la ligne correspondante dans ~/.ssh/authorized_keys sur le serveur distant.

nano ~/.ssh/authorized_keysCode language: JavaScript (javascript)

Supprimez la ligne de la clé, enregistrez, puis testez depuis le client concerné.

Pour identifier une clé, utilisez son commentaire à la fin de la ligne. C’est pour cela que le -C de ssh-keygen est utile. Une clé nommée backup@apollo-2026-06-03 se comprend mieux qu’un blob cryptographique anonyme de 90 caractères.

Pour aller plus loin avec SSH et l’administration serveur

Si vous utilisez des clés SSH pour administrer vos serveurs, ces guides complètent bien la mise en place d’un accès propre, automatisable et sécurisé.

• Se connecter depuis un serveur vers un NAS Synology avec des clés SSH, sans mot de passe
• Mettre à jour WordPress en SSH avec WP-CLI
• Sécuriser SSH sur un serveur dédié
• Recevoir un email après le redémarrage d’un serveur Linux
• WordPress : bonnes permissions fichiers avec chown et chmod

FAQ

Une clé SSH sans passphrase est-elle dangereuse ?

Elle peut l’être si elle donne un shell complet. Pour un script automatisé, utilisez une clé dédiée, stockée avec des permissions strictes, puis restreignez-la côté serveur avec from=, restrict et éventuellement command=.

Faut-il encore utiliser RSA pour SSH ?

Pour une nouvelle clé utilisateur, utilisez Ed25519. RSA reste possible, mais Ed25519 est plus simple, rapide et moderne pour la plupart des usages SSH actuels.

Pourquoi SSH me demande encore un mot de passe ?

La clé publique n’est peut-être pas installée sur le bon compte, les permissions sont trop ouvertes, le client utilise une autre clé, ou le serveur n’autorise pas l’authentification par clé. Lancez ssh -vvv pour diagnostiquer.

Puis-je copier ma clé privée sur plusieurs machines ?

Évitez. Générez plutôt une clé par machine ou par usage. C’est plus simple à révoquer et beaucoup plus clair dans les journaux d’accès.

ssh-copy-id est-il obligatoire ?

Non. Il est simplement pratique. Vous pouvez ajouter manuellement la clé publique dans ~/.ssh/authorized_keys, à condition de respecter les bonnes permissions.

Puis-je désactiver complètement les mots de passe SSH ?

Oui, après avoir testé un accès par clé dans une deuxième session. Ensuite, vous pouvez définir PasswordAuthentication no et KbdInteractiveAuthentication no dans la configuration SSH serveur.

Conclusion

Créer une clé SSH permet de se connecter à un serveur sans saisir de mot de passe interactif. Pour un usage quotidien, utilisez une clé Ed25519 protégée par une passphrase et chargée dans ssh-agent. Vous gardez le confort sans sacrifier la sécurité.

Pour une automatisation, créez une clé dédiée sans passphrase, mais limitez-la côté serveur. Une clé qui ne peut lancer qu’une commande depuis une seule IP vaut beaucoup mieux qu’une clé qui ouvre un shell complet à qui la possède.

SSH est un outil robuste. Il devient excellent quand chaque clé a un usage clair, des permissions strictes et une méthode de révocation simple.

À vous les sauvegardes automatisées ou les rsync sauvages la nuit lorsque tout le monde dort !

Sources

• OpenBSD manual : ssh-keygen
• OpenBSD manual : sshd et authorized_keys
• OpenBSD manual : sshd_config
• Oracle Linux documentation : copying SSH public keys

Report a typo