Quick-Tutoriel.com Network & System Admin.
L’utilisation d’un SSH sécurisé sans mot de passe via un système de clés privées/publiques, permet une authentification plus robuste et pratique. Contrairement au mot de passe, la clé privée ne quitte jamais la machine client, ce qui limite considérablement les risques d’attaque. Dans ce tutoriel, nous allons vous montrer comment mettre en place cette méthode d’authentification sur vos serveurs Linux ou Unix, en détaillant chaque étape du processus. Cette méthode est particulièrement utile pour les administrateurs système, les développeurs, ou toute personne ayant besoin d’accéder fréquemment à un serveur distant.
Sommaire de l'article
Pourquoi préférer un SSH sécurisé sans mot de passe ?
L’utilisation de mots de passe pour se connecter à distance via SSH présente plusieurs inconvénients : ils peuvent être faibles, oubliés ou interceptés. Les clés SSH, quant à elles, offrent une alternative plus robuste, difficile à compromettre. Voici quelques raisons pour lesquelles elles sont préférées :
- Sécurité renforcée : les clés sont plus longues et donc plus difficiles à forcer.
- Protection accrue : la clé privée est stockée localement et peut être chiffrée par une passphrase.
- Moins de risques d’erreur humaine : plus besoin de taper le mot de passe à chaque connexion.
- Gestion facilitée : les utilisateurs peuvent être ajoutés ou supprimés facilement via le fichier authorized_keys.
De plus, cette méthode est essentielle dans les scripts automatisés où une interaction manuelle est à éviter.
Voici un schéma simple qui récapitule les différentes étapes pour se connecter en SSH sans mot de passe avec l’utilisation des clés SSH :
- 1. Connexion initiale Le client initie la connexion au serveur SSH (généralement sur le port 22).
- 2. Négociation Le client et le serveur se mettent d’accord sur les algorithmes (ex: chiffrement, hachage, échange de clés).
- 3. Échange de clés Le protocole SSH utilise Diffie-Hellman ou Curve25519 pour établir un secret partagé pour la session.
- 4. Challenge signé Le serveur envoie un défi au client ; le client le signe avec sa clé privée.
- 5. Vérification Le serveur vérifie la signature avec la clé publique (déjà enregistrée dans ~/.ssh/authorized_keys).
- 6. Session chiffrée Une fois l’authentification réussie, la communication est entièrement chiffrée.
Étapes pour générer une clé SSH et configurer l’accès sans mot de passe
Générer une paire de clés
Pour commencer, vous devez générer une paire de clés SSH sur votre machine locale. La commande suivante utilise l’algorithme Ed25519, réputé pour sa rapidité et sa sécurité :
ssh-keygen -t ed25519 -C "votre.email@example.com"
Vous pouvez également utiliser RSA avec une longueur de clé de 4096 bits si vous préférez :
ssh-keygen -t rsa -b 4096 -C "votre.email@example.com"
La clé privée sera stockée dans ~/.ssh/id_ed25519 et la clé publique dans ~/.ssh/id_ed25519.pub.
Sur le client local (MAC), nous allons générer les clés publiques avec l’utilitaire ssh-keygen (cet utilitaire est présent de base dans MAC OS X). Pour cet exemple, je n’ais pas mis de passphrase. Votre clé RSA est maintenant créée.
Copier la clé publique sur le serveur
Utilisez la commande suivante pour copier la clé publique sur le serveur distant :
ssh-copy-id utilisateur@serveur.example.com
Cette commande crée automatiquement le fichier ~/.ssh/authorized_keys sur le serveur s’il n’existe pas déjà, et y ajoute la clé publique.
Tester la connexion
Une fois la clé installée, testez la connexion depuis votre ordinateur local :
ssh utilisateur@serveur.example.com
Si tout est bien configuré, vous ne serez pas invité à entrer un mot de passe. En cas de problème, vérifiez les permissions des fichiers (voir la section FAQ ci-dessous).
Renforcer la sécurité de la connexion SSH
Pour sécuriser davantage votre serveur SSH, suivez ces recommandations :
- Désactiver l’authentification par mot de passe : éditez /etc/ssh/sshd_config et changez PasswordAuthentication à no.
- Changer le port par défaut : évitez le port 22, souvent ciblé par des bots.
- Restreindre l’accès : utilisez des règles de pare-feu ou un service comme fail2ban.
- Utiliser l’agent SSH : cela permet de charger une seule fois la clé avec ssh-add.
Ces pratiques renforcent significativement la sécurité de vos connexions SSH, surtout dans un environnement professionnel ou exposé sur Internet.
Dépannage & FAQ
| ProblèmeS | SolutionS |
|---|---|
| « Permission denied » | Vérifiez les permissions du dossier .ssh (700) et des fichiers (600). |
| Clé non acceptée | Assurez-vous que la clé publique est bien ajoutée au fichier authorized_keys. |
| Mot de passe encore demandé | Vérifiez que PubkeyAuthentication est à yes est activé et redémarrez sshd. |
| Erreur de clé hôte | Utilisez ssh-keygen -R hôte pour supprimer les anciennes empreintes. |
A titre d’information :
- chmod 700 donne un droit de lecture, écriture, exécution juste pour le propriétaire.
- chmod 640 donne un droit de lecture, écriture pour le propriétaire, un droit de lecture pour le groupe et aucun droit pour les autres
- chmod 600 signifie que seul le propriétaire du fichier a le droit de lecture et d’écriture, tandis que les autres (groupe et autres utilisateurs) n’ont aucun droit.
Les bonnes pratiques
Mettre en place une connexion SSH sans mot de passe est une étape importante vers une sécurité renforcée et une meilleure productivité. Elle permet non seulement d’accélérer les connexions, mais également de diminuer les risques de compromission par mot de passe.
Adoptez de bonnes pratiques telles que : le renouvellement périodique des clés, l’utilisation d’un gestionnaire de mots de passe pour stocker les passphrases, et la surveillance des journaux SSH pour détecter les activités suspectes. En combinant ces techniques, vous vous assurez un environnement SSH sécurisé, robuste et adapté à une utilisation moderne.
Enfin, n’oubliez pas de sauvegarder vos clés privées dans un endroit sûr, car leur perte pourrait vous empêcher d’accéder à vos serveurs.
Merci pour cet article. Il es aussi possible de signer les clés serveurs et d’utilisateurs. J’ai fait un simple mémo à ce sujet si ça t’intéresse : https://wiki.halpanet.org/doku.php?id=tuto:ssh-certificat