SSD Nodes Learn 🎉 VPS $5.50/月〜
ガイド Matt Connor著者 Matt Connor ・更新日 2026-08-13

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

SSHの「Permission denied (publickey)」は5種類の原因で起きます。ssh -vの3行を確認し、鍵の未送信やサーバー側の拒否を特定して、安全に修正する方法を解説します。

「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 image では通常 ubuntu アカウントが使われ、Debian の image では 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 に対してカウントします。MaxAuthTries のデフォルト値は 6 です。agent が 7 個の鍵を保持していると、正しい鍵に到達する前に上限へ達する可能性があります。その場合、メッセージは次のように変わります。

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

IdentitiesOnly=yes を指定すると、渡したファイルだけを試行します。agent が保持している鍵は ssh-add -l で一覧表示できます。古い鍵が何年分も蓄積している場合は、ssh-add -D で削除します。そのうえで設定を記録し、次回のログインでフラグを覚えておく必要がないようにします。

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 です。この場合、ホームディレクトリ内のファイルは完全に無視され、新しいパスに対して原因 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 つ目のコマンドは、公開鍵ファイルのフィンガープリントを出力します。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 します。これにより、すべての試行でサーバーが実際に受信した fingerprint がログに記録されます。

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

この行から、どちら側に問題があるかが分かります。認識できる fingerprint であれば、鍵はサーバーに到達していますが、サーバーに拒否されています。原因 3、4、5 を確認してください。認識できない fingerprint であれば、クライアントが意図していない鍵を送信しています。原因 2 に戻ってください。

ログを確認しても原因が分からない場合は、別のポートで 2 つ目の sshd を debug モードで起動します。これはフォアグラウンドで動作し、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 経由で接続すると、テストからファイアウォールを除外できます。debug 出力には、開いたファイル、照合した fingerprint、正確な拒否理由が表示されます。Authentication refused: bad ownership or modes for directory /home/deploy のような行も含まれます。原因が分かったら Ctrl+C を押してください。ポート 22 の実際の sshd には、テスト中ずっと影響しません。

自分自身を締め出さない方法

サーバー設定を編集するすべての手順では、SSH に依存しない復旧経路が必要です。SSH がまだ機能している間に準備してください。接続できなくなってからでは間に合いません。

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

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

同じ key が別のサーバーで機能するのに、なぜ Permission denied (publickey) になりますか？

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

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

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

なぜ sshd は authorized_keys file を無視するのですか？

StrictModes はデフォルトで有効であり、file、.ssh directory、または home directory が group または world から書き込み可能であるか、誤った account に所有されています。sshd は他者が変更できるパスを信頼しないため、key が存在しない場合と同じように動作します。home directory を 755 以下に設定し、.ssh を 700 に、authorized_keys を 600 に設定します。3 つすべてを login account の所有にします。LogLevel VERBOSE を使用すると、サーバーは Authentication refused: bad ownership or modes for directory /home/deploy/.ssh を記録します。

サーバーの upgrade 直後に key が機能しなくなりました。何が変わったのですか？

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

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

SSH を経由しない provider の console を使用します。そこで local password でログインし、sudo sshd -t を実行して syntax error と行番号を確認します。変更を元に戻して service を restart します。その後、sudo sshd -T を確認して実行中の値を確認します。/etc/ssh/sshd_config.d/ 内の file が main config を上書きしている可能性があるためです。local password がない場合は、まず console から root password を reset し、その後 file を修正します。

#ssh#openssh#troubleshooting#permissions#vps