domi a écrit :
Si tu fais sur le Rpi un :
sudo netstat -anp | grep sshd
Peux tu donner le résultat afin de vérifier que le Rpi écoute bien sur l'IP et sur le port 22 en ipv4.
Pour ôter toute doute, il n'y a pas de Firewall installé sur le Rpi ?
Le résultat :La connexion s’établit bien mais, malgré mes difficultés avec l’anglais je crois comprendre que la difficulté vient des clefs et que la procédure demande la suppression des 4 clefs existant chez le clientCode : Tout sélectionner
pi@raspberrypi:~$ sudo netstat anp | grep sshd tcp 0 0 0.0.0.0:28841 0.0.0.0:* LISTEN 437/sshd tcp6 0 : : :28841 : : :* LISTEN 437/sshd Unix 3 [ ] STREAM CONNECTE 11896 437/sshd [/quote] A noter qu’à un 2eme essai 1186 est devenu 11645 et 437 est devenu 403?? Contrairement à ce dont j'étais persuadé c’est le port 28841 qui est cité dans le netstat ci dessus Je pense que l’anomalie vient du fait que le port d’appel n’est pas le même les sur fichiers de config respectifs du client et du serveur. Je corrige donc celui du serveur en 22 et je relance : [code]gerard@gerard-L50:~$ ssh -v pi@192.168.1.87 OpenSSH_7.4p1 Debian-10+deb9u6, OpenSSL 1.0.2r 26 Feb 2019 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to 192.168.1.87 [192.168.1.87] port 22. debug1: Connection established. debug1: identity file /home/gerard/.ssh/id_rsa type 1 debug1: key_load_public: No such file or directory debug1: identity file /home/gerard/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/gerard/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/gerard/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/gerard/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/gerard/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/gerard/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/gerard/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u6 debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1 Raspbian-10+deb9u6 debug1: match: OpenSSH_7.4p1 Raspbian-10+deb9u6 pat OpenSSH* compat 0x04000000 debug1: Authenticating to 192.168.1.87:22 as 'pi' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: curve25519-sha256 debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ecdsa-sha2-nistp256 SHA256:XeiaygTtIdpimaTRV0JWpAt39aKI6azXaqtjTnlaL+A @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is SHA256:XeiaygTtIdpimaTRV0JWpAt39aKI6azXaqtjTnlaL+A. Please contact your system administrator. Add correct host key in /home/gerard/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /home/gerard/.ssh/known_hosts:4 remove with: ssh-keygen -f "/home/gerard/.ssh/known_hosts" -R 192.168.1.87 ECDSA host key for 192.168.1.87 has changed and you have requested strict checking. Host key verification failed. gerard@gerard-L50:~$
Dans cette hypothèse le fichier du client sera vide, ce qui suppose que je vais devoir reprendre la création des clefs depuis le début Exact ???
Dois-je aussi vider le fichier known_hosts du serveur au préalable ??? ou le fichier authorized_keys
Enfin, dernière question :
Pour répondre à ta demande j’ai travaillé à l’écran de ma TV , directement sur le rasp,
Malgré l’utilisation de sudo aucun mot de passe n’a été sollicité : pourtant j’ai bien créé un mot de passe utilisateur qui aurait du être demandé pour sudo ??
Aurais tu une idée à suggérer pour comprendre ce qu'il se passe ??
Pour info suite aux propositions d’artemus24 j’ai modifié les permissions sur le serveur
sudo chmod 700 ~/.ssh
sudo chmod 400 ~/.ssh/authorized_keys
Nouvelle occasion de constater que j’accède sans mot de passe ???
Merci & à+
