Problème de connexion SSH après changement d'interface

[arofarn]

Mon serveur YunoHost

Matériel: PC neuf à base de Ryzen 3, carte Wifi Intel et carte ethernet intégrées à la carte mère.
Version de YunoHost: 3.5.2.2 installé sur une Debian Stretch toute fraîche (à cause d’un bug graphique de l’installeur de l’ISO de Yunohost, mais c’est un autre sujet je pense)
J’ai accès à mon serveur : En SSH seulement en wifi | Par la webadmin wifi et ethernet

Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : oui
Si oui, expliquer:
Installation sur une Debian 9 fraîche (rien d’autre dessus). Disque système : SSD NVME, stockage sur RAID1 de disques SATA. Le tout chiffré (LUKS).
Ce nouveau serveur vient en remplacement de mon ancien portable que faisait office de serveur, mais pas trop adapté à l’utilisation 24/24h

Description du problème

Pour faciliter l’installation initiale, j’ai monté le serveur dans mon bureau. La seule connexion disponible lors de l’installation était le Wifi via la carte Intel intégrée à la carte mère.
Tout c’est bien passé : serveur disponible en SSH et web admin (en plus de clavier/écran).

Le problème est apparu au moment de quitter le wifi pour la connexion filaire (machine déplacée à côté de ma box):
Côté routeur, j’ai réaffecté l’IP utilisée en wifi sur vers la carte ethernet et fournit une nouvelle IP fixe à la carte Wifi (IP fixée par le DHCP)
Côté yunohost, j’ai juste configuré la carte ethernet pour se connecter automatiquement en DHCP.
Les bonnes IP sont affectées.

Yunohost (interface web) est accessible depuis le LAN et depuis l’extérieur, via la carte ethernet.
SSH inaccessible via la carte ethernet (time out), mais accessible depuis le wifi seulement. La désactivation du wifi n’y change rien (j’ai utilisé Shell in A box).

Le client SSH n’indique aucune erreur d’authentification : si je tente de me connecter sur l’IP de la carte ethernet, le client SSH abandonne au bout de 2min sans nouvelle du serveur. En wifi, ça fonctionne sans soucis.

Sur l’IP de la carte ethernet :

$ ssh -v admin@192.168.1.4
OpenSSH_7.9p1 Ubuntu-10, OpenSSL 1.1.1b  26 Feb 2019
debug1: Reading configuration data /home/arofarn/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.1.4 [192.168.1.4] port 22.
debug1: connect to address 192.168.1.4 port 22: Connection timed out
ssh: connect to host 192.168.1.4 port 22: Connection timed out

Aucune trace de la tentative de connexion dans le journal de SSH. (seulement des connexion par la carte wifi.

$ cat /etc/ssh/sshd_config
# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
#ListenAddress 192.168.1.4
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile     %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# 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

PasswordAuthentication no

J’ai tenté de modifier “ListenAddress” sans succés. Du coup, j’ai commenté la ligne. De toute façon, ça fonctionnait en wifi sur cette même IP.

[anonyme18]

Bonjour,

routeur, j’ai réaffecté l’IP utilisée en wifi sur vers la carte ethernet et fournit une nouvelle IP fixe à la carte Wifi (IP fixée par le DHCP)
Côté yunohost, j’ai juste configuré la carte ethernet pour se connecter automatiquement en DHCP.
Les bonnes IP sont affectées.

il y a un truc que je ne comprends pas :
pourquoi affecter IP wifi à carte ethernet et laisser dhcp ?

[arofarn]

Je gère les IP globalement depuis le routeur via la table de correspondance MAC / IP plutôt que d’affecter des IP fixes terminal par terminal.

En réaffectant l’IP à une autre carte réseau, je n’ai pas à toucher aux redirection du NAT.

D’ailleurs, en passant de l’ancien serveur (vieux portable) au nouveau, j’ai aussi garder la même adresse IP sans que ça pose de soucis.
A ce propos, la vieille machine était connecté en ethernet et j’y accèdait en SSH sans soucis (jamais utilisé le wifi sur celle-là).

[anonyme18]

Je pensais justement à cette option !
As-tu essayé le temps de tes essais à désactiver ta carte wifi ?

[arofarn]

Oui, j’avais désactivé la carte wifi, sans succès. Et j’ai du passé par Shell in the box pour la remettre en place.

Après un bon repas, j’ai une illumination et j’ai éteins mon répéteur Wifi…

Bingo! ça fonctionne de mon portable en wifi vers mon serveur Yunohost en ethernet.

C’est donc ce répéteur qui bloque la connexion SSH. Finalement, mon serveur SSH est bien configuré. Rien d’exotique à bricoler
Pendant l’installation du serveur, les deux machines étaient du même côté du répéteur. Et ça n’a pas changé depuis pour le wifi (malgré que le serveur soit juste à côté du routeur, il se connecte quand même en wifi au répéteur).
Pour l’ethernet c’est censé faire :
PC --wifi_etendu–> répéteur --wifi–> routeur --ethernet–> serveur_yunohost

Je vais regarder du côté du répéteur (dont j’ai besoin pour le Wifi en 5GHz). Pour info, c’est un TP-Link RE450 (prêté “gracieusement” sur demande par Bouygue Telecom aux clients BBox).
Je n’en avais pas parlé parce que jusque là, il ne m’avais jamais posé de problème au point de l’oublier un peu dans son coin…