ssh connect to host 192.168.1.250 port 22: Connection timed

Question

Bonsoir à tous,

J'ai passé des heures à consulter les questions sur CCM ainsi que sur les sites  sans trouver de réponse.

J'avais déjà posté sur cette question mais entre-temps, j’ai changé de distribution et tout remis à zéro.

J'ai un Raspberry 3 comme serveur avec une adresse fixe, 192.168.1.250. Lorsque je vais sur le net avec http://192.168.1.250/wordpress/, j'ai accès au site. Ping fonctionne. Par contre, ssh bernard@192.168.1.250 ou ***@*** revoie ceci :

bernard@debian:~$ ssh -vvv bernard@192.168.1.250
debug1: OpenSSH_10.0p2 Debian-7, OpenSSL 3.5.1 1 Jul 2025
debug3: Running on Linux 6.12.48+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.48-1 (2025-09-20) x86_64
debug3: Started with: ssh -vvv bernard@192.168.1.250
debug1: Reading configuration data /home/bernard/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug3: /etc/ssh/ssh_config line 19: Including file /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf depth 0
debug1: Reading configuration data /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf
debug2: resolve_canonicalize: hostname 192.168.1.250 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/bernard/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/bernard/.ssh/known_hosts2'
debug3: channel_clear_timeouts: clearing
debug3: ssh_connect_direct: entering
debug1: Connecting to 192.168.1.250 [192.168.1.250] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x10
debug1: connect to address 192.168.1.250 port 22: Connection timed out
ssh: connect to host 192.168.1.250 port 22: Connection timed out

J'ai paramétré le fichier ssh.conf dans /etc/ssh.conf sur le poste client ainsi que sshd.conf sur le serveur (j'ai installé Debian sur une clé usb, ce qui est très pratique pour les modifications).

Pour faire simple et éviter les difficultés avec la vérification par clé, j'ai simplement autorisé la connexion par

Un extrait de ssh.conf

Host localhost
HostName 192.168.1.27
#   ForwardAgent no
#   ForwardX11 no
#   ForwardX11Trusted yes
    PasswordAuthentication yes
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   GSSAPIKeyExchange no
#   GSSAPITrustDNS no
#   BatchMode no
#   CheckHostIP no
#   AddressFamily any
   ConnectTimeout 20
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   IdentityFile ~/.ssh/id_ecdsa
#   IdentityFile ~/.ssh/id_ed25519
    Port 22
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
#   MACs hmac-md5,hmac-sha1,***@***
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
#   VisualHostKey no
#   ProxyCommand ssh -q -W %h:%p gateway.example.com
#   RekeyLimit 1G 1h
#   UserKnownHostsFile ~/.ssh/known_hosts.d/%k
    SendEnv LANG LC_* COLORTERM NO_COLOR
    HashKnownHosts yes
    GSSAPIAuthentication yes

Je suis sûrement passé à côté de quelque chose !

Merci à tous.

Linux / Firefox 140.0

brupala · Answer

Salut,

HostName 192.168.1.27

alors que tu accèdes à 192.168.1.250, ça ne te gratouille pas quelque part ?

Lume51 · Answer

Et ça devrait me gratouiller où ? Désolé, si tu pouvais expliquer !

Lume51 · Answer

J'ai commenté la ligne

# HostName 192.168.1.27

sans changement

...........
debug3: channel_clear_timeouts: clearing
debug3: ssh_connect_direct: entering
debug1: Connecting to 192.168.1.250 [192.168.1.250] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x10
debug1: connect to address 192.168.1.250 port 22: Connection timed out
ssh: connect to host 192.168.1.250 port 22: Connection timed out

Par contre, le site s'affiche avec Firefox.

mamiemando · Answer

Bonjour,

Je pense que c'est une fonction entre client et serveur car il est question de ssh.conf et non de sshd.conf. Ici si tu veux que 192.168.1.250 soit accessible par SSH, tu dois installer sur cette machine un serveur SSH ; et sur la machine avec laquelle tu te connectes en SSH (disons 192.168.1.10), il faut installer un client ssh.

Sur le serveur : (192.168.1.250)

sudo apt update
sudo apt install ssh
sudo sudo systemctl start ssh.service
sudo sudo systemctl status ssh.service

Sur le client : (192.168.1.10) Si tu veux te connecter en vers le compte toto configuré sur 192.168.1.250 :

sudo apt update
sudo apt install openssh-client
ssh toto@192.168.1.250

Précisions importantes :

Par défaut, on ne peut pas se connecter en tant que root vers ssh. Et il ne faut pas changer ce comportement, car c'est le compte le plus sensible (et qui se fait le plus attaquer) ! En contrepartie, Il faut donc t'assurer que ta machine 192.168.1.250 dispose d'un compte utilisateur (toto dans mon exemple précédent) vers lequel se connecter.
	Le pare-feu du client et du doit laisser passer le trafic SSH. Le serveur écoutant par défaut sur le port 22. Il faut donc que le port 22 soit ouvert (trafic entrant pour le serveur, trafic sortant pour le client). Plus généralement, si plusieurs machines séparent le client et le serveur, il faut qu'elles fasse suivre le trafic correspondant (entrant et sortant).
	Lorsque tu installes un serveur SSH, je t'invite très fortement à le sécuriser, typiquement en obligeant les connexion par clé SSH. Voir ce tutoriel.
	
		Sur le serveur : Une fois la clé SSH mise en place (typiquement dans /home/toto/.ssh/authorized_keys sur 192.168.1.250), veille à désactiver les authentifications par mot de passe dans /etc/ssh/sshd_config :
		
sudo gedit /etc/sshd/sshd_config &
		Dans ce fichier, décommente / corrige la ligne PasswordAuthentication de sorte à ce qu'elle devienne :

PasswordAuthentication no

... sauve et quitte, puis redémarre le service SSH :

sudo systemctl restart ssh.service

Sur le client : vérifie que tu parviens toujours à te connecter au serveur SSH :

ssh-add
ssh toto@192.168.1.250

Bonne chance

Lume51 · Answer

Bonjour et merci pour tes explications toujours limpides,

Sur le serveur

J'ai suivi tes conseils. La clé id_ed25519.pub   a été générée et copiée sur le serveur. Elle apparaît bien dans

/home/bernard/.ssh/authorized_keys

J'ai désactivé les authentifications par mot de passe dans /etc/ssh/sshd_config : (serveur)

PasswordAuthentication no

Voici un extrait du fichier, il se peut qu'il y ait des erreurs :

Include /etc/ssh/sshd_config.d/*.conf

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
PermitRootLogin no
#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 no
#PermitEmptyPasswords no

# Change to "yes" to enable keyboard-interactive authentication.  Depending on
# the system's configuration, this may involve passwords, challenge-response,
# one-time passwords or some combination of these and other methods.
# Beware issues with some PAM modules and threads.
KbdInteractiveAuthentication 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 KbdInteractiveAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via KbdInteractiveAuthentication may bypass
# the setting of "PermitRootLogin prohibit-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and KbdInteractiveAuthentication to 'no'.
UsePAM yes
.........

Sur le poste client

Extrait du fichier  /etc/ssh/ssh.config

Include /etc/ssh/ssh_config.d/*.conf

Host *
#   ForwardAgent no
#   ForwardX11 no
#   ForwardX11Trusted yes
    PasswordAuthentication no
#   HostbasedAuthentication no

#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   GSSAPIKeyExchange no
#   GSSAPITrustDNS no
#   BatchMode no
#   CheckHostIP no
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   IdentityFile ~/.ssh/id_ecdsa
   IdentityFile ~/.ssh/id_ed25519
    Port 22
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
#   MACs hmac-md5,hmac-sha1,***@***
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
#   VisualHostKey no
#   ProxyCommand ssh -q -W %h:%p gateway.example.com
#   RekeyLimit 1G 1h
#   UserKnownHostsFile ~/.ssh/known_hosts.d/%k
    SendEnv LANG LC_* COLORTERM NO_COLOR
    HashKnownHosts yes
    GSSAPIAuthentication yes

J'ai relancé ssh et reconnecté la clé usb au raspberry.  Voici les logs de la connexion :

bernard@debian:~$ ssh -vvv  bernard@192.168.1.250
debug1: OpenSSH_10.0p2 Debian-7, OpenSSL 3.5.4 30 Sep 2025
debug3: Running on Linux 6.12.57+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.57-1 (2025-11-05) x86_64
debug3: Started with: ssh -vvv bernard@192.168.1.250
debug1: Reading configuration data /home/bernard/.ssh/config
debug1: /home/bernard/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug3: /etc/ssh/ssh_config line 19: Including file /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf depth 0
debug1: Reading configuration data /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolve_canonicalize: hostname 192.168.1.250 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/bernard/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/bernard/.ssh/known_hosts2'
debug3: channel_clear_timeouts: clearing
debug3: ssh_connect_direct: entering
debug1: Connecting to 192.168.1.250 [192.168.1.250] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x10
debug1: connect to address 192.168.1.250 port 22: Connection refused
ssh: connect to host 192.168.1.250 port 22: Connection refused

Par contre, le serveur est reconnu puisque le site s'affiche (avec lenteur, pb de connexion !!).

Le ping

bernard@debian:~$ ping 192.168.1.250 -v
ping: sock4.fd: 3 (socktype: SOCK_DGRAM), sock6.fd: 4 (socktype: SOCK_DGRAM), hints.ai_family: AF_UNSPEC

ai->ai_family: AF_INET, ai->ai_canonname: '192.168.1.250'
PING 192.168.1.250 (192.168.1.250) 56(84) bytes of data.
64 bytes from 192.168.1.250: icmp_seq=1 ttl=64 time=2758 ms
64 bytes from 192.168.1.250: icmp_seq=2 ttl=64 time=1740 ms
64 bytes from 192.168.1.250: icmp_seq=3 ttl=64 time=712 ms
64 bytes from 192.168.1.250: icmp_seq=4 ttl=64 time=6.89 ms
64 bytes from 192.168.1.250: icmp_seq=5 ttl=64 time=7.57 ms
64 bytes from 192.168.1.250: icmp_seq=6 ttl=64 time=7.41 ms
64 bytes from 192.168.1.250: icmp_seq=7 ttl=64 time=7.19 ms
^C
--- 192.168.1.250 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6052ms
rtt min/avg/max/mdev = 6.892/748.313/2757.924/1015.531 ms, pipe 3

Je ne sais pas interprété la variable time mais il me semble que cela n'est pas signe de rapidité. (je n'ai pas cherché car je sature !!!)

J'espère que tu as assez d'infos pour trouver la solution.

Merci

Lume · Answer

Bonjour,

J'ai modifié le port sur le serveur

/etc/ssh/sshd_config

en choisissant 2222 et en supprimant le #. Idem sur le poste client. J'ignore si c'est utile.

/etc/ssh/ssh_config

Rien n'y fait. Le ping fonctionne et la connexion avec Firefox réussit très lentement.

Une dernière info. Les logs de connexion.

bernard@debian:~$ ssh -vvv  bernard@raspberypi@local -p 2222
debug1: OpenSSH_10.0p2 Debian-7, OpenSSL 3.5.4 30 Sep 2025
debug3: Running on Linux 6.12.57+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.57-1 (2025-11-05) x86_64
debug3: Started with: ssh -vvv bernard@raspberypi@local -p 2222
debug1: Reading configuration data /home/bernard/.ssh/config
debug1: /home/bernard/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug3: /etc/ssh/ssh_config line 19: Including file /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf depth 0
debug1: Reading configuration data /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/bernard/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/bernard/.ssh/known_hosts2'
debug2: resolving "local" port 2222
debug3: resolve_host: lookup local:2222
ssh: Could not resolve hostname local: Name or service not known

Hier, avec le Port 22, le message d'erreur était

ssh: connect to host 192.168.1.250 port 22: Connection refused

Avec Port 2222, on obtient

ssh: Could not resolve hostname local: Name or service not known

Le fichier /etc/hosts

127.0.0.1	 localhost
127.0.1.1	 debian
127.0.1.1    www.toto.fr
192.168.1.250 raspberrypi.local

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Une dernière info obtenue avec Angry IP Scanner

IP:	192.168.1.250
Ping:	41 ms
Nom d'hôte:	raspberrypi.local
Ports:	80

On remarque le port 80 et non 2222. Peut-être parce que c'est en local ?? Je m'y perds.

Je patauge toujours malgré tous les posts sur ce sujet...

mamiemando · Answer

Bonjour,

Version courte

1) Est-ce que le client et le serveur sont deux machines distinctes ?

2) Peux-tu reporter sur le serveur (en admettant que tu veuilles te logguer sur le serveur en tant que toto) le résultat de

ls -l ~toto | grep .ssh
ls -l ~toto/.ssh | grep .ssh
netstat -ntlp

3) Toujours sur le serveur lance :

tail -f /var/log/auth.log

Cette commande surveille l'évolution de ce fichier. Appuie sur entrée pour passer quelques lignes.

Puis tente de te connecter vers le serveur ssh lance une connexion vers le serveur et reporte-nous les lignes apparues entretemps côté serveur. Ceci fait, interrompt la commande tail (ctrl+c).

Reporte aussi alors 
	
sudo journalctl -t sshd-session --since "10min ago"

Version longue

Désolé mon message est un peu long, mais tes messages soulèvent plusieurs points qu'il me paraît important d'expliquer et clarifient les commandes ci-dessus :D

Concernant #6

Concernant le client et /etc/ssh/ssh_config : je garderais la configuration par défaut, car selon le serveur ssh que tu cibles, tu peux vouloir potentiellement te connecter par mot de passe. Ainsi, le client ssh tentera par défaut une authentification par clé, et si elle échoue, te proposera de t'authentifier par mot de passe (si le serveur l'autorise).
	Si tu ne sais plus comment était la configuration sur le client par défaut, tu peux purger et réinstaller le paquet concerné. 
	
sudo apt purge openssh-client
sudo apt install openssh-client
	
	Concernant les logs coté client. On ne voit pas passer les clés. Voici à quoi ça devrait ressembler : 
	
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: get_agent_identities: bound agent to hostkey
debug1: get_agent_identities: agent returned 1 keys
debug1: Will attempt key: /home/mando/.ssh/id_rsa RSA SHA256:... explicit agent
debug1: Offering public key: /home/mando/.ssh/id_rsa RSA SHA256:... explicit agent
debug1: Server accepts key: /home/mando/.ssh/id_rsa RSA SHA256:... explicit agent
Authenticated to ... ([...]:22) using "publickey".
	
	Il se peut que ce soit lié au nom ou à la manière dont tu as créé ta clé. Il faut surtout que la clé ait été préalablement chargée, donc tu devrais à tout hasard lancer : 
	
ssh-add
ssh login@server

... en remplaçant login par un login existant sur le serveur (et différent de root) aevc lequel tu souhaites te connecter et pour lequel tu as installé la clé ssh, et en remplaçant server par l'IP (par exemple 11.22.33.44) ou le FQDN (par exemple toto.domain.fr) qui l'identifie.
	
	La commande ssh-add sert à charger tes clés ssh. Il n'est utile de le faire que quand tu lances ta session graphique (donc une fois à chaque redémarrage), pas besoin de le refaire à chaque fois que tu as besoin de lancer une commande ssh ou scp. Tu peux vérifier quelles clés sont chargées avec :

ssh-add -L

Il faut bien entendu que le serveur ssh du serveur soit lancé (sudo systemctl status ssh.service)

Si le serveur ssh n'écoute pas sur le port par défaut (donc 22), il faut préciser le port au moment de te connecter avec le client. Si le port sur lequel le serveur ssh écoute est 2222, la commande ssh à lancer côté client devient :

ssh -p 22 login@server
	
	Concernant les lenteurs : tant que ça marche, les lenteurs ne devraient pas gêner. Tu dis "le site s'affiche", je ne sais pas si ça signifie que ce serveur expose en plus du serveur ssh un serveur web (genre apache ou nginx). Si c'est de ça qu'il est question, le serveur web et le serveur ssh sont indépendant. Ils peuvent souffrir tout d'eux d'une lenteur de connexion, mais une autre explication peut simplement être que le serveur web est lent (problème de configuration, requêtes lourdes, etc), ou parce que ton navigateur web est lent (résolutions DNS lente, volume de données à télécharger important, etc.). Bref on ne peut pas trop dire à ce stade (et surtout je pense que ça n'impacte pas ta connexion ssh).
	Dans /etc/hosts : Je vois que tu as associé www.toto.fr à 127.0.1.1 ce qui me laisse penser que le client et le serveur SSH correspondent à une seule même machine machine physique.
	
		Est-ce le cas ? Si oui la connexion ssh doit être initiée avec : 
		
ssh -p 2222 toto@localhost
		
		C'est d'ailleurs un test que tu pourrais faire sur le serveur pour écarter les aspects réseaux.
		Remarque : si l'authentification se fait par clé SSH, cela présuppose que :
		
			soit la clé ssh privée est stockée dans le compte qui lance la commande ssh ci-dessus (donc par exemple, si tu es loggué en tata, ta clé privée est stockée ~tata/.ssh/id_rsa)
			soit la clé ssh privée est transportée de manière transparente grâce à ssh-add. Note que si tu fais plusieurs "rebonds" en ssh, cela marche parfaitement : par exemple tu peux te initier ta connexion ssh en tant que lume@client (avec ssh-add + ssh) puis vers tata@server1 (uniquement besoin de ssh) vers toto@server2 (uniquement besoin de ssh). Ainsi la clé privée peut être uniquement stockée dans ~lume/.ssh/id_rsa et est uniquement stockée sur client.
			
				Important: Il est important de ne PAS disséminer ta clé ssh privée (~/.ssh/id_rsa). Elle ne devrait résider que sur tes machines personnelles (client dans mon exemple) et dans lesquelles tu as confiance. On doit éviter autant que possible de la recopier sur d'autres machines (serveurs ...) en particulier s'ils sont accessibles depuis Internet et/ou par d'autres utilisateur.
				Remarque : il n'y a pas de "gros" problème a disséminer sa clé ssh publique (~/.ssh.id_rsa.pub). C'est ce que fait ssh-copy-id (ou, de manière équivalente, ce que tu fais quand tu complète ~toto/.ssh/authorized_keys sur ton serveur).

Concernant #8

Il faut bien comprendre ce qu'est un port.

Côté serveur : Quand une machine server lance un serveur (ssh, web, etc.), le serveur en question se "bind" à un port sur lequelle la machine écoute. Les ports sont normalisés, mais pas imposés. Par exemple un serveur SSH écoute par défaut sur le port 22, un serveur HTTP sur le port 80, un serveur HTTPS sur le port 443, etc. On voit donc que :

Un port est associé à un service : le serveur sait à quel service s'adresse un paquet, car :

le paquet contient le port de destination (22 dans notre cas).

Plus précisément, le port destination stockée dans le header du protocole de transport utilisé par le paquet (TCP ou UDP).

le système d'exploitation a préalablement associé chaque port à son serveur au moment du bind (SSH, HTTP, HTTPS).

La notion de client et serveur est relative : Cette terminologie est propre à une communication établie d'une machine vers un autre. Par exemple si A se connecte vers B, A est client et B est serveur. Si maintenant B se connecte vers C, alors B est client et C est serveur. On voit donc que B est tantôt client (1ère communication) ou serveur (2e communication).
	Port par défaut : Comme le port sur lequel est vital pour que le serveur sache à quel service un paquet est adressé, le client qui a émis ce paquet doit y indiquer le port destination adéquat (disons 22 si le serveur ssh cible écoute sur le port 22), car bien évidemment, un serveur autre (disons web) ne saura pas traiter pas du trafic SSH ;
	
		Côté client : si le port n'est pas précisé par l'utilisateur, alors l'application cliente (par exemple la commande ssh) rempli le port destination avec la valeur du port défaut associé à ce service (donc, 22 pour ssh).
		Côté serveur : on peut vérifier sur quel ports une machine écoute (i.e. sur quelles ports des applications serveur type sshd, nginx, ou apache se sont bindées) avec la commande : 
		
sudo netstat -ntlp

Bind-address : je n'en ai pas parlé jusque là, et je ne pense pas que tu sois concerné dans le cas de ssh sauf si tu l'as reconfigurée, mais dans l'absolu, il faut savoir que quand une application serveur se "bind", elle le fait avec une adresse appelée bind-address. Cette bind-address conditionne depuis quel interface le serveur accepte d'écouter du trafic. La commande netstat -ntlp que j'évoquais permet de voir la bind-address utilisée.
	
		Pour sshd (donc le service SSH) ou un serveur web (nginx, apache), c'est généralement 0.0.0.0, donc le trafic peut arriver depuis n'importe quelle interface réseau.
		Pour des services qui n'ont généralement pas besoin d'être accédé depuis une autre machine que le serveur lui-même, on se restreint au trafic local en indiquant la bind-address 127.0.0.1.
		Plus généralement, on peut se binder soit à 0.0.0.0, soit à une IP associée à l'une interface réseau du serveur (voir ip addr).

Port "pas par défaut" : la plupart des clients permettent de spécifier le port (typiquement l'option -p pour ssh et scp). mais cela sous-entend que le service de le service ciblé écoute bien sur le port par défaut (22 pour ssh et ainsi de suite).
	
		Si le service ciblé n'écoute pas sur le port par défaut, le client ne peut pas le deviner, et il faut donc lui indiquer (voir option -p pour ssh). C'est ce qui mène à une commande type : 
		
ssh -p 2222 toto@server

On pourrait se demander "mais le serveur doit lui même renvoyer des données au client, alors comment ça se passe ?" Eh bien c'est géré de manière transparente au moment d'établir la connexion par le protocole de transport IP sous jacent (donc typiquement TCP ou UDP). Quand le client se présente au serveur, le client a préalablement ouvert un port en local vers lequel le serveur pourra renvoyer les données. Donc côté client, le port pour recevoir les données est choisi dynamiquement et arbitrairement sans que tu aies à t'en préoccuper.

Cependant, même si le port côté client est géré implicitement, il doit être accessible depuis le serveur. Si des machines sont localisées entre le client et le serveur, le même principe que celui que je viens de détailler se produit récursivement. On est ainsi capable d'établir un chemin du serveur vers le client et chaque machine intermédiaire fait sa popote. Tout se fait donc "automatiquement".

Quel que soit le sens de la communication (soit du client interroge le serveur, soit le serveur qui répond au client), toutes les machines impliquées sur le chemin aller et retour doivent laisser passer le trafic sur les ports en question, et donc un pare feu peut limiter la communication.

Si on parlait de trafic HTTP/HTTPS/FTP, il faudrait également ajouter la notion de proxy à cet argument, ici on parle de SSH donc je passe.

J'espère que mes explications sont claires (et pas trop détaillées !).

Bonne chance

Lume51 · Answer

Bonjour,

Merci pour tes explications qui m'ont permis de tester. Ne pouvant me connecter en ssh, je suis passé directement à la version longue

Fichier Host

127.0.0.1    localhost
127.0.1.1    debian
192.168.1.250 www.toto.fr
192.168.1.250 raspberrypi.local

La clé est reconnue et ajoutée

bernard@debian:~$ ssh-add
Enter passphrase for /home/bernard/.ssh/id_ed25519:
Identity added: /home/bernard/.ssh/id_ed25519 (bernard@debian)

bernard@debian:~$ ssh-add -L
ssh-ed25519 XXXXXXXXXXXXXXXXXXXXX bernard@debian

Poste client

Apres avoir relancé le service ssh

bernard@debian:~$ sudo systemctl status ssh.service
● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/usr/lib/systemd/system/ssh.service; enabled; preset: enabled)
     Active: active (running) since Fri 2025-11-21 11:15:11 CET; 31s ago
 Invocation: 3a4640160ad74ca8b7a0c196e3bdea3f
       Docs: man:sshd(8)
             man:sshd_config(5)
    Process: 11499 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
   Main PID: 11503 (sshd)
      Tasks: 1 (limit: 6878)
     Memory: 1.3M (peak: 2M)
        CPU: 74ms
     CGroup: /system.slice/ssh.service
             └─11503 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"

nov. 21 11:15:11 debian systemd[1]: Starting ssh.service - OpenBSD Secure Shell server...
nov. 21 11:15:11 debian sshd[11503]: Server listening on 0.0.0.0 port 22.
nov. 21 11:15:11 debian sshd[11503]: Server listening on :: port 22.
nov. 21 11:15:11 debian systemd[1]: Started ssh.service - OpenBSD Secure Shell server.

Après avoir autorisé la connexion par mot de passe sur les postes client et serveur et désactivé la connexion par clé

/etc/ssh/ssh_config

Host *
#   ForwardAgent no
#   ForwardX11 no
#   ForwardX11Trusted yes
   PasswordAuthentication yes
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   GSSAPIKeyExchange no
#   GSSAPITrustDNS no
#   BatchMode no
#   CheckHostIP no
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   IdentityFile ~/.ssh/id_ecdsa
#   IdentityFile ~/.ssh/id_ed25519
#   Port 22
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
#   MACs hmac-md5,hmac-sha1,***@***
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any

Connection refused

bernard@debian:~$ ssh -p 22 -vvv bernard@192.168.1.250
debug1: OpenSSH_10.0p2 Debian-7, OpenSSL 3.5.4 30 Sep 2025
debug3: Running on Linux 6.12.57+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.57-1 (2025-11-05) x86_64
debug3: Started with: ssh -p 22 -vvv bernard@192.168.1.250
debug1: Reading configuration data /home/bernard/.ssh/config
debug1: /home/bernard/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug3: /etc/ssh/ssh_config line 19: Including file /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf depth 0
debug1: Reading configuration data /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolve_canonicalize: hostname 192.168.1.250 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/bernard/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/bernard/.ssh/known_hosts2'
debug3: channel_clear_timeouts: clearing
debug3: ssh_connect_direct: entering
debug1: Connecting to 192.168.1.250 [192.168.1.250] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x10
debug1: connect to address 192.168.1.250 port 22: Connection refused
ssh: connect to host 192.168.1.250 port 22: Connection refused

Les derniers logs

bernard@debian:~$ sudo journalctl -u ssh --since -1h
nov. 21 14:07:31 debian systemd[1]: Starting ssh.service - OpenBSD Secure Shell server...
nov. 21 14:07:31 debian sshd[1138]: Server listening on 0.0.0.0 port 22.
nov. 21 14:07:31 debian sshd[1138]: Server listening on :: port 22.
nov. 21 14:07:31 debian systemd[1]: Started ssh.service - OpenBSD Secure Shell server.

J'espère que cela te parlera !

mamiemando · Answer

Bonjour

En réponse à #11

Je vois que ton serveur ssh écoute sur le port 22 (donc le port par défaut) et autorise les authentifications par mot de passe (ce qui est très bien, on pourra toujours voir les clés ssh ultérieurement et ensuite désactiver les authentifications par mot de passe). Ton serveur ssh semble se lancer correctement.

Cependant, je vois que les commandes ssh et ssh-add (à utiliser côté client) et les commandes systemctl et journalctl (à utiliser côté serveur) semble lancer sur la même machine (appelée debian).Si j'ai bien suivi, le serveur est 192.168.1.250 et le client est à ce stade indeterminé.

Si le client et le serveur sont la même machine et que tu veux te connecter en tant que bernard, il faut lancer : 
	
ssh bernard@localhost
	
	Sinon, merci de reprendre #10 en distinguant bien ce qui doit être fait sur le client et sur le serveur (machine 192.168.1.250). Dans l'ordre :
	
		Coté serveur : 
		
sudo systemctl restart ssh.service
sudo systemctl status ssh.service  # Vérifier que c'est vert
sudo netstat -ntlp  # Vérifier la bind-address et le port d'écoute
ip addr  # Confirmer que l'IP est bien 192.168.1.250
tail -f /var/log/auth.log
		
		Côté client (en adaptant dans la commande qui suit le login cible) : 
		
ssh -v toto@192.168.1.250
		
		Côté serveur : voir ce qui est apparu entretemps (cf commande tail -f). Puis ctrl+c. Puis lancer voir les éventuelles erreurs reportées par 
		
sudo journalctl -u ssh --since -1h

Mes questions pour clarifier le problème :

Merci de reporter le résultat des commandes précédentes
	Est-ce que dans cette communication ssh, le client et le serveur sont une seule et même machine ?
	Peux-tu préciser les adresses du client et du serveur et confirmer que les deux peuvent communiquer ? 
	
ip addr
ip route

Enfin, peux-tu reporter le résultat de la commande suivante (sur le client et le forum) : 
	
sudo iptables -L

Bonne chance

Lume51 · Answer

Bonjour, Le client et le serveur sont sur deux machines différentes, un PC et un Raspberry pi 3 ( j'ignorais qu'on pouvait utiliser une seule machine). Je ne peux toujours pas me connecter au serveur. bernard@debian:~$ ssh -p 22 -vvv bernard@192.168.1.250 debug1: OpenSSH_10.0p2 Debian-7, OpenSSL 3.5.4 30 Sep 2025 debug3: Running on Linux 6.12.57+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.57-1 (2025-11-05) x86_64 debug3: Started with: ssh -p 22 -vvv bernard@192.168.1.250 debug1: Reading configuration data /home/bernard/.ssh/config debug1: /home/bernard/.ssh/config line 1: Applying options for * debug1: Reading configuration data /etc/ssh/ssh_config debug3: /etc/ssh/ssh_config line 19: Including file /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf depth 0 debug1: Reading configuration data /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf debug1: /etc/ssh/ssh_config line 21: Applying options for 192.168.1.250 debug1: /etc/ssh/ssh_config line 23: Applying options for * debug2: resolve_canonicalize: hostname 192.168.1.250 is address debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/bernard/.ssh/known_hosts' debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/bernard/.ssh/known_hosts2' debug3: channel_clear_timeouts: clearing debug3: ssh_connect_direct: entering debug1: Connecting to 192.168.1.250 [192.168.1.250] port 22. debug3: set_sock_tos: set socket 3 IP_TOS 0x10 debug1: connect to address 192.168.1.250 port 22: Connection refused ssh: connect to host 192.168.1.250 port 22: Connection refused bernard@debian:~$ Les derniers logs nov. 21 22:18:55 debian sshd[9457]: Received signal 15; terminating. nov. 21 22:18:55 debian systemd[1]: Stopping ssh.service - OpenBSD Secure Shell server... nov. 21 22:18:55 debian systemd[1]: ssh.service: Deactivated successfully. nov. 21 22:18:55 debian systemd[1]: Stopped ssh.service - OpenBSD Secure Shell server. nov. 21 22:18:55 debian systemd[1]: Starting ssh.service - OpenBSD Secure Shell server... nov. 21 22:18:56 debian sshd[9506]: Server listening on 0.0.0.0 port 22. nov. 21 22:18:56 debian sshd[9506]: Server listening on :: port 22. nov. 21 22:18:56 debian systemd[1]: Started ssh.service - OpenBSD Secure Shell server. Sur le client ip addr bernard@debian:~$ ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: wlp1s0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 84:c5:a6:2d:92:4a brd ff:ff:ff:ff:ff:ff altname wlx84c5a62d924a inet 192.168.1.27/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp1s0 valid_lft 39139sec preferred_lft 39139sec inet6 2a01:e0a:a7d:4160:41ef:a3cb:7f0b:8405/64 scope global temporary dynamic valid_lft 86015sec preferred_lft 82276sec inet6 2a01:e0a:a7d:4160:86c5:a6ff:fe2d:924a/64 scope global dynamic mngtmpaddr noprefixroute valid_lft 86015sec preferred_lft 86015sec inet6 fe80::86c5:a6ff:fe2d:924a/64 scope link noprefixroute valid_lft forever preferred_lft forever ip route bernard@debian:~$ ip route default via 192.168.1.254 dev wlp1s0 proto dhcp src 192.168.1.27 metric 600 192.168.1.0/24 dev wlp1s0 proto kernel scope link src 192.168.1.27 metric 600 sudo iptables -L bernard@debian:~$ sudo iptables -L Chain INPUT (policy DROP) target prot opt source destination ufw-before-logging-input all -- anywhere anywhere ufw-before-input all -- anywhere anywhere ufw-after-input all -- anywhere anywhere ufw-after-logging-input all -- anywhere anywhere ufw-reject-input all -- anywhere anywhere ufw-track-input all -- anywhere anywhere Chain FORWARD (policy DROP) target prot opt source destination ufw-before-logging-forward all -- anywhere anywhere ufw-before-forward all -- anywhere anywhere ufw-after-forward all -- anywhere anywhere ufw-after-logging-forward all -- anywhere anywhere ufw-reject-forward all -- anywhere anywhere ufw-track-forward all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination ufw-before-logging-output all -- anywhere anywhere ufw-before-output all -- anywhere anywhere ufw-after-output all -- anywhere anywhere ufw-after-logging-output all -- anywhere anywhere ufw-reject-output all -- anywhere anywhere ufw-track-output all -- anywhere anywhere Chain ufw-after-forward (1 references) target prot opt source destination Chain ufw-after-input (1 references) target prot opt source destination ufw-skip-to-policy-input udp -- anywhere anywhere udp dpt:netbios-ns ufw-skip-to-policy-input udp -- anywhere anywhere udp dpt:netbios-dgm ufw-skip-to-policy-input tcp -- anywhere anywhere tcp dpt:netbios-ssn ufw-skip-to-policy-input tcp -- anywhere anywhere tcp dpt:microsoft-ds ufw-skip-to-policy-input udp -- anywhere anywhere udp dpt:bootps ufw-skip-to-policy-input udp -- anywhere anywhere udp dpt:bootpc ufw-skip-to-policy-input all -- anywhere anywhere ADDRTYPE match dst-type BROADCAST Chain ufw-after-logging-forward (1 references) target prot opt source destination LOG all -- anywhere anywhere limit: avg 3/min burst 10 LOG level warn prefix "[UFW BLOCK] " Chain ufw-after-logging-input (1 references) target prot opt source destination LOG all -- anywhere anywhere limit: avg 3/min burst 10 LOG level warn prefix "[UFW BLOCK] " Chain ufw-after-logging-output (1 references) target prot opt source destination Chain ufw-after-output (1 references) target prot opt source destination Chain ufw-before-forward (1 references) target prot opt source destination ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ACCEPT icmp -- anywhere anywhere icmp destination-unreachable ACCEPT icmp -- anywhere anywhere icmp time-exceeded ACCEPT icmp -- anywhere anywhere icmp parameter-problem ACCEPT icmp -- anywhere anywhere icmp echo-request ufw-user-forward all -- anywhere anywhere Chain ufw-before-input (1 references) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ufw-logging-deny all -- anywhere anywhere ctstate INVALID DROP all -- anywhere anywhere ctstate INVALID ACCEPT icmp -- anywhere anywhere icmp destination-unreachable ACCEPT icmp -- anywhere anywhere icmp time-exceeded ACCEPT icmp -- anywhere anywhere icmp parameter-problem ACCEPT icmp -- anywhere anywhere icmp echo-request ACCEPT udp -- anywhere anywhere udp spt:bootps dpt:bootpc ufw-not-local all -- anywhere anywhere ACCEPT udp -- anywhere mdns.mcast.net udp dpt:mdns ACCEPT udp -- anywhere 239.255.255.250 udp dpt:1900 ufw-user-input all -- anywhere anywhere Chain ufw-before-logging-forward (1 references) target prot opt source destination Chain ufw-before-logging-input (1 references) target prot opt source destination Chain ufw-before-logging-output (1 references) target prot opt source destination Chain ufw-before-output (1 references) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ufw-user-output all -- anywhere anywhere Chain ufw-logging-allow (0 references) target prot opt source destination LOG all -- anywhere anywhere limit: avg 3/min burst 10 LOG level warn prefix "[UFW ALLOW] " Chain ufw-logging-deny (2 references) target prot opt source destination RETURN all -- anywhere anywhere ctstate INVALID limit: avg 3/min burst 10 LOG all -- anywhere anywhere limit: avg 3/min burst 10 LOG level warn prefix "[UFW BLOCK] " Chain ufw-not-local (1 references) target prot opt source destination RETURN all -- anywhere anywhere ADDRTYPE match dst-type LOCAL RETURN all -- anywhere anywhere ADDRTYPE match dst-type MULTICAST RETURN all -- anywhere anywhere ADDRTYPE match dst-type BROADCAST ufw-logging-deny all -- anywhere anywhere limit: avg 3/min burst 10 DROP all -- anywhere anywhere Chain ufw-reject-forward (1 references) target prot opt source destination Chain ufw-reject-input (1 references) target prot opt source destination Chain ufw-reject-output (1 references) target prot opt source destination Chain ufw-skip-to-policy-forward (0 references) target prot opt source destination DROP all -- anywhere anywhere Chain ufw-skip-to-policy-input (7 references) target prot opt source destination DROP all -- anywhere anywhere Chain ufw-skip-to-policy-output (0 references) target prot opt source destination ACCEPT all -- anywhere anywhere Chain ufw-track-forward (1 references) target prot opt source destination Chain ufw-track-input (1 references) target prot opt source destination Chain ufw-track-output (1 references) target prot opt source destination ACCEPT tcp -- anywhere anywhere ctstate NEW ACCEPT udp -- anywhere anywhere ctstate NEW Chain ufw-user-forward (1 references) target prot opt source destination Chain ufw-user-input (1 references) target prot opt source destination ACCEPT tcp -- anywhere anywhere tcp dpt:ssh ACCEPT udp -- anywhere anywhere udp dpt:22 ACCEPT tcp -- anywhere anywhere tcp dpt:ssh ACCEPT tcp -- anywhere anywhere tcp dpt:http ACCEPT tcp -- anywhere anywhere tcp dpt:2222 ACCEPT tcp -- anywhere anywhere tcp dpt:ssh /* 'dapp_OpenSSH' */ Chain ufw-user-limit (0 references) target prot opt source destination LOG all -- anywhere anywhere limit: avg 3/min burst 5 LOG level warn prefix "[UFW LIMIT BLOCK] " REJECT all -- anywhere anywhere reject-with icmp-port-unreachable Chain ufw-user-limit-accept (0 references) target prot opt source destination ACCEPT all -- anywhere anywhere Chain ufw-user-logging-forward (0 references) target prot opt source destination Chain ufw-user-logging-input (0 references) target prot opt source destination Chain ufw-user-logging-output (0 references) target prot opt source destination Chain ufw-user-output (1 references) target prot opt source destination Comment faire pour questionner le serveur quand on n'y a pas accès avec ssh ? Existe-il un autre moyen ? Le raspberry fonctionne avec une clé usb qui accueille Debian. Merci.

Lume51 · Answer

Bonjour,

J'ai oublié de préciser que j'utilise le serveur sans écran ni clavier, ce qui explique les difficultés pour effectuer des modifications.

Lume51 · Answer

Oui, je peux me connecter au site via firefox mais c'est apache qui est accepté, pas ssh. Comment vérifier si le parefeu bloque sur le serveur en connectant la clé qui contient Debian (serveur). Quel est le fichier à modifier ? mc et nano sont très efficaces !

mamiemando · Answer

Bonjour @Lume51,

Je vois dans #13 ceci :

Le client (192.168.1.27) et le serveur (192.168.1.250) sont sur le même réseau.
	Les routes côté client sont OK. Je suppose qu'elles le sont aussi côté serveur vu que le serveur web fonctionne
	
		Ce serait bien de reporter le résultat côté serveur de la commande ip route afin de vérifier ça? Je suppose que tu ne l'as pas fait faute de clavier écran sur le Raspberry (voir #14).

Un pare-feu est déployé sur le client (ce serait bien de vérifier sur le serveur). Les règles : 
	
ACCEPT     udp  --  anywhere             anywhere             udp dpt:22
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:2222
	... semblent à première vue correctes. Cependant, comme le souligne @brupala (voir #15), le pare-feu (côté client, serveur ou entre les deux) reste un suspect crédible. Cela expliquerait pourquoi HTTP/HTTPS passe mais pas SSH.

Peux tu désactiver ufw (côté client et serveur) et reprendre ton test ? Si ça marche, nous avons trouvé la cause.
		
			Dans ce cas, active l'un des deux pare-feu (mais pas l'autre) puis tente de te connecter en ssh. Cela permettra de déterminer si cela vient du pare-feu côté client ou côté serveur.

À partir du moment où le Raspberry parvient à communiquer en HTTPS, je ne pense pas que le problème viennent de la configuration IP (je suppose que @brupala suspectait une machine configurée de manière statique dans un contexte DHCP), mais préciser le contexte ne fera pas de mal.

Je ne pense pas non plus que Wordpress puisse interférer avec SSH et je propose donc de rester centrés sur SSH dans cette discussion, quitte à ouvrir un nouveau fil de discussion concernant les éventuels problèmes liés à Wordpress.

Bonne chance

Lume51 · Answer

Bonsoir,

Merci à vous deux. J'ai récupéré un clavier et un écran, ce qui me permettra d'accéder plus facilement au serveur car je ne vois pas comment faire même en brancher la clé-USB qui contient le programme. Il y a sûrement un moyen de paramétrer le serveur en ligne de commande mai je ne sais pas faire.  Je vous tiens au courant.

Lume51 · Answer

Excusez les coquilles !!

Ssh connect to host 192.168.1.250 port 22: Connection timed

15 réponses

Votre réponse

Discussions similaires

Newsletters