ssh - 可能的 SSH PAM PTY 分配问题

Question

已关闭。此问题不符合 Stack Overflow guidelines 。目前不接受答案。

---

这个问题似乎不是关于 a specific programming problem, a software algorithm, or software tools primarily used by programmers 。如果您认为这个问题与 another Stack Exchange site 上的主题有关，您可以发表评论来解释问题可能在哪里得到解答。

已关闭 7 年前。

Improve this question

我有一个托管在 Amazon EC2 上的 Linux ubuntu 服务器。系统上创建了大约 3000 多个 Linux 用户，用户 ID 为 user_1、user_2 等。

令人惊讶的是，user_2685 之前的用户都能够通过 ssh 登录服务器。不超出这个范围。

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

1. 用户登录失败时的相关转储 - 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 26Apr 18 10:18:00 domU-12-31-39-01-86-0C sshd[18879]: debug3: mm_pty_allocate: waiting for MONITOR_ANS_PTYApr 18 10:18:00 domU-12-31-39-01-86-0C sshd[18879]: debug3: mm_request_receive_expect entering: type 27Apr 18 10:18:00 domU-12-31-39-01-86-0C sshd[18879]: debug3: mm_request_receive enteringApr 18 10:18:00 domU-12-31-39-01-86-0C sshd[18802]: debug3: mm_request_receive enteringApr 18 10:18:00 domU-12-31-39-01-86-0C sshd[18802]: debug3: monitor_read: checking request 26Apr 18 10:18:00 domU-12-31-39-01-86-0C sshd[18802]: debug3: mm_answer_pty enteringApr 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 unusedApr 18 10:18:00 domU-12-31-39-01-86-0C sshd[18802]: debug1: session_new: session 0Apr 18 10:18:00 domU-12-31-39-01-86-0C sshd[18802]: debug1: SELinux support disabledApr 18 10:18:00 domU-12-31-39-01-86-0C sshd[18879]: debug1: do_cleanupApr 18 10:18:00 domU-12-31-39-01-86-0C sshd[18879]: debug3: PAM: sshpam_thread_cleanup entering

1. 用户成功登录时的相关转储 - 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 26Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18957]: debug3: mm_pty_allocate: waiting for MONITOR_ANS_PTYApr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18957]: debug3: mm_request_receive_expect entering: type 27Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18957]: debug3: mm_request_receive enteringApr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18880]: debug3: mm_request_receive enteringApr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18880]: debug3: monitor_read: checking request 26Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18880]: debug3: mm_answer_pty enteringApr 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 unusedApr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18880]: debug1: session_new: session 0Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18880]: debug1: SELinux support disabledApr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18880]: debug3: mm_request_send entering: type 27Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18880]: debug3: mm_answer_pty: tty /dev/pts/37 ptyfd 4Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18957]: debug1: session_pty_req: session 0 alloc /dev/pts/37Apr 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 1Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18957]: debug1: session_by_channel: session 0 channel 0Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18957]: debug1: session_input_channel_req: session 0 req shellApr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18957]: debug2: fd 3 setting TCP_NODELAYApr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18957]: debug2: channel 0: rfd 9 isattyApr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18957]: debug2: fd 9 setting O_NONBLOCKApr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18957]: debug3: fd 7 is O_NONBLOCKApr 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/gamesApr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18958]: debug3: Copy environment: LANG=en_US.UTF-8Apr 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 1debug2: callback donedebug2: channel 0: open confirm rwindow 0 rmax 32768debug2: channel_input_status_confirm: type 99 id 0debug2: PTY allocation request accepted on channel 0debug2: channel 0: rcvd adjust 2097152debug2: channel_input_status_confirm: type 99 id 0debug2: shell request accepted on channel 0

登录失败

debug2: channel 0: request shell confirm 1debug2: callback donedebug2: channel 0: open confirm rwindow 0 rmax 32768debug1: channel 0: free: client-session, nchannels 1debug3: 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 secondsBytes per second: sent 3043.4, received 1800.6debug1: Exit status -1

操作系统:Ubuntu Precision 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。

也可以在不要求 PTY 的情况下执行 ssh ssh -T user_3000@www.codelearn.org登录用户。但它会在登录后停止并且不会出现提示。可能这是因为一开始就没有要求提示。

Answer 1

您是否检查过您的 sshd_config 以确保没有发生最大问题？

留意ClientAliveCountMax最大 session 数MaxStartups

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

您可以在此处阅读更多信息 - http://www.manpagez.com/man/5/sshd_config/