☰

更新: 修正できましたが、なぜ発生したのかは不明です

tag-icon • tag-icon permissions sshd
更新: 修正できましたが、なぜ発生したのかは不明です

背景

RAS キー経由の SSH アクセスが可能なサーバーをセットアップしています。パスワード アクセスは許可されていません。

正常に動作していました。ユーザー (ここでは USER1 と呼びます) と root は、それぞれのキーを使用してログインできました。

問題を引き起こす可能性のある変更

昨日、指示に従ってサーバーにいくつかの変更を加えました記事上で、新しいユーザー（USER2）に1つのフォルダ（Webルート）への限定的なアクセスを許可するために、私はまた、この記事。

これらの変更をまとめると、新しいユーザー (USER2) を作成し、bindfsWeb ルート ( /home/user1/sites/domain/public/) を にしました/home/user2/domain/public/。これらの記事に従って、他にもいくつかの操作を実行しましたが、私が知る限り、それらのどれも USER1 の権限と SSH アクセスには影響しません。そのため、ここですべてを繰り返すことはしません。

それらの記事の 1 つに従って、次の内容もファイルに追加しましたsshd_config。

subsystem sftp internal-sftp
Match User USER2
ChrootDirectory %h
AllowTCPForwarding no
X11Forwarding no
ForceCommand internal-sftp

私の知る限り、USER1 で最後にログインしてから変更されたのはこれだけです。

問題

上記の変更を行った後、翌日（本日）ログインできなくなりました。エラーが発生しますPermission denied (publickey).。

~/home/USER1/.sshフォルダーとファイルの適切な権限と所有権を設定するために、すべての標準的な推奨事項に従いました~/home/USER1/.ssh/authorized_keys。ただし、昨日の私の操作によってそれらのどれも変更されなかったので、基本的には既存の権限を再適用しただけです。

/etc/ssh/sshd_config私のファイルの内容は次のとおりです:

Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 1024
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes

AuthorizedKeysFile  %h/.ssh/authorized_keys
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
PasswordAuthentication no
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
UsePAM yes
Subsystem sftp /usr/lib/openssh/sftp-server

Match User USER2
PasswordAuthentication yes
ChrootDirectory %h
AllowTCPForwarding no
X11Forwarding no
ForceCommand internal-sftp

AuthorizedKeysFile %h/.ssh/authorized_keys以前はコメントアウトされていました。この問題を修正しようとしてコメントを解除しました。

USER1 がキーベースの SSH アクセスを行えない原因がわかりません。さらに役立つ情報があれば、お知らせください。

更新: 修正できましたが、なぜ発生したのかは不明です

すべての権限が正しいこと、およびファイルに異常がないことを二重に確認した後sshd-config、パスワード ログインを許可するように ssh を設定し、id_rsa.pub ファイルを ( を使用ssh-copy-id) サーバーに再コピーしました。

これにより、キーを使用して USER1 のアクセスが復元されました。

この問題がなぜ発生したのかは完全には理解していません。また、これらの記事の手順を他のサーバーでも使用することを計画しています (開発者 (例) に Web サイトへの厳格な SFTP アクセス (のみ) を許可し、ファイルの変更権限を与えるのに非常に便利な方法であることが証明されているため)。そのため、手順のどこに誤りがあったのかを指摘できる方がいらっしゃいましたら、ぜひご指摘ください。

それらの記事を読まなくても済むように、私が実行した手順を以下に説明します。

mkdir -p /home/user2/websites/application1
chown -Rf user2:user2 /home/user2/websites
chmod -Rf 770 /home/user2/websites

以下を追加/etc/fstab

bindfs#/home/user1/websites/domain/public /home/user2/websites/application1 fuse force-user=user2,force-group=user2,create-for-user=user1,create-for-group=user1,create-with-perms=0770,chgrp-ignore,chown-ignore,chmod-ignore 0 0

chown user1:user1 /home/user1/websites/domain/public
chmod 770 /home/user1/websites/domain/public

新しいユーザーを作成しました:

sudo useradd -d /home/user2/website/application1 user2
sudo passwd user2

sshd-configに追加

subsystem sftp internal-sftp
Match User user2
ChrootDirectory %h
AllowTCPForwarding no
X11Forwarding no
ForceCommand internal-sftp

それから、sudo service ssh restart

質問

そこで私の質問を修正すると、上記の手順で、user1そのキーを使用して SSH アクセスを行った結果何が起こったのでしょうか?

関連情報