6

我有一个托管在 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。

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

4

2 回答 2

0

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

密切注意，提防，小心 ClientAliveCountMax MaxSessions MaxStartups

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

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

于 2013-04-19T10:36:22.683 回答
0

所以事实证明这是用户的 /etc/security/limits.conf 问题。

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

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

于 2013-04-19T12:08:00.257 回答