Possibile problema di assegnazione PTY PAM SSH

Question

Ho un server Ubuntu linux ospitato su Amazon EC2. Ci sono circa 3000+ utenti Linux creati sul sistema con userid come user_1, user_2 & così via.

Sorprendentemente gli utenti fino a user_2685 sono in grado di accedere tramite ssh al server. Non oltre.

Ho modificato LogLevel in DEBUG3 in/etc/ssh/sshd_config. Incollare il contenuto pertinente.

1. discarica rilevante quando l'utente non riesce ad accedere - http://pastebin.com/NS2jC8vg

 
Apr 18 10:18:00 domU-12-31-39-01-86-0C sshd[18879]: debug1: Allocating pty. 
Apr 18 10:18:00 domU-12-31-39-01-86-0C sshd[18879]: debug3: mm_request_send entering: type 26 
Apr 18 10:18:00 domU-12-31-39-01-86-0C sshd[18879]: debug3: mm_pty_allocate: waiting for MONITOR_ANS_PTY 
Apr 18 10:18:00 domU-12-31-39-01-86-0C sshd[18879]: debug3: mm_request_receive_expect entering: type 27 
Apr 18 10:18:00 domU-12-31-39-01-86-0C sshd[18879]: debug3: mm_request_receive entering 
Apr 18 10:18:00 domU-12-31-39-01-86-0C sshd[18802]: debug3: mm_request_receive entering 
Apr 18 10:18:00 domU-12-31-39-01-86-0C sshd[18802]: debug3: monitor_read: checking request 26 
Apr 18 10:18:00 domU-12-31-39-01-86-0C sshd[18802]: debug3: mm_answer_pty entering 
Apr 18 10:18:00 domU-12-31-39-01-86-0C sshd[18802]: debug2: session_new: allocate (allocated 0 max 10) 
Apr 18 10:18:00 domU-12-31-39-01-86-0C sshd[18802]: debug3: session_unused: session id 0 unused 
Apr 18 10:18:00 domU-12-31-39-01-86-0C sshd[18802]: debug1: session_new: session 0 
Apr 18 10:18:00 domU-12-31-39-01-86-0C sshd[18802]: debug1: SELinux support disabled 
Apr 18 10:18:00 domU-12-31-39-01-86-0C sshd[18879]: debug1: do_cleanup 
Apr 18 10:18:00 domU-12-31-39-01-86-0C sshd[18879]: debug3: PAM: sshpam_thread_cleanup entering 

1. discarica rilevante quando l'utente effettua il login SUCCESSO - http://pastebin.com/vUXnpDsr

 
Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18957]: debug1: Allocating pty. 
Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18957]: debug3: mm_request_send entering: type 26 
Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18957]: debug3: mm_pty_allocate: waiting for MONITOR_ANS_PTY 
Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18957]: debug3: mm_request_receive_expect entering: type 27 
Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18957]: debug3: mm_request_receive entering 
Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18880]: debug3: mm_request_receive entering 
Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18880]: debug3: monitor_read: checking request 26 
Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18880]: debug3: mm_answer_pty entering 
Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18880]: debug2: session_new: allocate (allocated 0 max 10) 
Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18880]: debug3: session_unused: session id 0 unused 
Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18880]: debug1: session_new: session 0 
Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18880]: debug1: SELinux support disabled 
Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18880]: debug3: mm_request_send entering: type 27 
Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18880]: debug3: mm_answer_pty: tty /dev/pts/37 ptyfd 4 
Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18957]: debug1: session_pty_req: session 0 alloc /dev/pts/37 
Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18957]: debug1: Ignoring unsupported tty mode opcode 11 (0xb) 
Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18957]: debug1: Ignoring unsupported tty mode opcode 17 (0x11) 
Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18957]: debug1: server_input_channel_req: channel 0 request shell reply 1 
Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18957]: debug1: session_by_channel: session 0 channel 0 
Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18957]: debug1: session_input_channel_req: session 0 req shell 
Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18957]: debug2: fd 3 setting TCP_NODELAY 
Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18957]: debug2: channel 0: rfd 9 isatty 
Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18957]: debug2: fd 9 setting O_NONBLOCK 
Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18957]: debug3: fd 7 is O_NONBLOCK 
Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18958]: debug1: Setting controlling tty using TIOCSCTTY. 
Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18958]: debug3: Copy environment: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games 
Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18958]: debug3: Copy environment: LANG=en_US.UTF-8 
Apr 18 10:20:07 domU-12-31-39-01-86-0C jk_chrootsh[18958]: now entering jail /opt/users-rails-apps for user user_1 (1001) with arguments 

Update 1:

I suddetti dump provengono da /var/log/auth.log sul server. Di seguito sono riportati i dump sul client. Basta mettere la parte rilevante della discarica che si differenzia

login di successo

 
debug2: channel 0: request shell confirm 1 
debug2: callback done 
debug2: channel 0: open confirm rwindow 0 rmax 32768 
debug2: channel_input_status_confirm: type 99 id 0 
debug2: PTY allocation request accepted on channel 0 
debug2: channel 0: rcvd adjust 2097152 
debug2: channel_input_status_confirm: type 99 id 0 
debug2: shell request accepted on channel 0 

di accesso non riusciti

 
debug2: channel 0: request shell confirm 1 
debug2: callback done 
debug2: channel 0: open confirm rwindow 0 rmax 32768 
debug1: channel 0: free: client-session, nchannels 1 
debug3: channel 0: status: The following connections are open: 
    #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cc -1) 

Connection to www.codelearn.org closed by remote host. 
Connection to www.codelearn.org closed. 
Transferred: sent 2488, received 1472 bytes, in 0.8 seconds 
Bytes per second: sent 3043.4, received 1800.6 
debug1: Exit status -1 

OS: Ubuntu preciso server di 12.04

Openssh: OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012

SSH cliente: non importa come ho provato da Ubuntu così come il comportamento Mac & è lo stesso.

Aggiornamento 2:

Btw - questo non è un problema con PAM in quanto tale, come posso fare su user_3000 & il nuovo utente in & ottiene un PTY troppo.

Anche facendo ssh senza chiedere PTY ssh -T user_3000@www.codelearn.org registra l'utente in. Ma si interrompe dopo l'accesso & non viene visualizzato prompt. Probabilmente perché non è stato richiesto alcun prompt per il primo posto.

Answer 1

Quindi risulta questo è stato un problema con /etc/security/limits.conf per gli utenti.

Sto indovinando che PAM tenta di autenticarsi guardando il file/etc/passwd come utente. I limiti hanno un campo fsize che è stato impostato su 1000. Se l'utente è apparso in precedenza in/etc/passwd - PAM sarebbe in grado di trovare l'autenticazione &. Se è comparso più tardi, il limite di fsize potrebbe aver raggiunto & PAM si chiude.

Cambiare il valore da 1000 a 2000 ha risolto il problema.

Answer 2

Avete controllato il vostro sshd_config per garantire che non si verifichino problemi di massimo livello?

Lookout per ClientAliveCountMax MaxSessions MaxStartups

particolare MaxSessions dal tuo messaggio di accesso non riusciti elenca una serie di connessioni aperte come la ragione. Aumentare il numero e controllare il comportamento.

Puoi leggere di più qui - http://www.manpagez.com/man/5/sshd_config/