J’ai une rapsberrypi 3 j’ai installé l’image de raspbian en passant par WINDOWS.
Le port console fonctionne bien. Avec la version Jessie Lite le ssh est bloqué. Donc je me connecte en faisant un bon petit sudo apt-get install je trouve le menu car sur Jessie Lite il est caché…et finalement je me dis, ca roule et donc je branche ma Pi via le port ethernet à ma BoxInternet …
…et je lance un XTERM sous iMAC !
Depuis mon iMAC (Sierra) je fais ssh pi@adresseIPdelaPI et là bing je suis bloqué.
Chose faite je retape la même commande sauf que l’on me demande le mot de passe directement sans me demander le login. (qui est censé être PI par défaut)
Et je tape le mot de passe exact mais ca passe toujours pas.
Alors je me lance dans le mode debug que voici :
ssh pi@adresse IP de la PI -l pi -v
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /var/root/.ssh/id_rsa
debug1: Trying private key: /var/root/.ssh/id_dsa
debug1: Trying private key: /var/root/.ssh/id_ecdsa
debug1: Trying private key: /var/root/.ssh/id_ed25519
debug1: Next authentication method: password pi@192.168.1.40’s password:
Authentication failed.
→ est ce que j’ai bien compris ? l’iMAC envoie une clef d’authent en guise de login au lieu de « pi » ? C’est pour ca que j’ai l’invite demandant le mot de passe directement ?
—> comment faire pour désactiver ce comportement de l’iMAC pour que je puisse mettre le login moi-même
Merci beaucoup …j’ai vu et lu les autres topic lié aux questions ssh mais comme j’ai la version 3 de RaspberryPi je préfère poser la question. S’il y la réponse dans un topic qui m’aurait échappé, n’hésitez pas à me le dire
Je suis sur Mac et linux.
J’utilise tjrs la commande ssh admin@192.168.0.xx
ou ssh pi@192.168.0.xx
'selon l’OS qui tourne sur le Rpi) et cela sans aucun pb.
Aussi bien depuis mon Mac que dps un des Linux.
Aussi bien sur Rpi que Rpi2 ou Rpi3
Encore faut-il que le SSH soit activé sur ton Raspbian
Si tu tapes user@adresseIP = il ne te demande pas ton user mais ton mot de passe directement ; logique.
D’ailleurs, parfois l’erreur est de taper ‹ pi@adresseIP › alors que ça tourne avec ‹ admin › ou un autre nom
Je viens d’allumer le Rpi3 avec Raspbian pour tester ta commande ‹ bavarde ›
Mac-mini-de-Nabla:~ nabla$ ssh pi@192.168.0.xx -l pi -v
OpenSSH_7.4p1, LibreSSL 2.5.0
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 192.168.0.xx [192.168.0.xx] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /Users/nabla/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/nabla/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/nabla/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/nabla/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/nabla/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/nabla/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/nabla/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/nabla/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Raspbian-5+deb8u3
debug1: match: OpenSSH_6.7p1 Raspbian-5+deb8u3 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.0.xx:22 as ‹ pi ›
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:supprimé par nabla
debug1: Host ‹ 192.168.0.xx › is known and matches the ECDSA host key.
debug1: Found key in /Users/nabla/.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/nabla/.ssh/id_rsa
debug1: Trying private key: /Users/nabla/.ssh/id_dsa
debug1: Trying private key: /Users/nabla/.ssh/id_ecdsa
debug1: Trying private key: /Users/nabla/.ssh/id_ed25519
debug1: Next authentication method: password
pi@192.168.0.xx’s password:
Donc, il tente bien les différents modes de connexion et choisi la méthode ‹ password ›.
Je n’ai pas souvenir d’avoir fait un truc spécifique … mais ça fait des années que j’utilise le ssh depuis mon mac vers mes Linux …
Hum humm…
J’ai modifié le mot de passe initial (raspberry par mySecretMDP)
est ce que lorsque l’on rentre le nouveau mdp, on est en mode querty ? (j’ai même fait la convertion AZERTY (mon clavier) vers QUERTY et en plus sous MAC on peut switcher facilement d’un mode en l’autre.
C’est clair non ce que je viens de mettre ? AHAH !
Je viens de ta^per « ca y est j’ai trouvé » mais en mode QUERTY !!
et donc mon mot de passe a été tapé en mode QUERTY et pas AZERTY…donc en me mettant en mode QUERTY ca fonctionne !!!
et voici le petit bébé pi qui répond
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Jul 19 15:28:22 2017
pi@raspberrypi:~ $
pi@raspberrypi:~ $
Elle est pas belle la vie ?
Hop résolu (au moins pour ce topic…hein Nabla …tu sais qu’il m’en reste encore un, LOL)
Nabla a le don d’ubiquité !
A tout hasad, maintenant que je suis plus chaud ==> as-tu testé à tout hasard l’augmentation de la longueur de la clef publique comme indiqué ci-dessous.
Si je comprends bien mon super debug c’est la pi qui envoie la clef publique, donc je me connecte en ssh (avec le bon mode de Clavier…) et je tape les commandes ci-dessous
Alors, il est vrai que j’avais lu cette page il y a qq temps et m’étais dit « oh, faudrait que je teste ».
Mais comme tout ce qui comporte le conditionnel et non le présent/futur … Ben … Ce n’est pas encore fait …
Conclusion : il faudra voire il faut que je teste !
En fait, j’ai un Rpi3 qui tourne avec 3 clef USB différentes (il boote sur USB) et 3 cartes SD différentes alors peut-être que ça simplifierait les connexions.
En effet, si le Rpi démarre sur Raspiban et que je veux m’y connecter en ssh depuis le mac, ça fonctionne.
Mais si j’éteins et rallume avec RetroPie, je dois aller modifier le fichier « known_hosts » dans /Users/nabla/.ssh/ sinon erreur de sécurité.
Peut-être que la mise en place de la clef serait une solution.
C’est fait !
Merci de m’y avoir poussé.
J’ai réalisé la procédure sur 2 clefs USB différentes de Raspbian.
1 - ça fonctionne ; je me connecte en ssh par ‹ passphrase › et non par ‹ password › avec une clef en option 4096
2 - Mauvaise nouvelle pour moi, j’ai tjrs le même souci.
Comme j’ai fait coller une IP fixe au Rpi3 via sons adresse mac, j’ai une erreur en changeant d’OS car IP identique mais système différent.
Donc, j’ai le droit à un joli :
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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:supprimé par Nabla.
Please contact your system administrator.
Add correct host key in /Users/nabla/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /Users/nabla/.ssh/known_hosts:1
ECDSA host key for 192.168.0.xx has changed and you have requested strict checking.
Host key verification failed.
Je dois donc supprimer mon known_hosts.
Il faudrait donc que je change mon système pour que l’IP soit lié à l’OS et non à l’adresse Mac du matériel …
A creuser dans un autre sujet.
Merci Nabla d’avoir fait bêta-testeur …mais pourquoi avoir changé d’OS (pour faire une extension de longueur de clef ?)
Par contre j’espère que l’iMAC saura (bien) gérer une clefs plus longue que la longueur classique, initialement paramétrée par l’iMAC…
J’attends de voir la réponse pour voir si je tente ou pas.
Ce soir opération CAM IP !! (si tu vois de quoi je parle LOL)
J’ai réalisé la procédure depuis mon Mac mini qui tourne sous Sierra.
AUCUN souci avec le Mac qui génère et gère la clef (tu ouvres un Terminal sous Mac et tu gère comme sous Linux That’s all)
Après, j’ai testé pour le fun + pour toi + pour tester un truc pour moi.
Pour toi = aucun pb, tu peux te lancer ; le mac sait faire et le Raspberry sera plus sécurisé.
Pour moi, c’est différent.
Le but était de voir si ça me supprimait mon bug d’autorisation lié à mon utilisation multi-os de mon Rpi3.
Depuis un poste (Mac ou Linux), qd tu te connectes à un autre poste (Linux ou Raspberry Pi) = tu vas créer une « reconnaissance » entre les 2 postes.
Mon souci est que mon Raspberry Pi3 me sert sous Raspbian à jour (une Clef USB) mais aussi sous un autre Raspbian pour du timeLaps (Clef USB) + sous RetroPie (carte SD) + …
Mon souci est que si je me connecte en SSH au Rpi3 sous Raspbian, ça créé une trace dans mon fichier « known_hosts ».
Du coup, je serais éjecté si je reboote le Rpi3 sous RetroPie et tente d’y accéder en ssh.
Pour passer, il faudra que je fasse une remise à zéro du « known_hosts »
Je le fais en 12 secondes … mais si je n’avais pas à le faire, ça serait mieux.
Je vais donc voir si je peux assigner une IP liée à l’OS et non lié au Raspberry.
Mais tu peux fermer ton sujet et le passer en [Résolu] ; je me ferais un sujet si besoin.
