Warum schlägt scp sporadisch fehl, wenn mehrere scps gleichzeitig ausgeführt werden?

Question

Ich habe eine kleine Anwendung, die versucht, ein Dutzend parallele "scp" Läufe zu tun, Dateien von einem Remote-System zu ziehen. Normalerweise läuft es gut. Manchmal, ein oder zwei der scp läuft leise stirbt. („leise“, wenn von Linux zu ziehen. Wenn Ziehen von HP-UX, ich eine Nachricht wie Verbindung von Peer zurückgesetzt erhalten.)

Wenn ich „-v“ zu meinen scp Befehle hinzufügen, dann, wenn ein Fehler auftritt Ich sehe, dass ich bin bekommen "ssh_exchange_identification: lesen: Verbindung zurückgesetzt von Peer" (unter Linux ... habe nicht versucht, die -v auf HP-UX).

Hier ist der „scp -v“ Ausgang für einen typischen Lauf, mit dem Punkt, an dem einen ‚schlechter‘ Lauf und ein ‚guter‘ divergieren angegeben laufen:

Executing: program /usr/bin/ssh host wilbur, user (unspecified), command scp -v -p -f /home/sieler/source/misc/[p-q]*.[ch] 
OpenSSH_6.9p1, LibreSSL 2.1.8 
debug1: Reading configuration data /etc/ssh/ssh_config 
debug1: /etc/ssh/ssh_config line 51: Applying options for * 
debug1: Connecting to wilbur [10.84.3.61] port 22. 
debug1: Connection established. 
debug1: identity file /Users/sieler/.ssh/id_rsa type 1 
debug1: key_load_public: No such file or directory 
debug1: identity file /Users/sieler/.ssh/id_rsa-cert type -1 
debug1: key_load_public: No such file or directory 
debug1: identity file /Users/sieler/.ssh/id_dsa type -1 
debug1: key_load_public: No such file or directory 
debug1: identity file /Users/sieler/.ssh/id_dsa-cert type -1 
debug1: key_load_public: No such file or directory 
debug1: identity file /Users/sieler/.ssh/id_ecdsa type -1 
debug1: key_load_public: No such file or directory 
debug1: identity file /Users/sieler/.ssh/id_ecdsa-cert type -1 
debug1: key_load_public: No such file or directory 
debug1: identity file /Users/sieler/.ssh/id_ed25519 type -1 
debug1: key_load_public: No such file or directory 
debug1: identity file /Users/sieler/.ssh/id_ed25519-cert type -1 
debug1: Enabling compatibility mode for protocol 2.0 
debug1: Local version string SSH-2.0-OpenSSH_6.9 

‚schlecht‘ und ‚gut‘ Läufe passen bis zu diesem Punkt, dann ...

Bad:

ssh_exchange_identification: read: Connection reset by peer 

Gut:

debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3 
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000 
debug1: Authenticating to wilbur:22 as 'sieler' 
debug1: SSH2_MSG_KEXINIT sent 
debug1: SSH2_MSG_KEXINIT received 
debug1: kex: server->client aes128-ctr umac-64@openssh.com none 
debug1: kex: client->server aes128-ctr umac-64@openssh.com none 
... 

Obwohl der übliche Host-Rechner für das Skript und scp läuft, ist ein Mac mit OS X 10.11.4, das Problem wurde reproduziert zu/von mehreren Kombinationen von Mac/Linux/HP-UX (genug, um auszuschließen es ist ein Mac oder HP-UX spezifisches Problem).

IIRC, mit scp von Linux auf Mac zu ziehen hat das Problem, sowie Ziehen von HP-UX auf Mac, und ziehen von Linux zu HP-UX.
Haben Sie nicht versucht, von Mac oder HP-UX zu Linux zu ziehen.

Gibt es etwas über scp/ssh/openssh, dass die parallele Nutzung manchmal fehlschlägt?

Wenn ich sshd auf dem Linux-System mit -ddd laufen, dann stoppt der Dämon nach der erste scp greift sie (die scp hat kein Problem), und die anderen elf scp läuft scheitern.

Dank

Answer 1

Dies wird wahrscheinlich durch die Begrenzung der parallelen Sitzungen in sshd_config verursacht. Standardmäßig ist der Server so konfiguriert, dass er "zufälliges frühes Fallenlassen" ausführt, was bedeutet, dass neue Verbindungen abgelehnt werden, wenn die aktive Menge größer als ein Limit ist. Die verantwortliche Option ist MaxStartups (von Mann sshd_config):

MaxStartups

die maximale Anzahl gleichzeitiger nicht authentifizierte Verbindungen zum SSH-Daemon fest. Zusätzliche Verbindungen werden verworfen, bis die Authentifizierung erfolgreich ist oder die LoginGraceTime für eine Verbindung abläuft. Der Standardwert ist 10: 30: 100.

Alternativ kann der zufällige frühe Abfall durch Angabe der drei Doppelpunkt-getrennten Werte "start: rate: full" (z. B. "10:30:60") aktiviert werden.sshd (8) wird Verbindungsversuche mit einer Wahrscheinlichkeit von "rate/100" (30%) ablehnen, wenn derzeit "nicht authentifizierte" Verbindungen ("Start") (10) vorhanden sind. Die Wahrscheinlichkeit steigt linear an und alle Verbindungsversuche werden abgelehnt, wenn die Anzahl der nicht authentifizierten Verbindungen "voll" erreicht (60).

Wenn Sie den Wert auf etwas Größeres als die von Ihnen erwartete Anzahl von Verbindungen stossen, sollten Sie Ihr Problem lösen. Andernfalls können Sie LogLevel DEBUG3 in sshd_config festlegen, um mehr Protokolle im Systemprotokoll anzuzeigen.

---

Aber wenn Sie mit dem gleichen Server verbunden sind, ist es besser Verbindungsmultiplexing zu verwenden. Es wird schneller sein und Sie werden diese Probleme nicht haben. Check out ControlMaster Option in ssh_config oder überprüfen Sie einfach my similar answer für einen schnellen Ausflug zu diesem "Magie".