Possible SSH PAM PTY distribution problem

I have a ubuntu linux server hosted on Amazon EC2. There are more than 3000 linux users in the system, such as user_1, user_2, etc.

Surprisingly, users up to user_2685 can log in via ssh to the server. Not further.

I changed LogLevel to DEBUG3 in / etc / ssh / sshd _config. Insert relevant content.

  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
  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:

The above dumps from /var/log/auth.log on the server. The following are dumps on the client. Just place the corresponding dump part which is different

Successful login

  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

Failed login

  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 exact 12.04

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

SSH client: it doesn't matter since I tried to use ubuntu as well as Mac and the behavior is the same.

Update 2:

Btw is not a problem with PAM, since I can do su user_3000 and a new user logs in and receives PTY.

Also does ssh without a PTY request ssh -T user_3000@www.codelearn.org registers the user. But he stops sending messages and the invitation does not appear. This is probably because the invitation was not requested first.

+6
source share
2 answers

So it turns out that this is a problem with /etc/security/limits.conf for users.

I assume that PAM is trying to authenticate by looking at the / etc / passwd file as a user. Limits have an fsize field that has been set to 1000. If the user appeared earlier in / etc / passwd, PAM will be able to find and authenticate. If he appears later, he may reach the limit of physicism, and PAM will cease to exist.

Replacing fsize from 1000 to 2000 fixed the problem.

0
source

Have you checked your sshd_config so that there are no problems with maximum?

Search ClientAliveCountMax MaxSessions MaxStartups

In particular, MaxSessions , since your unsuccessful login message contains a list of open connections as a reason. Increase the number and check the behavior.

You can read more here - http://www.manpagez.com/man/5/sshd_config/

0
source

All Articles