SSH接続でPermission denied (publickey)について調べていると、「~/.sshは700」「authorized_keysは600」という情報をよく見かけました。しかし、なぜ600なのか、700ではないといけないのかまでは説明されていない記事が多かったため、OpenSSHの仕様やLinuxの権限を調べてみました。
なぜ ~/.ssh は700なのか
~/.sshの権限として一般的に700(drwx——)が推奨されています。これはユーザーのみに読み込み、書き込み、実行が許可されているという設定です。
以下のコマンドで実際に~/.sshの中身を確認してみたところ、authorized_keysやknown_hostsなどそのユーザー専用のSSH設定や鍵が保存されていることがわかりました。
ls -la ~/.sshつまりこの情報を他人に見られたり変更されたりすると危険であるため、ユーザーにのみ権限を認めているということになります。
ちなみに、後述のauthorized_keysが6(-rw——-)なのに対して、なぜ.sshは7(drwx——)なのかというと、.sshは先頭の”d”を見ても分かるようにディレクトリです。
ディレクトリの中身を確認するには実行権が必要になります。もし、実行権がないと中身が確認できずauthorized_keysなどを確認できないため、公開鍵認証が行えなくなってしまうということです。
なぜauthorized_keysは600なのか
authorized_keysは一般的に600(-rw——-)が推奨されています。
authorized_keys自体は公開鍵を保存するファイルですが、第三者によって内容を書き換えられると、攻撃者の公開鍵を登録され不正ログインにつながる可能性があります。
そして、authorized_keysはディレクトリではないため実行権を与える必要がありません。
このように、公開鍵認証をするために必要最低限の権限を与えた場合、authorized_keysは600、.sshは700となっているようで、デフォルトでもこの設定になっていました。
検証１：権限を緩和
では、ユーザー以外にも権限を与えているとどのように認証がされるのかを試してみたいと思います。
まずは以下のコマンドで権限を変更します。
chmod 777 ~/.sshそして、そのままSSH接続を試みます。
ssh user@IPアドレスするとなぜかパスワード認証が求められました。
user@IPアドレス's password:パスワードを入力するとSSH接続ができました。一度ログアウトして何が起きているのかを確認するため以下のコマンドをクライアント側(Shell)で実行しました。
ssh -v penguin@192.168.56.101表示されたログを見てみると、気になるものがありました。
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: ~/.ssh/id_ed25519_sk
debug1: Trying private key: ~/.ssh/id_xmss
debug1: Trying private key: ~/.ssh/id_dsa
debug1: Next authentication method: passwordまず初めに「Authentications that can continue: publickey,password」というログから、公開鍵認証とパスワード認証が利用できることが示されています。
しかしその後、「Trying private key…」と3回認証を試みていますが、次のログでは「Next authentication method: password」というようにパスワード認証に切り替わっていることがわかります。
検証結果として権限を緩くしすぎると公開鍵認証が拒否されることがわかりますが、そのことについて明言されているというわけではなく、パスワード認証に即座に切り替わるということがわかりました。
ちなみにですが、パスワード認証自体をオフにした状態で実行してみると以下のようにアクセスが
拒否されました。
debug1: No more authentication methods to try.
user@IPアドレス: Permission denied (publickey).検証１：権限を強化
次は逆に権限をより厳格にしてみました。
chmod 400 ~/.ssh結論から申し上げると、先ほどと同じでした。.sshを開くには実行権が必要ということだったので、今回の場合は予想通りでした。
では、700以外に公開鍵認証が可能な権限はあるのでしょうか？
今回の検証環境では、.sshは700以外では公開鍵認証に成功しませんでした。
しかし、authorized_keysの権限については結果が異なりました。
検証：authorized_keysの場合
いろいろな権限で公開鍵認証を試し、ある法則があることに気が付きました。
まず、認証が成功した権限は以下の通りでした。
700 600 400 610 620 640 660 701 704 604 601そして、認証失敗したパターンは以下の通りでした。
702 602 706 606まず、前提として権限は左からuser（ユーザー）、group（グループ）、others（その他）になります。
ユーザーについてはデフォルトは6ですが検証結果から7でも4でも認証できましたが、2や1では認証失敗しました。
そして、グループについてはどの権限でもあまり影響がありませんでしたが、その他については2と6と7の場合に認証失敗しました。
それ以外の場合については認証が成功しましたので、others（その他）については2(書き込み権)が含まれていると認証ができないことが分かりました。
OpenSSH公式ドキュメント
~/.sshやauthorized_keysの権限についてOpenSSHのマニュアルページを確認したところ、以下のような記述がありました。
If this file, the ~/.ssh directory, or the user’s home directory are writable by other users, then the file could be modified or replaced by unauthorized users. In this case, sshd will not allow it to be used unless the StrictModes option has been set to “no”.
出典：OpenSSH Manual Pages sshd(8) ~/.ssh/authorized_keys
つまり、書き込み権が他のユーザーに認められると、改ざんされる恐れがあるのでStrictModesをオフにしない限り通常認めていないということです。
StrictModesについては以下のような記述がありました。
Specifies whether sshd(8) should check file modes and ownership of the user’s files and home directory before accepting login. This is normally desirable because novices sometimes accidentally leave their directory or files world-writable. The default is
yes. Note that this does not apply toChrootDirectory, whose permissions and ownership are checked unconditionally.
出典：OpenSSH Manual Pages sshd_config(8) StrictModes
内容としては、このStrictModesという設定が権限をチェックするかどうかの役割を果たしているので、StrictModesをno(オフ)にすると、公開鍵認証時に行われるユーザー関連ファイルの権限・所有者チェックが無効になります。
実際にStrictModesをオフにして権限を変更してみました。
StrictModes noすると、000などユーザー自体にも権限を制限するものはこれまで通り認証に失敗しましたが、777など権限を緩和する設定では認証に成功しました。
まとめ
今回はSSHの公開鍵認証についてなぜauthorized_keysは600、.sshは700なのかについて説明・検証をしました。
結論として、ユーザー以外に書き込み権などを与えると、データの改ざんのおそれや不正アクセス等の原因となるため基本的にはユーザーにのみ権限が認められています。
そして、権限のチェックは設定ファイル上のStrictModesという項目によって行われているため、これをオフにした場合は他のユーザーにも認証ができてしまうということも分かりました。
セキュリティの観点からはこの設定はデフォルトのオンから変更しるべきではないかと思われます。