Possible SSH PAM PTY allocation issue [closed]

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 6 years ago.

Improve this question

I have a linux ubuntu server hosted on Amazon EC2. There are around 3000+ linux users created on the system with userid as user_1, user_2 & so on.

Surprisingly users till user_2685 are able to login via ssh to the server. Not beyond that.

I have changed LogLevel to DEBUG3 in /etc/ssh/sshd_config . Pasting the relevant content.

1. Relevant dump when user fails to login - 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. Relevant dump when user SUCCESSFULLY login - 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:

The above dumps are from /var/log/auth.log on the server. Below are the dumps on the client. Just putting the relevant part of the dump that differs

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

Unsuccessful 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 precise 12.04

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

SSH client: does not matter as I have tried from ubuntu as well as Mac & behavior is the same.

Update 2:

Btw - this is not a problem with PAM as such as I can do su user_3000 & the new user logs in & gets a PTY too.

Also doing ssh without asking for PTY ssh -T user_3000@www.codelearn.org logs the user in. But it stops post login & no prompt appears. Probably that is because no prompt was asked for the at the first place.

Answer 1

So turns out this was a problem with /etc/security/limits.conf for the users.

I am guessing that PAM tries to authenticate by looking at /etc/passwd file as the user. The limits have a field fsize which was set to 1000 . If the user appeared earlier in /etc/passwd - PAM would be able to find & authenticate. If he appeared later, fsize limit might have reached & PAM quits.

Changing fsize from 1000 to 2000 fixed the problem.

Answer 2

Have you checked your sshd_config to ensure no maxing out issues are occurring?

Lookout for ClientAliveCountMax MaxSessions MaxStartups

Specifically MaxSessions since your unsuccessful login message lists a bunch of open connections as the reason. Increase the number and check the behavior.

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