SSH の StrictModes、エージェント転送(ssh -A)、ssh -a を解説

結論:`StrictModes yes`(OpenSSH のデフォルト)にすると、sshd は鍵を受け入れる前にホームディレクトリ、`~/.ssh`、`~/.ssh/authorized_keys` の所有者とパーミッションを確認し、いずれかがグループや他者から書き込み可能だったり別のユーザーの所有だったりすると、「Authentication refused: bad ownership or modes」でログインを拒否します。チェックを無効にするのではなく、パーミッションを修正してください。`ssh -A` によるエージェント転送では、接続中にリモートホストがあなたのローカルの鍵を使えてしまうので、完全には信頼できないホストでは避け、代わりに `ssh -J`(ProxyJump)を使いましょう。小文字の `ssh -a` は、エージェント転送を明示的に無効にします。

このガイドはSSH 強化ガイドを補完するもので、Debian 12/13、Ubuntu 24.04、AlmaLinux 9 や Rocky 9 などの RHEL 系システムが対象です。

SSH の StrictModes がチェックするもの

StrictModes は `/etc/ssh/sshd_config` にあるサーバー側の設定です。目的はシンプルで、他のユーザーがあなたの `authorized_keys` に書き込めるなら、自分の鍵を追加してあなたとしてログインできてしまいます。そのため sshd は、パス全体が保護されていない限りそのファイルを信頼しません。ファイル自体と、ホームディレクトリを含むその上位のディレクトリをチェックします。

実際に有効な値は `sshd -T | grep -i strictmodes` で確認できます。Ubuntu 24.04 と Debian 13 では、`/etc/ssh/sshd_config.d/` 内のドロップインファイルも確認してください。

「Authentication refused: bad ownership or modes」を修正する

クライアントに表示されるのは汎用的な `Permission denied (publickey)` だけです。本当の理由はサーバーのログにあり、`Authentication refused: bad ownership or modes for directory /home/alice` や `... for file /home/alice/.ssh/authorized_keys` のように正確なパスが示されます。VPS のコンソールか別のセッションで修正しましょう。

1. 01.ログを読みます:Debian と Ubuntu では `journalctl -u ssh -n 50`、AlmaLinux と Rocky では `journalctl -u sshd -n 50`。
2. 02.ユーザーの SSH ディレクトリの所有者を修正します:`chown -R alice:alice /home/alice/.ssh`。
3. 03.モードを修正します:`chmod 700 /home/alice/.ssh` と `chmod 600 /home/alice/.ssh/authorized_keys`。
4. 04.ホームディレクトリからグループと全員の書き込み権限を外します:`chmod go-w /home/alice`。
5. 05.SELinux のシステム(AlmaLinux、Rocky、Fedora)では、ラベルを復元します:`restorecon -Rv /home/alice/.ssh`。
6. 06.動作中のセッションは開いたまま、新しいターミナルから `ssh -v alice@server` でテストします。

# all-in-one, run as root on the server
chown -R alice:alice /home/alice/.ssh
chmod go-w /home/alice
chmod 700 /home/alice/.ssh
chmod 600 /home/alice/.ssh/authorized_keys
namei -l /home/alice/.ssh/authorized_keys   # shows owner and mode of every path component

Note · エラーを消すために `StrictModes no` を設定しないでください。実際の保護がなくなり、設定ミスを直すのではなく隠すことになります。

StrictModes と StrictHostKeyChecking の違い

「ssh strictmode」の検索では、無関係な2つのオプションが混同されがちです。`StrictModes` はサーバーの `sshd_config` にあり、ファイルのパーミッションをチェックします。`StrictHostKeyChecking` はクライアントの `ssh_config` や `~/.ssh/config` にあり、サーバーのホスト鍵が未知の場合や変更された場合の挙動を制御します。クライアントにも独自のパーミッションチェックがあり、他のユーザーが読める秘密鍵は、保護されていない秘密鍵ファイルについての警告とともに使用を拒否されます。これは `chmod 600 ~/.ssh/id_ed25519` で修正できます。

ssh -A によるエージェント転送:そのリスク

`ssh -A`(または `ForwardAgent yes`)は、リモートホスト上に `$SSH_AUTH_SOCK` で参照されるソケットを作り、署名要求を手元のマシンの ssh-agent へ中継します。秘密鍵自体が手元のマシンを離れることはありませんが、そのソケットにアクセスできる者なら誰でも、接続中はあなたの鍵を使えます。リモートホスト上では、root やあなたのユーザーとして動くあらゆるプロセスがそれに含まれます。

サーバーが侵害されていたり、他人が管理していたりすると、攻撃者は Git ホスティングや本番サーバーを含め、あなたの鍵で開けるすべてのホストに気づかれずにログインできます。OpenSSH クライアントのデフォルトが `ForwardAgent no` なのはそのためです。

• ▹共有ホスト、第三者のホスト、まだ強化していない再インストール直後のホストには、エージェントを決して転送しないこと。
• ▹どうしても転送する場合は `ssh-add -c` を使い、鍵を使うたびにローカルでの確認を必須にしましょう。
• ▹OpenSSH 8.9 以降では `ssh-add -h` による接続先の制約に対応しており、転送した鍵を使えるホストを制限できます。
• ▹サーバー側では `sshd_config` の `AllowAgentForwarding no` で無効にできますが、シェルアクセスを持つユーザーは独自の転送手段を用意できてしまいます。

踏み台には ProxyJump(ssh -J)を使う

エージェント転送の多くは、踏み台(バスティオン)を経由して内部のマシンへ移動するために使われています。`ssh -J` ならエージェントを露出させずにこれを実現できます。踏み台は暗号化された TCP ストリームを転送するだけで、内部ホストへの認証はノート PC からエンドツーエンドで行われます。プライベートネットワーク経由でしか到達できないサーバーには、WireGuard トンネルという選択肢もあります。WireGuard VPN ガイドやWireGuard メッシュガイドを、keepalive と PSK の設定についてはWireGuard チューニングガイドを参照してください。

NoctisNode の VPS では KVM マシン上で SSH によるフル root 権限が得られるので、小さな Wisp プランを、他に何も動かさない専用の踏み台ホストとして使えます。VPS プランを参照してください。

# one-off
ssh -J [email protected] [email protected]

# ~/.ssh/config
Host bastion
    HostName bastion.example.com
    User alice
    ForwardAgent no

Host db1
    HostName 10.88.0.3
    User alice
    ProxyJump bastion

ssh -a(小文字)の働き

小文字の `ssh -a` は、その接続でのエージェント転送を無効にします。`-A` の逆です。`~/.ssh/config` でワイルドカードのホストに `ForwardAgent` を有効にしていて、特定の接続だけは確実に転送させたくない場合に便利です。例:`ssh -a admin@untrusted-host`。エージェントのソケットのパスを設定する `ssh-agent -a` や、エージェントに鍵を読み込む `ssh-add` と混同しないでください。

よくある質問