SSHのPermission denied (publickey)を解決する方法

「Permission denied (publickey)」の実際の意味

「Permission denied (publickey)」は、クライアントが 1 つ以上の公開鍵を送信したものの、サーバーがどれも受け入れなかったことを示します。ネットワークは正常で、sshd も稼働しています。拒否が発生したのは、認証の最後の段階です。それより前にセッションが切断される場合は、接続拒否または接続タイムアウトを調べてください。これは別の診断であり、確認すべき項目も異なります。推測で修正する必要はありません。ssh -v により、5 つの原因のどれに該当するかが分かります。

括弧内の語は、サーバーが受け入れ可能な認証方式です。Permission denied (publickey) だけが表示される場合、そのサーバーではパスワードログインが無効になっているため、パスワードに切り替えることはできません。Permission denied (publickey,password) は、パスワードが提示されたものの、それでも認証に失敗したことを示します。

この 1 つのメッセージは、5 つの異なる障害を表します。意図的に具体性が抑えられています。サーバーが「そのユーザーは存在しない」や「その鍵はインストールされていない」と返すと、有効なアカウントを探している人に手掛かりを与えてしまうためです。したがって、最初から鍵を入れ替えたり、設定ファイルを編集したりしないでください。1 つのコマンドを実行して、出力の 3 行を確認すれば、5 つの可能性を 1 つに絞り込めます。

まず ssh -v を実行し、3 行を確認する

失敗したコマンドに -v を追加して再実行します。

ssh -v deploy@203.0.113.10

実際の実行結果は、次のようになります。

OpenSSH_9.6p1 Ubuntu-3ubuntu13, OpenSSL 3.0.13 30 Jan 2024
debug1: Connecting to 203.0.113.10 [203.0.113.10] port 22.
debug1: Connection established.
debug1: Authenticating to 203.0.113.10:22 as 'deploy'
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Will attempt key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Offering public key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
deploy@203.0.113.10: Permission denied (publickey).

必要な情報は、3 行にすべて含まれています。

Authenticating to 203.0.113.10:22 as 'deploy' は、実際に使用されるユーザー名です。使用するつもりだった名前ではありません。コマンドライン、~/.ssh/config、またはローカルのログイン名から ssh が決定した名前です。

Authentications that can continue: publickey は、鍵の試行前にサーバーが送信する、受け入れ可能な方式の一覧です。最初の一覧に publickey がない場合、サーバーでは公開鍵ログインが無効になっているため、どの鍵も機能しません。

Offering public key: ... は、クライアントが実際に送信した各鍵について 1 行ずつ表示され、鍵の取得元ファイルと SHA256 フィンガープリントを示します。Offering の行がない鍵は、サーバーに送信されていません。

次の 2 つに分けて問題を切り分けます。

• 期待する鍵の Offering public key 行がない。サーバーは鍵をまったく受信していないため、問題はクライアント側にあります。
• 鍵が提示され、再び Authentications that can continue: publickey が返される。サーバーはその鍵を受信したうえで拒否しているため、問題はサーバー側にあります。

以下の原因は、実際に該当する頻度が高い順に並べています。

原因 1: 接続時のユーザー名が正しくない

最も一般的な原因は、最も単純なものでもあります。SSH（Secure Shell）サーバーデーモンである sshd は、アカウントが存在しないことを通知しません。攻撃者に有効なアカウント名を推測される手掛かりを与えないため、存在しないユーザー名でも一連の認証処理を最後まで実行し、同じメッセージを返して拒否します。ユーザー名の入力ミスは、鍵の破損とまったく同じように見えます。

他の確認をする前に、Authenticating to ... as 行を確認します。そこにサーバーのアカウントではなく、ノートパソコンのログイン名が表示されている場合は、コマンドでユーザー名を指定していません。

ssh -v deploy@203.0.113.10
ssh -v root@203.0.113.10

デフォルトのアカウントは、プロバイダーが構築したイメージによって異なります。2026 年 8 月現在、Ubuntu の cloud イメージでは通常 ubuntu アカウント、Debian イメージでは debian または admin、Rocky Linux と AlmaLinux では rocky と almalinux が使われます。一方、多くの VPS プロバイダーでは、鍵を root に直接登録します。作成されたアカウントは、プロバイダーのコントロールパネルで確認できます。サーバーの外部から実行するコマンドで、その情報を問い合わせることはできません。

~/.ssh/config の Host ブロックでもユーザー名を設定できます。この設定は、ローカルのログイン名より優先されます。

Host vps-prod
  HostName 203.0.113.10
  User deploy

自分でアカウントを作成した後、そのアカウントでログインできない場合は、イメージのデフォルトユーザー用に鍵が登録されていて、新しいアカウントにはコピーされていない可能性があります。この作業は新しい VPS の最初の 10 分間に行うもので、簡単に抜け落ちます。

原因 2: 送信していると思っている鍵が、実際に送信されている鍵ではない

デフォルトでは、ssh は ssh-agent が保持している鍵と、~/.ssh にある固定のファイル名だけを提示します。対象は id_ed25519、id_ecdsa、id_rsa およびそれらのハードウェア版と DSA 版です。~/.ssh/vps-prod として保存した鍵は、明示的に指定するまで ssh から見えません。そのため、詳細出力に Offering public key 行が表示されません。

ファイルを指定し、agent の鍵が代わりに使われないようにします。

ssh -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@203.0.113.10

agent が鍵を保持している場合、-i だけでは不十分です。ssh は引き続き agent の鍵を先に提示し、指定したファイルを最後に提示するためです。サーバーは拒否された鍵をすべて MaxAuthTries に対して数えます。デフォルト値は 6 です。agent が 7 個の鍵を保持していると、正しい鍵に到達する前に上限を使い切ることがあります。その場合、メッセージは次のように変わります。

Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures

そのメッセージが表示される場合、正しい key に到達する前にサーバーがセッションを切断しています。これは 認証試行回数が多すぎる場合で説明している問題です。IdentitiesOnly=yes は、指定したファイルだけを試すよう制限します。ssh-add -l で agent が保持している内容を一覧表示し、古い key が何年分も蓄積している場合は ssh-add -D で削除します。次回のログインで flag を覚えておく必要がないよう、設定を記述しておきます。

Host vps-prod
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/vps-prod
  IdentitiesOnly yes

クライアント側には、もう 1 つ注意点があります。自分のマシン上にある別のアカウントから読み取れる秘密鍵を、ssh は使用しません。警告を表示して鍵を無視するため、鍵は提示されず、サーバーにも届きません。

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/you/.ssh/vps-prod' are too open.

chmod 600 ~/.ssh/vps-prod で修正できます。USB メモリや Windows 共有を経由して鍵を移動すると、通常はモードが失われます。鍵の保存場所と名前の付け方については、SSH 鍵管理の基本 で説明しています。

原因 3: 公開鍵が authorized_keys に届いていない

ssh -v で鍵が送信されているのにサーバーが拒否する場合、次に確認するのは、その鍵がアカウントの authorized_keys ファイルに存在するかどうかです。SSH ではログインできないため、プロバイダーのコンソールを開いて確認します。

sudo ls -l /home/deploy/.ssh/
sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys

authorized_keys ファイルに対して ssh-keygen -lf を実行すると、エントリごとに1つのフィンガープリントが表示されます。

256 SHA256:0eL/8sBw... you@laptop (ED25519)
3072 SHA256:9Tq2yZk... old-laptop (RSA)

これらを Offering public key 行に表示されるフィンガープリントと比較します。リストに存在しない場合、記憶している操作にかかわらず、そのアカウントには鍵が登録されていません。

よくある原因は次の4つです。

• .pub ファイルではなく、秘密鍵を貼り付けた。公開鍵の行は ssh-ed25519 または ssh-rsa で始まります。秘密鍵は -----BEGIN OPENSSH PRIVATE KEY----- で始まります。
• 貼り付けた内容が複数行に折り返された。各エントリは必ず1行に収める必要があります。折り返された鍵は複数の壊れたエントリとして解釈され、どの鍵とも一致しません。
• deploy としてログインしているのに、鍵を /root/.ssh/authorized_keys に追加した。またはその逆です。このファイルはアカウントごとに存在し、共有されません。
• プロバイダーの「鍵を追加」ボックスが、イメージのデフォルトユーザーにだけ鍵を書き込んだ。そのため、後から作成したアカウントの .ssh ディレクトリは空になっています。

コンソールから root として鍵を追加する安全な方法は次のとおりです。

sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo tee -a /home/deploy/.ssh/authorized_keys >/dev/null <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKeyDataHere you@laptop
EOF
sudo chown deploy:deploy /home/deploy/.ssh/authorized_keys
sudo chmod 600 /home/deploy/.ssh/authorized_keys

その後、もう一度 sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys を実行します。新しいフィンガープリントがリストに表示されるはずです。パスワードでログインできるマシンから実行する場合は、ssh-copy-id -i ~/.ssh/vps-prod.pub deploy@203.0.113.10 でも同じ処理が行われ、適切なモードが設定されます。

原因 4: 権限が過度に開かれていると sshd が authorized_keys を無視する理由

StrictModes yes は sshd のデフォルト設定です。この設定では、.ssh ディレクトリ、アカウントのホームディレクトリ、またはそのファイルを所有者以外のユーザーが書き込み可能な場合、sshd は authorized_keys の読み取りを拒否します。理由は明確です。ホームディレクトリをグループまたはその他のユーザーが書き込み可能だと、その権限を持つアカウントが authorized_keys を置き換え、ログインを乗っ取れるためです。sshd は、信頼できないパスを、鍵が存在しない場合と同じように扱います。

クライアントには、単に Permission denied と表示されます。サーバーログには実際の理由が記録されます。

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh

ファイル自体に問題がある場合は、次のように記録されます。

Authentication refused: bad ownership or modes for file /home/deploy/.ssh/authorized_keys

sshd が許可する状態:

• ホームディレクトリ: グループ書き込み可能でも、その他のユーザーが書き込み可能でもないこと。755、750、700 はすべて通過します。775 と 777 は失敗します。
• ~/.ssh: モード 700。
• ~/.ssh/authorized_keys: モード 600。
• 所有者: 3 つすべてが、root ではなくログインするアカウントに所有されていること。

所有者はモードと同じくらい重要です。/home/deploy/.ssh 内のファイルが root に所有されている場合も、同じチェックで失敗します。これは、sudo nano でファイルを作成した後、所有者を戻し忘れた場合に発生します。次のコマンドで両方を同時に修正します。

sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys
sudo chmod go-w /home/deploy
ls -ld /home/deploy /home/deploy/.ssh

最後のコマンドで結果を確認できます。ホームディレクトリは drwxr-xr-x 以上に制限し、.ssh は drwx------ にします。これらの文字列の意味がまだ明確でない場合は、稼働中のサーバーでモードを変更する前に、drwxr-xr-x のような権限文字列の読み方を確認してください。

Rocky Linux と AlmaLinux では、確認対象に SELinux (security-enhanced Linux) も含めます。通常とは異なる方法で作成した .ssh ディレクトリには、誤ったファイルラベルが付いていることがあります。その場合、モードが正しく見えても sshd による読み取りアクセスが拒否されます。sudo restorecon -Rv /home/deploy/.ssh でラベルを復元し、sudo ausearch -m avc -ts recent で拒否したコンポーネントが SELinux かどうかを確認できます。

原因 5: sshd が接続を拒否する設定になっています

現在の Ubuntu または Debian システムでは、/etc/ssh/sshd_config を読むだけでは不十分です。このファイルは Include /etc/ssh/sshd_config.d/*.conf で始まっており、OpenSSH は各設定について最初に見つかった値を使用します。そのため、50-cloud-init.conf のような drop-in ファイルが先に読み込まれ、メインファイルの下部で編集した内容より優先されます。編集内容が正しく見えるのに、まったく反映されないのはこのためです。

sshd が実際に使用している設定を確認します。

sudo sshd -T | grep -Ei 'pubkeyauth|authorizedkeysfile|permitrootlogin|allowusers|allowgroups|denyusers'

正常な出力は次のようになります。

permitrootlogin prohibit-password
pubkeyauthentication yes
authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2

自分の出力で確認する項目は次のとおりです。

• pubkeyauthentication no。鍵は一切受け付けられません。これは ssh -v に、publickey を含まない最初の Authentications that can continue: リストとしても現れます。
• authorizedkeysfile が別の場所を指している。たとえば /etc/ssh/authorized_keys/%u です。この場合、ホームディレクトリ内のファイルは完全に無視され、cause 4 のモード規則が新しいパスに適用されます。
• allowusers または allowgroups が存在する。リストにないアカウントは、このエラーだけを返して拒否されます。denyusers と denygroups は逆の動作をします。
• root としてログインしようとしているときに permitrootlogin no になっている。prohibit-password は実用的な中間設定です。root は鍵を使用できますが、パスワードは使用できません。

Match ブロックは、単純な sshd -T には表示されません。接続元によって結果が変わるためです。特定の接続について確認します。

sudo sshd -T -C user=deploy,host=vps.example.com,addr=198.51.100.7

古い鍵に影響する設定もあります。OpenSSH 8.8 では、デフォルトで SHA-1 署名（ssh-rsa）の受け入れが停止されました。そのため、何年も使えていた RSA 鍵が、サーバーのアップグレード直後に使えなくなることがあります。クライアントは原因を明確に表示します。

debug1: send_pubkey_test: no mutual signature algorithm

正しい対処は新しい鍵を作成することです。ssh-keygen -t ed25519 -C "deploy@vps-prod" を実行し、その後、上記の手順で .pub ファイルをインストールします。サーバーで PubkeyAcceptedAlgorithms +ssh-rsa を設定すると古い署名が再び有効になり、当面はログインできるようになります。ただし、これはサーバーに接続するための一時的な手段であり、対処の完了ではありません。確認すべきその他のサーバー側設定については、VPS 上の SSH サーバーを強化する を参照してください。

秘密鍵がインストール済みの公開鍵と一致することを確認する方法

このエラーで推測が必要になる主な原因は、2 つのファイルが対になっているか分からないことです。次のコマンドで確認できます。

ssh-keygen -y -f ~/.ssh/vps-prod

このコマンドは、秘密鍵から導出した公開鍵を出力します。隣にある .pub ファイルは読み取らないため、古い .pub ファイルの内容ではなく、秘密鍵の実際の内容を確認できます。鍵にパスフレーズが設定されている場合、コマンドはパスフレーズを要求します。これにより、現在もパスフレーズを把握していることも確認できます。

ssh-keygen -lf ~/.ssh/vps-prod.pub
ssh-add -l

1 つ目のコマンドは、1 つの公開鍵ファイルのフィンガープリントを出力します。2 つ目は、agent が保持している鍵のフィンガープリントを出力します。ssh -v の Offering public key 行にあるフィンガープリント、.pub ファイルのフィンガープリント、サーバーの authorized_keys にある ssh-keygen -lf のフィンガープリント、サーバーログのフィンガープリントという、同じ文字列に対する 4 つの表示を照合します。一致しなくなる箇所が、問題の原因です。

ログインに失敗する間、サーバーログを確認する

クライアントには、意図的に有用な情報が返されません。実際の理由はサーバーがログに記録します。コンソールセッションでログの追跡を開始し、その後、ノートPCから失敗する ssh コマンドを実行します。

sudo journalctl -u ssh -f

Ubuntu 24.04 では rsyslog はデフォルトでインストールされないため、/var/log/auth.log は存在しない場合があります。Rocky Linux と AlmaLinux では unit 名が sshd で、同じ記録が /var/log/secure にも保存されます。

sshd の設定で LogLevel VERBOSE を指定し、サービスを reload します。これにより、各試行でサーバーが実際に受信した鍵のフィンガープリントがログに記録されます。

Failed publickey for deploy from 198.51.100.7 port 49812 ssh2: ED25519 SHA256:0eL/8sBw...

この行から、問題がどちら側にあるかを判断できます。見覚えのあるフィンガープリントなら、鍵はサーバーに届いていますが、サーバーに拒否されています。その場合は原因 3、4、5 を確認します。見覚えのないフィンガープリントなら、クライアントが意図していない鍵を送信しています。その場合は原因 2 に戻ります。

ログを見ても原因が明確でない場合は、別のポートで sshd をデバッグモードで起動します。フォアグラウンドで動作し、1 件の接続を処理し、判断内容を出力して終了します。

sudo /usr/sbin/sshd -ddd -p 2222

同じサーバーのコンソールセッションから、loopback アドレス経由で接続します。

ssh -p 2222 -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@127.0.0.1

127.0.0.1 経由で接続すると、ファイアウォールをテスト対象から外せます。デバッグ出力には、開いたファイル、照合したフィンガープリント、拒否の正確な理由が表示されます。Authentication refused: bad ownership or modes for directory /home/deploy のような行も含まれます。原因が分かったら Ctrl+C を押してください。ポート 22 の実際の sshd には、終始影響しません。

自分を締め出さない方法

サーバー設定を変更するすべての手順では、SSH に依存しない復旧経路が必要です。SSH がまだ使える間に準備してください。障害が発生してからでは遅すぎます。

1. プロバイダーのコンソールを開き、シリアル接続または VNC (virtual network computing) 経由でアクセスし、そこでログインできることを確認します。
2. sudo が可能なアカウントの、使用できるローカルパスワードを把握していることを確認します。持っていない場合は、まず プロバイダーのコンソールから root パスワードをリセットする を実行します。
3. 現在の SSH セッションを開いたままにします。開いているセッションは systemctl restart ssh の影響を受けないため、新しい設定に誤りがあっても復旧経路として利用できます。
4. 再起動する前に構文を確認します。sudo sshd -t はファイルが有効な場合は何も出力せず、無効な場合はファイル名と行番号を出力します。
5. 最初の端末を閉じる前に、2 つ目の端末を開いて新しいセッションでログインします。設定に誤りがあると新しいログインは停止しますが、既存のセッションは維持されます。そのため、現在使用中のセッションだけでは変更が機能したかどうかを確認できません。

Debian と Ubuntu では sudo systemctl restart ssh、Rocky Linux と AlmaLinux では sudo systemctl restart sshd を使用して再起動します。Ubuntu 24.04 では sshd が socket unit から起動されるため、Port または ListenAddress を変更した場合は、反映前に sudo systemctl restart ssh.socket も実行する必要があります。

FAQ

同じ鍵が別のサーバーでは使えるのに、なぜ Permission denied (publickey) になるのですか？

鍵自体に問題はなく、周辺の設定などに問題があります。ssh -v を実行し、Offering public key の行を探します。鍵が一覧にない場合、ssh はその鍵を送信していません。ファイルが ~/.ssh にデフォルト名で存在せず、agent にも読み込まれていないため、-i /path/to/key -o IdentitiesOnly=yes を追加します。鍵が一覧にあり、それでもサーバーが拒否する場合は、その鍵がアカウントの authorized_keys にないか、鍵までのパスが group-writable であるか、sshd の設定がユーザーを拒否しています。サーバーログで原因を切り分けられます。

SSH が実際に送信している鍵を確認するにはどうすればよいですか？

ssh -v host は鍵ごとに debug1: Offering public key: の行を出力します。各行には、元のファイルと SHA256 fingerprint が表示されます。ssh-add -l は agent が保持する fingerprint を一覧表示します。ssh-keygen -lf ~/.ssh/id_ed25519.pub は単一の鍵ファイルの fingerprint を表示し、ssh-keygen -y -f ~/.ssh/id_ed25519 は秘密鍵から実際に導出される公開鍵を表示します。ログインを成功させるには、Offering の行に表示された fingerprint が、サーバーの authorized_keys に対して実行した ssh-keygen -lf の出力にも存在している必要があります。

なぜ sshd は authorized_keys ファイルを無視するのですか？

StrictModes はデフォルトで有効です。また、ファイル、.ssh ディレクトリ、または home directory が group または world によって書き込み可能であるか、誤ったアカウントが所有しています。sshd は他のユーザーが変更できるパスを信頼しないため、鍵が存在しない場合と同じように動作します。home directory の権限を 755 以下にし、.ssh を 700 に、authorized_keys を 600 に設定します。3 つすべてをログインアカウントの所有にします。LogLevel VERBOSE により、サーバーは Authentication refused: bad ownership or modes for directory /home/deploy/.ssh を記録します。

サーバーをアップグレードした直後に鍵が使えなくなりました。何が変わったのですか？

RSA 鍵の場合、SHA-1 の変更が原因である可能性が高いです。OpenSSH 8.8 では、ssh-rsa SHA-1 署名がデフォルトで無効になりました。その方式でしか署名できない鍵は、拒否されます。詳細なクライアント出力に debug1: send_pubkey_test: no mutual signature algorithm が表示されます。ssh-keygen -t ed25519 で新しい鍵を生成し、その .pub ファイルをインストールします。すぐにアクセスする必要がある場合は、サーバーで PubkeyAcceptedAlgorithms +ssh-rsa を設定すると古い署名を再び有効にできます。新しい鍵が使えることを確認したら、その行を削除してください。

sshd_config を編集した後、まったくログインできなくなりました。どうすれば復旧できますか？

SSH を経由しないプロバイダーのコンソールを使用します。そこで local password でログインし、sudo sshd -t を実行して構文エラーと行番号を確認します。変更を元に戻して、サービスを再起動します。次に sudo sshd -T を確認して、実行中の値を確認します。/etc/ssh/sshd_config.d/ 内のファイルがメイン設定を上書きしている可能性があるためです。local password がない場合は、まずコンソールから root password をリセットしてから、ファイルを修正します。