SSH (Secure Shell) est un protocole de réseau cryptographique qui est utilisé pour établir des connexions sécurisées entre un client distant et un serveur, en utilisant le TCP protocole de sécurité et de fiabilité.
Les connexions basées sur SSH prennent en charge diverses méthodes d'authentification, dont certaines sont :
- Authentification basée sur un mot de passe
- Authentification basée sur une clé
Par défaut, la création d'une nouvelle connexion SSH entre deux machines utilisera l'authentification par mot de passe. Mais si vous vous connectez fréquemment à un serveur à partir du même client, il peut être fastidieux et irritant de saisir le mot de passe chaque fois que vous vous connectez au serveur.
Ce tutoriel présente l'autre alternative d'authentification pour se connecter au serveur distant, en utilisant des clés publiques .
Voyons comment nous pouvons configurer cela sur nos machines clientes et serveurs particulières que nous utilisons fréquemment, afin que nous puissions nous connecter automatiquement à partir de cette machine en toute sécurité !
Vérifiez les clés SSH existantes sur la machine cliente
La première partie traite de la génération d'une paire de clés privée-publique dans le client machine. La clé publique est ensuite copiée sur le serveur et est utilisée pour l'authentification.
Avant de définir une clé SSH, assurons-nous qu'aucune clé existante n'est déjà présente pour cette combinaison client-serveur.
Exécutons ce script bash pour vérifier si le fichier existe (vous pouvez également le saisir directement sur le terminal)
if test -f ~/.ssh/id_*.pub; then
echo "Found"
else
echo "Not Found"
fi
Si vous obtenez "Not Found", cela signifie qu'aucun fichier de ce type n'existe et que nous sommes prêts à créer une nouvelle clé pour cette connexion.
Sinon, vous pouvez utiliser directement les clés existantes et ignorer l'étape suivante. Mais si vous ne souhaitez pas utiliser les anciennes clés, vous pouvez supprimer les anciennes clés et en générer de nouvelles en suivant l'étape suivante.
Générer une nouvelle paire de clés SSH pour les machines client-serveur
La commande ci-dessous générera un nouveau 4096 bits Paire de clés SSH avec votre identifiant (peut être n'importe quoi d'identifiable !) en commentaire :
ssh-keygen -t rsa -b 4096 -C "[email protected]"
Après avoir configuré l'emplacement de la clé et les phrases de passe en exécutant cette commande, nous aurons maintenant la nouvelle clé générée pour nous, ainsi que l'empreinte de la clé.
Maintenant, vérifions si la clé privée-publique est bien là, en utilisant ls .
ls ~/.ssh/id_*
Vous devriez obtenir la sortie ci-dessous :
/root/.ssh/id_rsa /root/.ssh/id_rsa.pub
Cela signifie que id_rsa est votre clé privée, et id_rsa.pub est votre clé publique.
REMARQUE :Jamais partagez votre clé privée entre les machines. C'est pourquoi vous avez une clé publique. Nous pouvons donc copier la même clé publique sur plusieurs serveurs vers ssh à, tout en maintenant la sécurité supplémentaire à l'aide de la clé privée sur votre machine locale.
Copiez la clé publique sur le serveur
Puisque nous avons notre paire de clés SSH sur notre client, pour pouvoir nous connecter au serveur distant, nous devons y copier la clé publique.
Nous pouvons utiliser scp pour copier des fichiers sur notre serveur, mais il existe une meilleure alternative pour ssh clés, en utilisant ssh-copy-id .
Vous pouvez installer ssh-copy-id en utilisant votre gestionnaire de paquets s'il n'est pas disponible.
ssh-copy-id server_username@server_ip
Après avoir entré le mot de passe du nom d'utilisateur du serveur, nous serons désormais authentifiés pour nous connecter au serveur à l'aide des clés publiques.
Le résultat ressemblera à ceci :
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/client_user/.ssh/id_rsa.pub" /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys SERVER_USER@SERVER_IP's password: Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'SERVER_USER@SERVER_IP'" and check to make sure that only the key(s) you wanted were added.
Cela signifie que nous pouvons utiliser ssh à cette machine particulière de notre client avec l'authentification supplémentaire basée sur une clé !
Pour le tester, essayez ssh sur le serveur maintenant !
ssh server_user@server_ip
Débogage des problèmes potentiels
Mais certains d'entre vous peuvent toujours recevoir l'invite de mot de passe, ainsi que la phrase secrète basée sur la clé ! Que se passe-t-il ?
Une raison potentielle est détaillée ici. Il semble que nous n'ayons pas les autorisations appropriées sur notre ~/.ssh répertoire sur le serveur distant . Le contenu de la ACCUEIL répertoire ~ , le ~/.ssh répertoire et le ~/.ssh/authorized_keys le fichier doit être accessible en écriture uniquement par nous. Sinon, il détecte que d'autres utilisateurs peuvent y accéder, et c'est pourquoi le mot de passe est également demandé.
Vérifions d'abord les autorisations de notre répertoire personnel.
Comme nous ne pouvons qu'écrire, nous n'avons pas besoin de modifier les autorisations pour ce répertoire. De même, regardez les modes et changez le mode en utilisant chmod .
Modifions les autorisations sur ces fichiers et répertoires à l'aide de chmod -R ~/.ssh 700 récursivement.
Maintenant, testez-le pour voir si cela fonctionne.
Débogage des problèmes potentiels – Partie 2
Si vous ne parvenez toujours pas à le faire fonctionner, ce fil mentionne que certaines des options du fichier de configuration ssh peuvent être désactivées.
Vérifiez /etc/ssh/sshd_config dans le serveur pour s'assurer que RSAAuthentication , PubkeyAuthentication et UsePAM les options ne sont pas désactivées.
Assurez-vous également que vous avez explicitement défini PasswordAuthentication no dans la configuration, pour désactiver l'authentification par mot de passe pour notre utilisateur.
Comme vous pouvez le voir, ce fut effectivement le cas pour moi ! Le PubKeyAuthentication a également été désactivé, et par conséquent, il m'a demandé le mot de passe, car la session ne l'a pas utilisé comme mode d'authentification principal !
J'ai décommenté cette ligne et redémarré ssh pour appliquer les modifications.
sudo systemctl restart ssh
Maintenant, cela a permis à l'authentification sans mot de passe de fonctionner enfin pour moi ! J'espère que vous avez également trouvé une solution à ce moment-là.
Nous avons enfin configuré ssh travailler sans mot de passe !
Conclusion
Dans ce tutoriel, nous vous avons montré comment configurer ssh méthode d'authentification basée sur une clé publique et connectez-vous à un serveur sans mot de passe !