首页 文章

可能的SSH PAM PTY分配问题[关闭]

提问于
浏览
6

我在Amazon EC2上托管了一个linux ubuntu服务器 . 在系统上创建了大约3000个Linux用户,其中userid为user_1,user_2等 .

令人惊讶的是,用户直到user_2685才能通过ssh登录到服务器 . 不仅如此 .

我在/ etc / ssh / sshd_config中将LogLevel更改为DEBUG3 . 粘贴相关内容 .

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

更新1:

上述转储来自服务器上的/var/log/auth.log . 以下是客户端上的转储 . 只是将转储的相关部分放在不同的位置

成功登录

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

登录失败

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

操作系统:Ubuntu精确12.04

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

SSH客户端:无所谓,因为我从ubuntu尝试过以及Mac和行为是一样的 .

更新2:

顺便说一句 - 这不是PAM的问题,因为我可以做 su user_3000 &新用户登录&获得一个PTY .

同时做ssh而不要求PTY ssh -T user_3000@www.codelearn.org 记录用户 . 但是它会在登录后停止并且不会出现提示 . 可能是因为首先没有要求提示 .

2 回答

  • 0

    您是否检查了 sshd_config 以确保没有发生最大限度的问题?

    了解 ClientAliveCountMax MaxSessions MaxStartups

    特别是 MaxSessions ,因为您的登录消息不成功列出了一堆打开的连接作为原因 . 增加数量并检查行为 .

    你可以在这里阅读更多内容 - http://www.manpagez.com/man/5/sshd_config/

  • 0

    事实证明这对用户来说是/etc/security/limits.conf的问题 .

    我猜测PAM尝试通过查看/ etc / passwd文件作为用户进行身份验证 . 限制的字段fsize设置为1000 . 如果用户在/ etc / passwd中出现较早--PAM将能够找到并进行身份验证 . 如果他后来出现,fsize限制可能已达到&PAM退出 .

    将fsize从1000更改为2000可以解决问题 .

相关问题