我有一个托管在 Amazon EC2 上的 linux ubuntu 服务器。在系统上创建了大约 3000 多个 linux 用户,用户 ID 为 user_1、user_2 等。
令人惊讶的是,直到 user_2685 的用户都能够通过 ssh 登录到服务器。不止于此。
我已将 /etc/ssh/sshd_config 中的 LogLevel 更改为 DEBUG3。粘贴相关内容。
- 用户无法登录时的相关转储 - 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 进入
- 用户成功登录时的相关转储 - 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 会登录用户。但它会停止登录后并且没有出现提示。可能那是因为一开始没有要求提示。