Możliwy problem alokacji PTY PST SSH

Question

Mam serwer Ubuntu Linuxa hostowany na Amazon EC2. Istnieje około 3000 użytkowników Linuksa utworzonych w systemie z userid jako user_1, user_2 & i tak dalej.

Zaskakująco użytkownicy do user_2685 są w stanie zalogować się przez ssh na serwer. Nie dalej.

Zmieniłem LogLevel na DEBUG3 w/etc/ssh/sshd_config. Wklejanie odpowiednich treści.

1. Stosowna wysypisko, gdy użytkownik nie powiedzie się zalogować - 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. Stosowna wysypisko gdy użytkownik pomyślnie się zalogować - 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 

Aktualizacja 1:

Powyższe zrzuty pochodzą z /var/log/auth.log na serwerze. Poniżej znajdują się zrzuty na kliencie. Tylko wprowadzenie odpowiedniej części składowiska, która różni

udanym logowaniu

 
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 

Nieudane logowania

 
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 precyzyjny serwera 12,04

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

SSH klient: nie ma znaczenia jak ja wypróbowany od zachowania Ubuntu i Maca Mac OS X: Zachowanie jest takie samo.

Aktualizacja 2:

Btw - to nie jest problem z PAM jako taki jak mogę zrobić su user_3000 & nowe użytkownik loguje się & dostaje zbyt PTY.

Robienie ssh bez pytania o PTY ssh -T user_3000@www.codelearn.org powoduje zalogowanie użytkownika. Ale zatrzymuje się po zalogowaniu & nie pojawia się monit. Prawdopodobnie dlatego, że na początku nie pytano o monit.

Answer 1

więc okazuje się, że był to problem z /etc/security/limits.conf dla użytkowników.

Zgaduję, że PAM próbuje uwierzytelnić, patrząc na plik/etc/passwd jako użytkownik. Limity mają pole fsize, które zostało ustawione na 1000. Jeśli użytkownik pojawił się wcześniej w/etc/passwd - PAM byłby w stanie znaleźć uwierzytelnienie &. Jeśli pojawił się później, limit fsize mógł osiągnąć & PAM.

Zmiana rozmiaru fsize z 1000 na 2000 naprawiła problem.

Answer 2

Czy sprawdziłeś swoje sshd_config, aby upewnić się, że nie występują problemy z maksymalizacją?

poszukiwania ClientAliveCountMax MaxSessions MaxStartups

Konkretnie MaxSessions od swojej nieudanej wiadomości logowania wymienia kilka otwartych połączeń jako powód. Zwiększ liczbę i sprawdź zachowanie.

można przeczytać więcej tutaj - http://www.manpagez.com/man/5/sshd_config/