J’ai une Raspberry 3 model B avec Raspbian 9 Stretch installé et j’essaye de me connecter à SSH avec un windows 10 (Putty) et un Ubuntu 18.04 LTS.
J’ai bien suivi les tutoriels d’installation du client ssh sur la Pi (autoriser la connexion ssh, sudo apt-get install openssh-server/client).
Le processus ssh fonctionne bien car j’ai :
pi@josephh_raspberrypi:~ $ sudo service ssh status
...
Active: active (running)
...
Je peux me connecter à ma Pi depuis la Pi avec :
ssh localhost
Et ça marche !
Puis sur windows, une requette ping à l’adresse IP de la PI arrive bien à destination.
Ensuite, j’ai la même erreur sur Putty et sur Linux lorsque je me connecte avec ssh sur le port 22 : « Network error, connection timed out »
J’ai regardé sur pas mal de forums sur internet et je n’ai pas trouvé ma solution, je ne sais plus quoi essayer.
Merci pour votre réponse, mais j’ai la même chose, le processus fonctionne bien :
● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2018-11-11 00:55:56 CET; 18h ago
Process: 520 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
Main PID: 553 (sshd)
CGroup: /system.slice/ssh.service
└─553 /usr/sbin/sshd -D
nov. 11 00:55:55 josephh_raspberrypi systemd[1]: Starting OpenBSD Secure Shell server...
nov. 11 00:55:56 josephh_raspberrypi sshd[553]: Server listening on 0.0.0.0 port 5555.
nov. 11 00:55:56 josephh_raspberrypi sshd[553]: Server listening on :: port 5555.
nov. 11 00:55:56 josephh_raspberrypi systemd[1]: Started OpenBSD Secure Shell server.
nov. 11 00:55:56 josephh_raspberrypi sshd[553]: Server listening on 0.0.0.0 port 80.
nov. 11 00:55:56 josephh_raspberrypi sshd[553]: Server listening on :: port 80.
nov. 11 00:55:56 josephh_raspberrypi sshd[553]: Server listening on 0.0.0.0 port 22.
nov. 11 00:55:56 josephh_raspberrypi sshd[553]: Server listening on :: port 22.
Avec ifconfig, j’ai bien une adresse ip : 192.168.0.106
Après avoir fait quelques tests, j’ai l’impression qu’il y a un problème avec ma configuration réseau. En effet, j’ai une livebox (192.168.1.1) à qui est connectée un relais wi-fi D-link par Ethernet (192.168.0.1).
Avec ma Rpi, je suis connecté au relais.
Mais maintenant, un ping vers l’ip de ma Rpi ne réponds pas.
Autre détail étonnant, en me connectant à ma livebox et en regardant sur les appareils connectés, je ne vois pas les appareils connectés au relais wi-fi.
Tu pourrais tester de mettre ton Rpi en filaire sur ta livebox, de vérifier son IP et de tenter de t’y connecter en SSH (pour voir si le pb ets lié au basculement de plage de réseau)
Le processus ssh est bien actif sur le port 22.
Voici la sortie de zenmap sur la cible (la Rpi) :
Starting Nmap 7.40 ( https://nmap.org ) at 2018-11-12 21:52 CET
NSE: Loaded 143 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 21:52
Completed NSE at 21:52, 0.00s elapsed
Initiating NSE at 21:52
Completed NSE at 21:52, 0.00s elapsed
Initiating Parallel DNS resolution of 1 host. at 21:52
Completed Parallel DNS resolution of 1 host. at 21:52, 0.01s elapsed
Initiating SYN Stealth Scan at 21:52
Scanning 192.168.0.107 [1000 ports]
Discovered open port 3389/tcp on 192.168.0.107
Discovered open port 22/tcp on 192.168.0.107
Completed SYN Stealth Scan at 21:52, 2.92s elapsed (1000 total ports)
Initiating Service scan at 21:52
Scanning 2 services on 192.168.0.107
Completed Service scan at 21:52, 6.02s elapsed (2 services on 1 host)
Initiating OS detection (try #1) against 192.168.0.107
NSE: Script scanning 192.168.0.107.
Initiating NSE at 21:53
Completed NSE at 21:54, 60.33s elapsed
Initiating NSE at 21:54
Completed NSE at 21:54, 0.01s elapsed
Nmap scan report for 192.168.0.107
Host is up (0.000078s latency).
Not shown: 998 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh (protocol 2.0)
| fingerprint-strings:
| NULL:
|_ SSH-2.0-OpenSSH_7.4p1 Raspbian-10+deb9u4
| ssh-hostkey:
| 2048 de:df:9b:82:02:df:cc:3d:40:94:d0:04:b0:21:1e:3d (RSA)
|_ 256 85:eb:29:3d:d6:4c:fc:24:45:17:ee:3c:e0:a1:87:90 (ECDSA)
3389/tcp open ms-wbt-server Microsoft Terminal Service
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
SF-Port22-TCP:V=7.40%I=7%D=11/12%Time=5BE9E82A%P=arm-unknown-linux-gnueabi
SF:hf%r(NULL,29,"SSH-2\.0-OpenSSH_7\.4p1\x20Raspbian-10\+deb9u4\n");
Device type: general purpose
Running: Linux 3.X
OS CPE: cpe:/o:linux:linux_kernel:3
OS details: Linux 3.7 - 3.10
Uptime guess: 27.259 days (since Tue Oct 16 16:41:42 2018)
Network Distance: 0 hops
TCP Sequence Prediction: Difficulty=263 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows
NSE: Script Post-scanning.
Initiating NSE at 21:54
Completed NSE at 21:54, 0.00s elapsed
Initiating NSE at 21:54
Completed NSE at 21:54, 0.00s elapsed
Read data files from: /usr/bin/../share/nmap
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 76.47 seconds
Raw packets sent: 1164 (53.920KB) | Rcvd: 2336 (102.212KB)
ssh: connect to host 192.168.1.27 port 22: Connection timed out
Edit :
Je viens de me rendre compte qu’avec la Pi branchée en Ethernet, je n’ai pas le ssh activé (je ne peux pas y accéder avec un moniteur), la sortie de Zenmap :
Starting Nmap 7.60 ( https://nmap.org ) at 2018-11-12 23:16 CET
NSE: Loaded 146 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 23:16
Completed NSE at 23:16, 0.00s elapsed
Initiating NSE at 23:16
Completed NSE at 23:16, 0.00s elapsed
Initiating ARP Ping Scan at 23:16
Scanning 192.168.1.27 [1 port]
Completed ARP Ping Scan at 23:16, 0.22s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 23:16
Completed Parallel DNS resolution of 1 host. at 23:16, 0.01s elapsed
Initiating SYN Stealth Scan at 23:16
Scanning josephhraspberrypi.home (192.168.1.27) [1000 ports]
Completed SYN Stealth Scan at 23:16, 21.12s elapsed (1000 total ports)
Initiating Service scan at 23:16
Initiating OS detection (try #1) against josephhraspberrypi.home (192.168.1.27)
Retrying OS detection (try #2) against josephhraspberrypi.home (192.168.1.27)
NSE: Script scanning 192.168.1.27.
Initiating NSE at 23:16
Completed NSE at 23:16, 0.00s elapsed
Initiating NSE at 23:16
Completed NSE at 23:16, 0.00s elapsed
Nmap scan report for josephhraspberrypi.home (192.168.1.27)
Host is up (0.0057s latency).
All 1000 scanned ports on josephhraspberrypi.home (192.168.1.27) are filtered
MAC Address: B8:27:EB:63:4D:65 (Raspberry Pi Foundation)
Too many fingerprints match this host to give specific OS details
Network Distance: 1 hop
TRACEROUTE
HOP RTT ADDRESS
1 5.65 ms josephhraspberrypi.home (192.168.1.27)
NSE: Script Post-scanning.
Initiating NSE at 23:16
Completed NSE at 23:16, 0.00s elapsed
Initiating NSE at 23:16
Completed NSE at 23:16, 0.00s elapsed
Read data files from: /usr/bin/../share/nmap
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 25.80 seconds
Raw packets sent: 2046 (94.166KB) | Rcvd: 14 (2.102KB)
Normalement, il n’y a rien à installer.
Si tu as Raspbian Stretch avec Raspbian, c’est installé et il faut juste autoriser les connexions.
Tu peux essayer sudo apt-get install ssh
Mais avant tout, tu peux vérifier que le SSH est bien activé :
Menu Framboise --> Préférences --> configuration --> Interfaces
Surprenant, sshd en écoute sur 5555, 80 et 22 !
Je suppose que /etc/ssh/sshd_config à été modifié. Il serait bon de repasser à un version non modifiée pour faire des tests. A priori si le service sshd est fonctionnel en local, il devrait fonctionner à distance.
ci-joint une copie d’un ‹ /etc/ssh/sshd_config › d’origine. Redémarrer après avoir modifié le fichier.
# $OpenBSD: sshd_config,v 1.100 2016/08/15 12:32:04 naddy Exp $
# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options override the
# default value.
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key
# Ciphers and keying
#RekeyLimit default none
# Logging
#SyslogFacility AUTH
#LogLevel INFO
# Authentication:
#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
#PubkeyAuthentication yes
# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2
#AuthorizedPrincipalsFile none
#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes
#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation sandbox
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none
# no default banner path
#Banner none
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
# override default of no subsystems
Subsystem sftp /usr/lib/openssh/sftp-server
# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# PermitTTY no
# ForceCommand cvs server
@jelopo Merci pour ta réponse
C’est tout à fait vrai, j’avais changé le fichier /etc/ssh/sshd_config lorsque j’avais cherché une solution sur Internet.
J’ai bien copié le fichier original et je ne peux pas me connecter en ssh depuis un autre ordinateur mais cela fonctionne en local.
Peut être une problème de pare-feu (que je n’ai pas touché par ailleurs…) ?
Je viens de tester de retirer l’autorisation et ssh localhost est impossible donc ton autorisation SSH est bien OK.
Sinon, je persiste. Normalement, il n’y a rien à installer !
Si tu as Raspbian Stretch avec Raspbian, c’est installé et il faut juste autoriser les connexions. Menu Framboise --> Préférences --> configuration --> Interfaces Ou sudo raspi-config si tu es sous la version Lite
J’ai des Rpi depuis qq années et j’ai toujours utilisé SSH (je suis sous Linux et Mac donc le Terminal est ouvert quasi en permanence).
Je n’ai jamais eu à installer quoique ce soit.
Juste à activer/autoriser les connexions SSH (depuis 2-3 ans ; avant c’était activé d’emblée).
Tu pourrais tester un truc :
Coller le Rpi directement sur ta LiveBox en filaire.
Écrire la dernière version de Raspbian Stretch sur une Clef USB si tu n’as pas d’autre carte SD.
Démarrer sur cette clef à la place de ta carte SD (les Rpi3B+ le font nativement ; les Rpi3 le font après une petite manip facile).
Activer le ssh (sans rien faire d’autre) et redémarrer
Puis tenter de te connecter à l’IP donnée par ifconfig
Si ça fonctionne, refaire le test après mise en état réseau habituel.
Oui j’ai bien compris, en fait je n’ai rien installé de plus
Je viens de réinstaller Raspbian stretch 9 et j’ai bien sur activé la connexion SSH depuis raspi-config.
Résultat :
Je peux me connecter en ssh en tapant : ssh pi@localhost
Je peux aussi me connecter en faisant : ssh pi@192.168.0.107
@jelopo
La commande me retourne : #Port 22 #GatewayPorts no
J’ai une autre question :
Lorsque j’essaye de pinger ma Rpi avec son adresse IP (sur la livebox), pourquoi le ping est-il redirigé vers une autre adresse IP?
C:\Users\Joseph Henry>ping 192.168.1.28
Envoi d’une requête 'Ping' 192.168.1.28 avec 32 octets de données :
Réponse de 192.168.1.19 : Impossible de joindre l’hôte de destination.
Réponse de 192.168.1.19 : Impossible de joindre l’hôte de destination.
Réponse de 192.168.1.19 : Impossible de joindre l’hôte de destination.
Réponse de 192.168.1.19 : Impossible de joindre l’hôte de destination.
Statistiques Ping pour 192.168.1.28:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Aussi, je me connecte la Rpi à mon routeur (lui-même connecté à la livebox par ethernet) et j’essaye de me connecter par ssh depuis un windows connecté sur le routeur lui-aussi. Voici le résultat (que je ne comprends pas trop) :
ssh pi@192.168.0.107
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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:lv90e/1AoAwvX3CCCWAu3cMFDIWLHYDp75gWPq4/rrw.
Please contact your system administrator.
Add correct host key in C:\\Users\\Joseph Henry/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in C:\\Users\\Joseph Henry/.ssh/known_hosts:3
ECDSA host key for 192.168.0.107 has changed and you have requested strict checking.
Host key verification failed.
EDIT :
J’ai modifié le fichier …/.ssh/known_hosts et ça marche.
Aaahhh ! Ca marche enfin avec mon ordi linux et sur mon pc windows à condition que la Pi et l’ordinateur soient sur la même wi-fi (et pas sur la livebox et sur le routeur)
Alors que normalement, rien à faire.
D’où ma remarque insistante
Et oui, en cas de "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! ", il suffit d’effacer le fichier « known_hosts » ; je le fais souvent car j’ai plusieurs systèmes pour un même Rpi (sur carte SD et sur clefs USB) alors que tous mes Rpi ont une IP fixe via leur adresse MAC --> erreur SSH au redémarrage sur autre système.
Parfois je mets mon Mac en point d’accès pour des tests (je n’utilise pas le wifi de manière habituelle). Le réseau filaire est 192.168.0.x mais le wifi est en 192.168.2.x et j’ai aussi remarqué des problèmes de connexion entre les certains équipements.
Tu peux passer en Résolu en insérant [Résolu] au début de ton titre (il suffit d’éditer ton message initial) ?
Petite precision, il suffit d’effacer seulement les références adresse IP et nom du hôte en question. Sinon on perd toutes les références aux autres hôtes. Pour cela passer la commande
@josephh je pense que le service sshd était à l’écoute seulement sur le port localhost (127.0.0.1) ce qui provoquait le symptôme. Avec le résultat de la commande, je voulais vérifier le port et l’adresse à l’écoute. Le fait qu’il n’y ait aucune ListenAdress explique sans doute la panne.
