Abilita SSH simultaneo massiccio su un singolo server


9

Il mio obiettivo è consentire a 10000 SSH simultanei in esecuzione su un singolo server.

Per semplicità sto scrivendo a localhost:

for i in `seq 1 10000`; do
    ssh localhost "echo ${i}; sleep 100"  >>./info 2>>./log &
done

sleep 100è assicurarsi che quando inizia la 10000 ssh , la 1a ssh sia ancora connessa, quindi ci sono effettivamente 10000 ssh simultanee .

Ed ecco i due tipi di messaggi di errore che ho ricevuto:

1. ssh_exchange_identification: Connection closed by remote host

2. ssh_exchange_identification: read: Connection reset by peer

Ho apportato le seguenti modifiche:

  1. In /etc/security/limits.confe /etc/security/limits.d/90-nproc.conf, impostare soft & hard nofile& nprocsu 65535 (questo è il valore massimo possibile giusto? - Aggiornamento: no. Il valore massimo è 1048576 )
  2. In /etc/sysctl.conf, setkernel.pty.max = 65535
  3. In /etc/ssh/sshd_config, set MaxStartups 10000.

Queste modifiche mi permettono di eseguire correttamente 1000 concomitante ssh s per un singolo server, ma non lo fanno il lavoro per il 2000 e al di sopra ssh s.

Alcune persone hanno suggerito di cambiare il valore per MaxSessions(in realtà non sono chiaro sul suo utilizzo: in che modo il multiplexing influisce sul mio caso?), /proc/sys/net/core/netdev_max_backlogE /proc/sys/net/core/somaxconn, ma sembrano non fare alcuna differenza.

Inoltre, non ci sono errori se sono 10000 SSH simultanei su server diversi (i problemi si verificano solo quando SSH su un singolo server):

for i in `seq 1 10000`; do
    j=$(( 1 + $i % 8 ))
    ssh server-${j} "echo hi; sleep 100" >info-${j} 2>log-${j} &
done

Sono stato bloccato su questo per molto tempo.
Ogni aiuto sarebbe profondamente apprezzato!


1
Il registro del server sshd può fornire ulteriori informazioni sul motivo del rifiuto delle connessioni. Fondamentalmente se vuoi solo 10000 sessioni, ti consiglio di usare il multiplexing usando ControlMaster (e poi ovviamente bump MaxSessions).
Jakuje,

1
Non penso sleep 100sche faccia quello che pensi. Viene eseguito non nella sessione ssh, ma sul tuo computer.
Daniel Kullmann,

1
@Jakuje grazie per avermi ricordato di controllare il registro del server! Ho trovato error: reexec socketpair: Too many open files, quindi suppongo che il valore precedente di nofile(cioè 65535) fosse tutt'altro che sufficiente. Non ho familiarità con ControlMaster ma ci proverò, grazie !! :)
Clara,

1
Interessante, quando eseguo una delle righe, un ps axu | egrep "ssh|sleep" | grep -v grepsolo elenca il sleep 100s, non il ssh. Penso che dovresti cambiare il comando in ssh "echo hi; sleep 100s".
Daniel Kullmann,

2
@danielkullmann Sì, hai assolutamente ragione - sleep 100dovrebbe essere nel comando inviato tramite ssh, come nel mio vero script, ma ho fatto un refuso qui. Ho aggiornato il post principale di conseguenza. Grazie mille per averlo sottolineato !!
Clara,

Risposte:


2

/ vorrei che potesse commentare

sshd deve (in genere, ma non hai specificato i casi d'uso esatti, ecc.) allocare un pty per login, tuttavia nel tuo caso ssh "echo hi; sleep 100s" NON alloca un pty, quindi non è necessario per l'impostazione kernel.pty.max ... a meno che non si desideri che migliaia di utenti abbiano effettuato l'accesso * ... per verificarlo, è necessario aggiungere l'opzione -t ai propri test, ad es. ssh -t "echo hi; sleep 100s"

Tornando al problema in questione con i error: reexec socketpair: Too many open files test su un Wheezy aggiornato al sistema Jessie, ho scoperto che / etc / security / limit * non cambia i limiti di sshd.

controlla quello con cat /proc/<pid-of-sshd>/limits cui nel mio caso, dopo aver impostato in /etc/security/limits.conf: * nofile soft 65535 * nofile hard 65535 riporta ancora solo 1024 (soft) e 4096 (hard) per i limiti di sshd. La risoluzione sembra essere quella di forzare ulimit -Hn 65535& ulimit -n 65535all'interno dello /etc/init.d/sshscript usando quei comandi ulimit, ho alzato i nofile di sshd a 65535/65535 da 1024/4096

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.