Ssh login si blocca alla password solo su specifico router e in wifi

Assistenza Linux
1

Ciao a tutti da un neo iscritto.
Vi sottopongo un problema che non mi è mai capitato.

Devo controllare da remoto un linux server connesso in wifi ad un router Zyxel (quello di wind di alcuni anni fa, detto anche Home&Life-hub).

Al ssh login da terminale del client, dopo aver dato enter alla password, si blocca tutto, ma proprio tutto… .ne’ controlD ne’ controlC mi fanno riprendere il controllo della finestra.

Ciò accade sia il server abbia installato ubuntu jelly che debian 11.

Nessun problema invece via ethernet stesso router oppure in wifi su hotospot di un android.

Presumo la causa siano le impostazioni del wifi del router, al quale ci sono connessi in wifi altri linux più datati che sono perfettamente raggiungibili in ssh.

Che diavolo può essere? Delle nuove funzionalità linux che il router non comprende?

2

Hai provato a collegarti via wifi con android o un altro computer?
La cosa mi fa pensare che tu ci abbia installato qualcosa come fail2ban, e quindi dopo alcuni tentativi ha bloccato il tuo indirizzo ip.

Sono molto scettico.

Giusto per chiedere, hai verificato che il server linux si collega effettivamente al router via wiifi?

3

Il dispositivo non ha nessun problema ad essere raggiunto via ssh se connesso all’hotspot android del mio smartphone. Su fail2ban, non so cosa sia.

Certo: il server non è connesso in altro modi se non alla WLAN del router, il quale gli ha assegnato un IP; qualsiasi client ssh si connetta a questo IP riceve il prompt di richiesta credenziali; come scrivevo si blocca all’enter a fine password.
Nel frattempo ho provato a connettermi con ssh -T user@IP ricevendo pure il banner, ma non è possibile nessuna interazione se non CTRL-C oppure CNTR-D per terminare la sessione. Senza l’opzione “-T” non è possibile riprendere il controllo del terminale in alcun modo.

4

Prova a vedere i log di SSHD sul server (e condividerli qui)…

5

Domanda: il programma di login è quello di default? Per programma di login intendo quello specificato all’ultima colonna della riga dell’utente nel file /etc/passwd sul server

6

Purtroppo non posso ancora risponderti: /var/log è desolatamente vuota e forse è in relazione ad alcuni errori della schedina SD del sistema operativo. Ho corretto con fsck, ma credo farò meglio a sostituirla, in quanto l’ho oramai riscritta una decina di volte, provando più versioni di linux.
Appena trovo una SD fresca riprovo e faccio un reply qui.

7

Allora,
il programma di login è il solito /bin/bash. L’unica differenza provando ssh user@ip “/bin/sh” è che con questa shell almeno riesco a riprendere il controllo del terminale locale con un control-C, altrimenti la finestra locale non risponde nemmeno ai control.

Questa la tail di auth.log

2024-03-15T21:52:06.719485+01:00 opiz3 sshd[1638]: Accepted password for pi from 192.168.1.7 port 60710 ssh2
2024-03-15T21:52:06.724579+01:00 opiz3 sshd[1638]: pam_unix(sshd:session): session opened for user pi(uid=1000) by (uid=0)
2024-03-15T21:52:06.746091+01:00 opiz3 systemd-logind[530]: New session 10 of user pi.
2024-03-15T21:52:06.816300+01:00 opiz3 (systemd): pam_unix(systemd-user:session): session opened for user pi(uid=1000) by (uid=0)
2024-03-15T21:52:07.441956+01:00 opiz3 sshd[1638]: pam_env(sshd:session): deprecated reading of user environment enabled

La cosa singolare è che, una volta connesso un cavo ethernet, l’accesso via ssh funziona, sempre sull’IP dell’interfaccia wifi.

end0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::9753:fb3a:a326:d678  prefixlen 64  scopeid 0x20<link>
        ether 02:00:fe:a3:d1:7e  txqueuelen 1000  (Ethernet)
        RX packets 93  bytes 9583 (9.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 57  bytes 7952 (7.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 51  

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.179  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::2af7:120e:68c9:307  prefixlen 64  scopeid 0x20<link>
        ether dc:80:e5:fb:d5:30  txqueuelen 1000  (Ethernet)
        RX packets 40  bytes 4240 (4.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 89  bytes 12990 (12.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Se scollego a caldo il cavo ethernet, ho ancora il prompt e posso riloggarmi senza problemi. Se riavvio il server, il problema del blocco dopo l’enter a fine password si ripresenta.

8

Mhm se cambi access point, hai lo stesso problema?

9

Come scrivevo nel primo messaggio, nessun problema via ethernet oppure in wifi su altro hotspot, per esempio quello del mio smartphone android.

Quindi probabilmente il problema è sul zyxel home&Life, ma solo con questo server Linux Debian bullseye, ubuntu jelly e in ultimo pure con bookworm.

10

Alla fine, per disperazione, ho risolto tirando fuori da un armadio un vecchio router Linksys, collegato in LAN e configurato come access point: il server linux ora risponde ai login ssh sulla nuova WLAN. Quindi il problema, tuttora ignoto, è sul router Wind (Home&Life Hub) che blocca le richieste ssh (sftp funziona!) e solo per quel particolare dispositivo della dozzina di collegati.

Spero la soluzione non sarà definitiva, visto che il costo dell’energia che, anche per un dispositivo da pochi watt ma 24/7, comincia ad influire sulla tasca.