De ce se deconectează SSH cu „ssh_dispatch_run_fatal: Connection to x.x.x.x port 2020: Connection corrupted”?

Încerc să îmi dau seama de ce mă deconectez în continuare de la sesiunea mea SSH. Gazda este un server CentOS, iar clienții sunt MacOS.

Eroarea pare să fie sporadică – uneori este o dată pe oră, alteori este de mai multe ori într-un minut. Dar ceea ce este interesant este că acest lucru nu se întâmplă doar atunci când nu folosesc conexiunea - pot să tast literal și conexiunea va merge. Eroarea este:

ssh_dispatch_run_fatal: Conexiune la portul x.x.x.x 2020: Conexiune coruptă

De asemenea, am încercat să am mai multe file deschise cu o conexiune ssh deschisă în fiecare și par să se deconecteze în același timp.

Pornind nivelul de depanare 3, am /var/log/secure ieșire aici în jurul timpului unei deconectări:

16 februarie 08:06:08 46 sshd[2864]: debug2: canal 0: cerere [email protected] confirmare 1
16 februarie 08:06:08 46 sshd[2864]: debug3: trimite pachet: tip 98
16 februarie 08:06:08 46 sshd[2864]: debug3: primire pachet: tip 100
16 februarie 08:06:08 46 sshd[2864]: debug1: Am primit 100/121 pentru keepalive
16 februarie 08:06:38 46 sshd[2864]: debug2: canal 0: cerere [email protected] confirmare 1
16 februarie 08:06:38 46 sshd[2864]: debug3: trimite pachet: tip 98
16 februarie 08:06:38 46 sshd[2864]: debug3: primire pachet: tip 100
16 februarie 08:06:38 46 sshd[2864]: debug1: Am primit 100/122 pentru keepalive
16 februarie 08:06:51 46 sshd[4517]: Conexiune închisă de portul x.x.x.x 62073
16 februarie 08:06:51 46 sshd[4517]: debug1: canal 0: gratuit: server-session, nchannels 1
Feb 16 08:06:51 46 sshd[4517]: debug3: canal 0: stare: Următoarele conexiuni sunt deschise:\r\n #0 server-session (t4 r0 i0/0 o0/0 fd 12/8 cc - 1)\r\n
16 februarie 08:06:51 46 sshd[4517]: Închideți sesiunea: utilizator my_username din portul x.x.x.x 62073 id 0
16 februarie 08:06:51 46 sshd[4517]: debug3: mm_request_send introducând: tip 30
16 februarie 08:06:51 46 sshd[4517]: debug3: session_unused: ID sesiune 0 neutilizat
16 februarie 08:06:51 46 sshd[4517]: debug1: do_cleanup
16 februarie 08:06:51 46 sshd[4517]: debug3: PAM: sshpam_thread_cleanup se introduce
16 februarie 08:06:51 46 sshd[4517]: debug3: mm_request_send introducând: tip 122
16 februarie 08:06:51 46 sshd[4517]: debug3: mm_request_receive_expect introducerea: tip 123
16 februarie 08:06:51 46 sshd[4517]: debug3: intrarea mm_request_receive
16 februarie 08:06:51 46 sshd[4514]: debug3: intrarea mm_request_receive
16 februarie 08:06:51 46 sshd[4514]: debug3: monitor_read: verificarea cererii 30
16 februarie 08:06:51 46 sshd[4514]: debug3: intrarea mm_answer_pty_cleanup
16 februarie 08:06:51 46 sshd[4514]: debug1: session_by_tty: sesiune 0 tty /dev/pts/1
16 februarie 08:06:51 46 sshd[4514]: debug3: mm_session_close: sesiune 0 pid 4517
16 februarie 08:06:51 46 sshd[4514]: debug3: mm_session_close: tty /dev/pts/1 ptyfd 4
16 februarie 08:06:51 46 sshd[4514]: debug1: session_pty_cleanup: sesiunea 0 ediție /dev/pts/1
16 februarie 08:06:51 46 sshd[4514]: debug3: session_unused: ID sesiune 0 neutilizat
16 februarie 08:06:51 46 sshd[4514]: debug3: intrarea mm_request_receive
16 februarie 08:06:51 46 sshd[4514]: debug3: monitor_read: verificarea cererii 122
16 februarie 08:06:51 46 sshd[4514]: debug3: mm_request_send introducând: tip 123
16 februarie 08:06:51 46 sshd[4517]: debug3: mm_request_send introducând: tip 124
16 februarie 08:06:51 46 sshd[4517]: Transferat: trimis 1503792, primit 18928 octeți
16 februarie 08:06:51 46 sshd[4517]: se închide conexiunea la portul x.x.x.x 62073
16 februarie 08:06:51 46 sshd[4517]: debug3: se introduce mm_audit_event
16 februarie 08:06:51 46 sshd[4517]: debug3: mm_request_send introducând: tip 112
16 februarie 08:06:51 46 sshd[4517]: debug3: mm_request_send introducând: tip 50
16 februarie 08:06:51 46 sshd[4514]: debug3: intrarea mm_request_receive
16 februarie 08:06:51 46 sshd[4514]: debug3: monitor_read: verificarea cererii 124
16 februarie 08:06:51 46 sshd[4514]: debug3: intrarea mm_request_receive
16 februarie 08:06:51 46 sshd[4514]: debug3: monitor_read: verificarea cererii 112
16 februarie 08:06:51 46 sshd[4514]: debug3: intrarea mm_answer_audit_event
16 februarie 08:06:51 46 sshd[4514]: debug3: intrarea mm_request_receive
16 februarie 08:06:51 46 sshd[4514]: debug3: monitor_read: verificarea cererii 50
16 februarie 08:06:51 46 sshd[4514]: debug3: mm_answer_term: demolarea sesiunilor
16 februarie 08:06:51 46 sshd[4514]: debug1: PAM: curățare
16 februarie 08:06:51 46 sshd[4514]: debug1: PAM: sesiune de închidere
16 februarie 08:06:51 46 sshd[4514]: pam_unix(sshd:session): sesiune închisă pentru utilizator my_username
16 februarie 08:06:51 46 sshd[4514]: debug1: PAM: ștergerea acreditărilor

Părțile sunt ascunse cu X sau numele_de_utilizator

Actualizați

Am adăugat un nou set de jurnale mai sus - mai puțin decât inițial, dar sper că cele aplicabile. Noua linie:

16 februarie 08:06:51 46 sshd[4517]: Conexiune închisă de portul x.x.x.x 62073

ma intereseaza.Ar sugera acest lucru că dispozitivul meu face deconectarea și nu are legătură cu SSH? Văd (cred) că sunt trimise pachete de succes de menținere în viață chiar înainte de deconectare.

Am încercat să repornesc demonul și să folosesc versiunea SSH OpenSSH (prin brew) pe Mac și asta nu a făcut nicio diferență.

Informații server:

â sshd.service - demonul serverului OpenSSH
   Încărcat: încărcat (/usr/lib/systemd/system/sshd.service; activat; prestabilit furnizor: activat)
   Activ: activ (în rulare) din vineri 2022-02-11 10:21:40 GMT; acum 1h 52min
     Documente: man:sshd(8)
           man:sshd_config(5)
 PID principal: 6271 (sshd)
   CGroup: /system.slice/sshd.service
           ââ6271 /usr/sbin/sshd -D

Singurele diferențe ale noastre sshd_config la standardul CentOS unul este portul, nivelul de jurnal și:

ClientAliveInterval 30
ClientAliveCountMax 5

De ce mă deconectez? Ce ar putea cauza coruptia conexiunii?

Aceasta este cel mai probabil o problemă de deconectare, nu sunt sigur ce versiune utilizați dacă verificați baza de cod ssh, spune:

ssh va returna SSH_ERR_CONN_CORRUPT în principal din cauza sshpkt_disconnect.

Acum întrebarea este cum vă puteți menține conexiunea vie, avem mai multe moduri într-un singur mod deja „milenao” partajate, dar înainte de a schimba setarea, vă rugăm să citiți mai întâi efectul. O altă modalitate este să rulați un fel de tunel pentru a trimite orice fel de trafic, astfel încât serviciul să creadă că conexiunea este activă, cum ar fi puteți trimite ping, data, viziona, dormi după o anumită frecvență în funcție de nevoile dvs.

Actualizați:

Cu jurnalele de mai sus, ceea ce pot spune că conexiunea dvs. nu este activă și a fost inițiată închiderea conexiunii, acesta este același lucru pe care îl prezicem.

   /* Conexiunea a fost întreruptă. */
   ssh_packet_get_bytes(ssh, &ibytes, &obytes);
   verbose("Transferat: trimis %llu, primit %llu octeți",
   (unsigned long long)obytes, (unsigned long long)ibytes);

   verbose("Închiderea conexiunii la portul %.500s %d", remote_ip, remote_port);

De aici: https://linux-tips.com/t/how-to-solve-ssh-disconnect-packet-corrupt-problems/258

Încercați să rulați această comandă pentru a dezactiva suma de verificare hardware:

sudo ethtool -K eth0 tx off rx off

Se pare că ar putea fi o problemă hardware. De asemenea, am citit în altă parte că pornirea/oprirea întregului server sau poate face o ip link set dev ${INTERFACE} jos; link-ul ip setează dev ${INTERFACE} ar putea funcționa și el.

Am avut aceeași problemă, așa că am adăugat următoarele .ssh/config fișier și nu am văzut încă acea eroare.

Gazdă i-* mi-*
ServerAliveInterval 300
ServerAliveCountMax 2

Nu există garanții că acest lucru va ajuta, dar până acum mi-a permis conexiunea să rămână deschisă mai mult decât a făcut-o.

puteți încerca să creșteți valorile ClientAliveInterval și ClientAliveCountMax:

ClientAliveInterval 60
ClientAliveCountMax 10

Cel mai probabil, serverul nu mai primește pachete de la clienți și conexiunea este deconectată din cauza unui timeout