Puncte:1

Quick, successive SSH connection attempts hanging

drapel jp

I have a bash script which copies small files in succession using scp. So there are a bunch of scp commands in this script. An SSH key is being used to authenticate to the other server.

Because the files are so small, the SSH connection attempts happen very quickly, and not far into the script at all, an scp will hang indefinitely.

  • No errors produced.
  • Network equipment has been eliminated from the equation and the servers communicating live on the same subnet.
  • Issue has been demonstrated with rsync as well.

If a sleep of 1 second is placed between these scp calls, the script runs smoothly, no hang.

Where should I look for this apparent rate limiting? I don't see this between any of my other servers...

Michael Hampton avatar
drapel cz
Te-ai gândit să folosești conexiuni ssh persistente? Nu numai că ar rezolva această problemă, ci ar face transferul general mult mai rapid.
Marcus avatar
drapel jp
@MichaelHampton Am luat în considerare acest lucru de fapt, dar deoarece depanez procesele pe care nu le dețin, am sarcina de a remedia problema fără a schimba scriptul. Cu siguranță o idee de soluție decentă totuși.
Marcus avatar
drapel jp
@anx Este interesant, mulțumesc pentru link, nu știam asta. Cu toate acestea, această problemă SSH a fost demonstrată și cu rsync, așa că cred că problema nu este cu scp.
Puncte:3
drapel in

Uneori oamenii se instalează limitarea ratei folosind iptables.

OpenSSH are MaxStartups opțiune care limitează o anumită rată pentru clienții care intră. Valoarea implicită (cel puțin pe computerul meu) este 10:30:100.

man sshd_config

Alternativ, eliminarea anticipată aleatorie poate fi activată prin specificarea celor trei valori separate prin două puncte start:rate:full (de exemplu, „10:30:60”). sshd(8) va refuza încercările de conectare cu o probabilitate de rate/100 (30%) dacă există în prezent conexiuni neautentificate de pornire (10). Probabilitatea crește liniar și toate încercările de conectare sunt refuzate dacă numărul de conexiuni neautentificate ajunge la maxim (60).

O altă problemă semi-obișnuită și cauză a întârzierii conexiunii OpenSSH este legată de o caracteristică de pe serverul OpenSSH care va încerca să facă o căutare inversă a adresei IP de intrare la o încercare de conectare. Cred că are nevoie de această funcționalitate DNS pentru compatibilitate cu unele dintre metodele mai vechi de autentificare compatibile cu rhost, funcționalitate pe care cred că aproape nimeni nu o mai folosește. Oricum, caracteristica de rezoluție DNS va cauza probleme dacă rezolutoarele DNS sunt configurate prost, sunt configurate să utilizeze un rezolutor stricat sau poate că ceva despre zona inversă de la care se conectează IP-ul clientului este întrerupt.

În mod ideal, răspunsul este să remediați DNS-ul și să vă asigurați că DNS-ul dvs. funcționează întotdeauna fără erori și că răspunde rapid. Dar dacă nu aveți nevoie de rezoluția DNS, atunci o soluție rapidă aici este să opriți serverul să încerce să rezolve numele. A stabilit UseDNS nr în dumneavoastră sshd_config.

Marcus avatar
drapel jp
Multumesc pentru acest raspuns. Din păcate, cred că le-am eliminat, deoarece MaxStartups este setat la fel ca pe gazdele mele care nu prezintă blocarea. Iar iptables nu conține reguli de limitare a ratei.
drapel in
De fapt, se blochează „la nesfârșit” sau doar o lungă perioadă de timp? O altă posibilitate la care mă gândesc este că ați rupt DNS-ul pe acel server și că a expirat încercarea de a rezolva DNS-ul. Poate doriți să setați „UseDNS no” în sshd_config.
Marcus avatar
drapel jp
Cred că ai reușit cu UseDNS nr. Dacă doriți să vă actualizați răspunsul cu această informație suplimentară care mi-a rezolvat problema, îl voi accepta.
anx avatar
drapel fr
anx
@Marcus care este fundalul eșecului DNS pentru încercări succesive de conectare, totuși? Este aceasta defecțiunea sau un rezolvator de stub local defect sau ceva care într-adevăr nu poate fi remediat local?
Marcus avatar
drapel jp
@anx Cauza rădăcină este încă în curs de investigare. Știind că este DNS, deși este extrem de util. Aveam alte indicii că era DNS, dar nu știam despre UseDNS al SSH până acum.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.