2013-04-18 16 views
6

私は、Amazon EC2でホストされているLinuxのubuntuサーバーを持っています。システム上に約3000人以上のLinuxユーザがuser_1、user_2として&というように作成されています。可能なSSH PAM PTY割り当ての問題

驚いたことに、user_2685がssh経由でサーバにログインできるようになるまでユーザーは驚いています。それを超えない。

私はLogLevelを/ etc/ssh/sshd_configの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 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 
  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 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からのものです。以下は、クライアント上のダンプです。 Ubuntuの正確12.04

OpenSSHサーバ:OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012

SSHだけ

成功したログイン

 
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 

OSの違いダンプの関連部分を置きますクライアント:私の持つものとは関係ありませんMacと同様にubuntuから試して&の動作は同じです。

アップデート2:

はところで - これは私が&にsu user_3000 &新しいユーザーがログインを行うことができますなどとしてPAMの問題ではありませんあまりにもPTYを取得します。

また、PTYを要求せずにsshを実行するssh -T [email protected]はユーザーをログインしますが、ログイン後は停止します&プロンプトが表示されません。おそらく、最初にプロンプ​​トが尋ねられなかったからです。

+0

実際の原因がPAMモジュールに関連している可能性があることを示すスレッドがあります。 http://ubuntuforums.org/archive/index.php/t-1448030.html HTH。 –

答えて

0

だから、これはユーザーのための/etc/security/limits.confを持つ問題だったが判明しました。

私はPAMが/ etc/passwdファイルをユーザとして見て認証しようとしていると推測しています。制限にはフィールドfsizeがあり、これは1000に設定されています。ユーザが/ etc/passwdに以前に登場した場合、PAMは&認証を見つけることができます。彼が後で現れた場合、fsizeの上限は&に達している可能性があります。

fsizeを1000から2000に変更すると問題が解決しました。

0

sshd_configをチェックして、最大限の問題が発生していないことを確認しましたか?

ClientAliveCountMax MaxSessions MaxStartups

に目を光らせ具体的MaxSessionsあなたの失敗したログインメッセージが理由としてオープン接続の束を示していますので、。番号を増やして、動作を確認してください。

あなたはもっとここまで読むことができます - http://www.manpagez.com/man/5/sshd_config/

+0

「Max」を検索すると、「#MaxStartups 10:30:60」というエントリが1つしかありません。また、私はそれがMaxSessionsだとは思っていません。なぜなら、ログインできるユーザーは実際に複数回同時にログインできるからです。ログインできなかったユーザーは、決してログインできません。 – Pocha

+0

自分でsshを試してみることができます。 sshのユーザーアカウントの詳細は、http://hackerstreet.in/item?id = 26459を参照してください。 – Pocha

関連する問題