私には、複数のユーザーを持つ機能的な EC2 インスタンスがあります。そのうちの一部はホーム ディレクトリに chroot されており、一部は ftp のみでシェル アクセスがないなどです。ec2-user はメインの管理者アカウントですが、他のユーザーもルート アクセスと完全な ssh ログインを持っています。実行中のインスタンスでは、すべてがうまく機能しています。
インスタンスのスナップショット イメージを取得し、そのスナップショットから新しいインスタンスを起動できます。新しいインスタンスに関連付けられたキー ペアに関して何を選択しても (ec2-user の元のキー ペアを使用する、新しいキー ペアを作成する、またはキー ペアを使用しない)、新しいインスタンスが起動して実行されると、ec2-user またはその他の ssh 対応ユーザーを使用してサーバーに ssh で接続できなくなります。ただし、ftp は正常に動作します。
セキュリティ グループは問題ではありません。私の知る限り、着信トラフィックは許可されています (いずれにしても、元のインスタンスと同じセキュリティ グループです)。
ログイン試行の /var/log/secure には次の内容が表示されます:
sshd[1739]: debug1: userauth-request for user ec2-user service ssh-connection method none
sshd[1739]: debug1: attempt 0 failures 0
sshd[1738]: debug1: user ec2-user does not match group list sftponly at line 142
sshd[1738]: debug1: PAM: initializing for "ec2-user"
sshd[1738]: debug1: PAM: setting PAM_RHOST to "..."
sshd[1738]: debug1: PAM: setting PAM_TTY to "ssh"
sshd[1739]: debug1: userauth-request for user ec2-user service ssh-connection method publickey
sshd[1739]: debug1: attempt 1 failures 0
sshd[1738]: debug1: temporarily_use_uid: 500/500 (e=0/0)
sshd[1738]: debug1: trying public key file /etc/ssh/keys/ec2-user
sshd[1738]: debug1: restore_uid: 0/0
sshd[1738]: debug1: temporarily_use_uid: 500/500 (e=0/0)
sshd[1738]: debug1: trying public key file /etc/ssh/keys/ec2-user
sshd[1738]: debug1: restore_uid: 0/0
sshd[1738]: Failed publickey for ec2-user from xx.xx.xx.xx port 60597 ssh2
sshd[1739]: Connection closed by xx.xx.xx.xx
sshd[1739]: debug1: do_cleanup
これは、ssh が有効なすべてのユーザーに同じエラーです。ログからわかるように、元のインスタンスの sshd_config を変更して、/etc/ssh/keys フォルダーで公開キーを検索するようにしました。
障害が発生したインスタンスを、動作中のインスタンスのボリュームとしてマウントしました。キーはフォルダー内にあり、権限とキー値はすべて予想どおり同じです。以下は、キー フォルダー (.) と ec2-user ファイルの ls -al です。
drwxr-xr-x. 2 root root 4096 Dec 1 16:59 .
-rw-------. 1 ec2-user ec2-user 388 Jul 25 13:27 ec2-user
この問題の原因は何でしょうか? スナップショットを保存して起動する時点、または元のインスタンスをセットアップする時点で問題を解決したいのですが、問題のあるインスタンスをマウントして手動で変更を加えることはせず、機能するようにしますが、より大きな問題は解決しません。
更新: sshd_config ファイル内のアクティブな設定は次のとおりです。
#...
Protocol 2
#...
SyslogFacility AUTHPRIV
LogLevel DEBUG
#...
AuthorizedKeysFile /etc/ssh/keys/%u
#...
PasswordAuthentication no
#...
ChallengeResponseAuthentication no
#...
GSSAPIAuthentication yes
#...
GSSAPICleanupCredentials yes
#...
UsePAM yes
#...
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
#...
X11Forwarding yes
#...
Subsystem sftp internal-sftp -f AUTH -l VERBOSE
#...
Match group sftponly
ChrootDirectory /home/%u
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp -l VERBOSE -f AUTH
#...
答え1
これは SELinux の問題だと思います。使用しているフォルダーのコンテキストを確認してください。キーを保持するには適切ではないと思われます。
残念ながら、コンテキストが正確に何であるかを確認するために Redhat ボックスにアクセスできなくなりました。とはいえ、これを試してください。
ls -lZ /root/.ssh
これにより、新しいフォルダに必要な selinux コンテキストが生成されます。正しく覚えていれば、system_u:system_r:sshd_t のような内容になるはずです。
次に、そのセキュリティ コンテキストを新しい承認済みキーの場所に適用する必要があります。
semanage fcontext -a -t system_u:system_r:sshd_t “/etc/ssh/keys(/.*)?”
正しいコンテキストを新しいキーの場所に関連付けます。最後に、コンテキストを新しい場所に適用します。
restorecon -Rv /etc/ssh/keys
答え2
sshd_config に 'AllowUsers' ディレクティブが設定されていますか? 元のサーバー上の特定のユーザーに設定されていて、ssh がまだ再起動されていないため、すべてのユーザーが受け入れられるのでしょうか?
ああ、デバッグでこれを見ました: 「ユーザー ec2-user は、行 142 のグループ リスト sftponly と一致しません」sshd_config を確認してください。グループを許可していないか、sftp のみを許可している可能性があります。