A voir également:
- Petit problème ssh
- Ssh download - Télécharger - Divers Web & Internet
- Trier du plus petit au plus grand excel - Guide
- Petit 3 ✓ - Forum Word
- Petit 2 ✓ - Forum Windows
- Petit 9 - Forum Mail
2 réponses
Bonjour
Oulala attention. Ce message d'erreur n'est pas innocent avant d'aller trop vite.
Signification du message d'erreur
L'une des sécurité de ssh est de s'assurer que quand tu te connectes à un serveur, tu t'adresses bien au serveur auquel tu penses. C'est le rôle des fingerprints (empreintes en français).
La première fois que tu te connectes en ssh à un serveur, celui-ci te donne son empreinte. Tu es supposée la contrôler (pour plus de détails, voir ici). L'association entre le nom du serveur et l'empreinte est alors sauvegardée dans
Sauf que l'empreinte annoncée par le serveur n'est pas celle qu'il connaît. Cela signifie que pour lui, tu ne t'adresses pas au serveur auquel tu crois.
Causes possibles du message d'erreur
Voici les trois principales causes :
1) soit ton trafic est dérouté vers un autre serveur et quelqu'un cherche à y recueillir des informations sensibles (d'où l'alerte).
2) soit le paquet
3) parfois tu as plusieurs serveurs ssh à la maison, mais tes PCs ne reçoivent pas toujours la même IP. Et du coup pour une même IP, le client ssh ne voit pas toujours la même empreinte. C'est peut-être ton cas, mais dans ce cas, il serait pas mal que ces machines reçoivent une IP fixe (voir paramètres DHCP de ta box).
Tu es probablement dans ce troisième cas vue l'IP.
Résolution du message d'erreur
Dans les cas 2 et 3, il est légitime de supprimer la clé de
Remarques additionnelles
1) Connexion root via ssh
C'est une TRÈS MAUVAISE idée d'autoriser les connexions en root sur un linux. Ce login est systématiquement attaqué, d'une part car il offre des droits maximaux, et d'autre part car il existe toujours.
Un serveur ssh bien configuré devrait TOUJOURS rejeter les connexion en tant que root. Charge au client de se connecter avec son login utilisateur puis de passer en root avec
Je te recommande vivement de corriger le fichier
... et dans ce fichier, d'ajouter ou de décommenter (en supprimant le # en début de ligne) la ligne (~l33)
(ctrl x pour sauver et quitter). Enfin redémarre le serveur sshd :
2) Connexion par mot de passe
Pour un maximum de sécurité et pour avoir quelque chose de plus pratique à utiliser, je te recommande de faire une authentification par clé ssh plutôt que par mot de passe. Créer une clé ssh se fait facilement, et par la suite l'authentification se fait automatiquement (il faut juste déverrouiller la clé au préalable).
a) Pour créer ta clé, côté client :
Ceci crée le fichier
b) Pour installer ta clé ssh publique (tant que l'authentification par mot de passe est autorisée) sur le serveur
Méthode 1: par
Méthode 2 : à la main.
c) Côté serveur, le fichier
Une fois la clé installée, vérifie qu'elle marche. Côté client :
d) Si tout est ok, on peut alors désactiver, sur le serveur, l'authentification par mot de passe.
... à l'aide des instructions (~l57) :
Puis sauve et quitte (ctrl x).
e) Enfin redémarre le serveur sshd :
Bonne chance
Oulala attention. Ce message d'erreur n'est pas innocent avant d'aller trop vite.
Signification du message d'erreur
L'une des sécurité de ssh est de s'assurer que quand tu te connectes à un serveur, tu t'adresses bien au serveur auquel tu penses. C'est le rôle des fingerprints (empreintes en français).
La première fois que tu te connectes en ssh à un serveur, celui-ci te donne son empreinte. Tu es supposée la contrôler (pour plus de détails, voir ici). L'association entre le nom du serveur et l'empreinte est alors sauvegardée dans
~/.ssh/known_hosts. Ainsi, par la suite, ton client
sshne te redemande pas de faire cette vérification, il la fait pour toi.
Sauf que l'empreinte annoncée par le serveur n'est pas celle qu'il connaît. Cela signifie que pour lui, tu ne t'adresses pas au serveur auquel tu crois.
Causes possibles du message d'erreur
Voici les trois principales causes :
1) soit ton trafic est dérouté vers un autre serveur et quelqu'un cherche à y recueillir des informations sensibles (d'où l'alerte).
2) soit le paquet
ssh-servera été réinstallé et l'empreinte a été régénérée.
3) parfois tu as plusieurs serveurs ssh à la maison, mais tes PCs ne reçoivent pas toujours la même IP. Et du coup pour une même IP, le client ssh ne voit pas toujours la même empreinte. C'est peut-être ton cas, mais dans ce cas, il serait pas mal que ces machines reçoivent une IP fixe (voir paramètres DHCP de ta box).
Tu es probablement dans ce troisième cas vue l'IP.
Résolution du message d'erreur
Dans les cas 2 et 3, il est légitime de supprimer la clé de
~/.ssh/known_hosts, soit en supprimant la ligne appropriée de ce fichier, soit à l'aide de la commande suggérée.
Remarques additionnelles
1) Connexion root via ssh
C'est une TRÈS MAUVAISE idée d'autoriser les connexions en root sur un linux. Ce login est systématiquement attaqué, d'une part car il offre des droits maximaux, et d'autre part car il existe toujours.
Un serveur ssh bien configuré devrait TOUJOURS rejeter les connexion en tant que root. Charge au client de se connecter avec son login utilisateur puis de passer en root avec
su -ou
sudo -sune fois connecté.
Je te recommande vivement de corriger le fichier
/etc/ssh/sshd_config:
sudo nano /etc/ssh/sshd_config
... et dans ce fichier, d'ajouter ou de décommenter (en supprimant le # en début de ligne) la ligne (~l33)
PermitRootLogin no
(ctrl x pour sauver et quitter). Enfin redémarre le serveur sshd :
sudo service ssh restart
2) Connexion par mot de passe
Pour un maximum de sécurité et pour avoir quelque chose de plus pratique à utiliser, je te recommande de faire une authentification par clé ssh plutôt que par mot de passe. Créer une clé ssh se fait facilement, et par la suite l'authentification se fait automatiquement (il faut juste déverrouiller la clé au préalable).
a) Pour créer ta clé, côté client :
ssh-keygen -t rsa -b 2048
Ceci crée le fichier
~/.ssh/id_rsa(ta clé privée, à garder précieusement et uniquement sur des machines de confiance) et
~/.ssh/id_rsa.pub(ta clé publique, que tu peux disséminer sans risque). Vois un peu ça comme une clé et un cadenas : pas de problème pour redistribuer des cadenas, par contre la clé qui les ouvre doit être gardée précieusement dans un endroit sûr.
b) Pour installer ta clé ssh publique (tant que l'authentification par mot de passe est autorisée) sur le serveur
MY_MACHINEavec le login
MY_LOGIN, deux méthodes sont possibles.
Méthode 1: par
ssh-copy-id
ssh-copy-id -i ~/.ssh/id_rsa.pub MY_LOGIN@MY_MACHINE:
Méthode 2 : à la main.
c) Côté serveur, le fichier
~/.ssh/authorized_keysliste les clés publiques (une par ligne) qui permettre de s'authentifier par clé. Il suffit donc de le créer (s'il n'existe pas déjà) et d'y copier coller le contenu de ta clé publique.
Une fois la clé installée, vérifie qu'elle marche. Côté client :
ssh-add ssh MY_LOGIN@MY_MACHINE
d) Si tout est ok, on peut alors désactiver, sur le serveur, l'authentification par mot de passe.
sudo nano /etc/ssh/sshd_config
... à l'aide des instructions (~l57) :
PasswordAuthentication no
PermitEmptyPasswords no
Puis sauve et quitte (ctrl x).
e) Enfin redémarre le serveur sshd :
sudo service ssh restart
Bonne chance
mais je me doutais que t'aller me répondre zip comme d'hab ^^ fait attention avec toute l'aide que tu me porte je risque de tomber amoureux .