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

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

4 月 18 日 10:18:00 domU-12-31-39-01-86-0C sshd[18879]：调试 1：分配 pty。 4 月 18 日 10:18:00 domU-12-31-39-01-86-0C sshd[18879]：调试 3：mm_request_send 输入：类型 26 4 月 18 日 10:18:00 domU-12-31-39-01-86-0C sshd[18879]：调试 3：mm_pty_allocate：等待 MONITOR_ANS_PTY 4 月 18 日 10:18:00 domU-12-31-39-01-86-0C sshd[18879]：调试 3：mm_request_receive_expect 输入：类型 27 4 月 18 日 10:18:00 domU-12-31-39-01-86-0C sshd[18879]: debug3: mm_request_receive 进入 4 月 18 日 10:18:00 domU-12-31-39-01-86-0C sshd[18802]: debug3: mm_request_receive 进入 4 月 18 日 10:18:00 domU-12-31-39-01-86-0C sshd[18802]: debug3: monitor_read: 检查请求 26 4 月 18 日 10:18:00 domU-12-31-39-01-86-0C sshd[18802]: debug3: mm_answer_pty 进入 4 月 18 日 10:18:00 domU-12-31-39-01-86-0C sshd[18802]: debug2: session_new: allocate (allocated 0 max 10) 4 月 18 日 10:18:00 domU-12-31-39-01-86-0C sshd[18802]: debug3: session_unused: session id 0 未使用 4 月 18 日 10:18:00 domU-12-31-39-01-86-0C sshd[18802]: debug1: session_new: session 0 4 月 18 日 10:18:00 domU-12-31-39-01-86-0C sshd[18802]：调试 1：禁用 SELinux 支持 4 月 18 日 10:18:00 domU-12-31-39-01-86-0C sshd[18879]：调试 1：do_cleanup 4 月 18 日 10:18:00 domU-12-31-39-01-86-0C sshd[18879]: debug3: PAM: sshpam_thread_cleanup 进入

1. 用户成功登录时的相关转储 - http://pastebin.com/vUXnpDsr

4 月 18 日 10:20:07 domU-12-31-39-01-86-0C sshd[18957]：调试 1：分配 pty。 4 月 18 日 10:20:07 domU-12-31-39-01-86-0C sshd[18957]：调试 3：mm_request_send 输入：类型 26 4 月 18 日 10:20:07 domU-12-31-39-01-86-0C sshd[18957]：调试 3：mm_pty_allocate：等待 MONITOR_ANS_PTY 4 月 18 日 10:20:07 domU-12-31-39-01-86-0C sshd[18957]：调试 3：mm_request_receive_expect 输入：类型 27 4 月 18 日 10:20:07 domU-12-31-39-01-86-0C sshd[18957]: debug3: mm_request_receive 进入 4 月 18 日 10:20:07 domU-12-31-39-01-86-0C sshd[18880]: debug3: mm_request_receive 进入 4 月 18 日 10:20:07 domU-12-31-39-01-86-0C sshd[18880]: debug3: monitor_read: 检查请求 26 4 月 18 日 10:20:07 domU-12-31-39-01-86-0C sshd[18880]: debug3: mm_answer_pty 进入 4 月 18 日 10:20:07 domU-12-31-39-01-86-0C sshd[18880]: debug2: session_new: allocate (allocated 0 max 10) 4 月 18 日 10:20:07 domU-12-31-39-01-86-0C sshd[18880]: debug3: session_unused: session id 0 未使用 4 月 18 日 10:20:07 domU-12-31-39-01-86-0C sshd[18880]: debug1: session_new: session 0 4 月 18 日 10:20:07 domU-12-31-39-01-86-0C sshd[18880]：调试 1：禁用 SELinux 支持 4 月 18 日 10:20:07 domU-12-31-39-01-86-0C sshd[18880]：调试 3：mm_request_send 输入：类型 27 4 月 18 日 10:20:07 domU-12-31-39-01-86-0C sshd[18880]: debug3: mm_answer_pty: tty /dev/pts/37 ptyfd 4 4 月 18 日 10:20:07 domU-12-31-39-01-86-0C sshd[18957]: debug1: session_pty_req: session 0 alloc /dev/pts/37 4 月 18 日 10:20:07 domU-12-31-39-01-86-0C sshd[18957]：调试 1：忽略不支持的 tty 模式操作码 11 (0xb) Apr 18 10:20:07 domU-12-31-39-01-86-0C sshd[18957]: debug1: 忽略不支持的 tty 模式操作码 17 (0x11) 4 月 18 日 10:20:07 domU-12-31-39-01-86-0C sshd[18957]: debug1: server_input_channel_req: channel 0 request shell reply 1 4 月 18 日 10:20:07 domU-12-31-39-01-86-0C sshd[18957]: debug1: session_by_channel: session 0 channel 0 4 月 18 日 10:20:07 domU-12-31-39-01-86-0C sshd[18957]: debug1: session_input_channel_req: session 0 req shell 4 月 18 日 10:20:07 domU-12-31-39-01-86-0C sshd[18957]：调试 2：fd 3 设置 TCP_NODELAY 4 月 18 日 10:20:07 domU-12-31-39-01-86-0C sshd[18957]：调试 2：通道 0：rfd 9 isatty 4 月 18 日 10:20:07 domU-12-31-39-01-86-0C sshd[18957]：调试 2：fd 9 设置 O_NONBLOCK 4 月 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: 使用 TIOCSCTTY 设置控制 tty。 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 4 月 18 日 10:20:07 domU-12-31-39-01-86-0C sshd[18958]：debug3：复制环境：LANG=en_US.UTF-8 4 月 18 日 10:20:07 domU-12-31-39-01-86-0C jk_chrootsh[18958]：现在为用户 user_1 (1001) 输入 jail /opt/users-rails-apps 参数

更新 1：

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

登录成功

debug2：通道 0：请求 shell 确认 1 debug2：回调完成 debug2：通道 0：打开确认 rwindow 0 rmax 32768 debug2：channel_input_status_confirm：类型 99 id 0 debug2: 在通道 0 上接受 PTY 分配请求 debug2：通道 0：rcvd 调整 2097152 debug2：channel_input_status_confirm：类型 99 id 0 debug2：在通道 0 上接受了 shell 请求

登录失败

debug2：通道 0：请求 shell 确认 1 debug2：回调完成 debug2：通道 0：打开确认 rwindow 0 rmax 32768 debug1：通道 0：免费：客户端会话，nchannels 1 debug3：通道 0：状态：以下连接已打开： #0 客户端会话（t4 r0 i0/0 o0/0 fd 4/5 cc -1） 远程主机关闭与 www.codelearn.org 的连接。 与 www.codelearn.org 的连接已关闭。 已传输：发送 2488，接收 1472 字节，在 0.8 秒内 每秒字节数：发送 3043.4，接收 1800.6 debug1：退出状态-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。

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

Answer 1

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

注意 ClientAliveCountMax MaxSessions MaxStartups

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

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

Answer 2

原来这是用户的 /etc/security/limits.conf 问题。

我猜 PAM 试图通过以用户身份查看 /etc/passwd 文件来进行身份验证。限制有一个字段 fsize 设置为 1000 。如果用户较早出现在 /etc/passwd - PAM 将能够找到并进行身份验证。如果他稍后出现，可能已经达到 fsize 限制并且 PAM 退出。

将 fsize 从 1000 更改为 2000 解决了这个问题。