SSH「Permission denied (publickey)」: 直し方

「Permission denied (publickey)」の意味

このエラーは、サーバーがあなたの認証を拒否したことを意味します ── ネットワーク接続は成功しましたが、クライアントが提示したどの資格情報もサーバーが受け付けなかったのです。括弧内に (publickey) とある場合、サーバーは鍵認証のみを許可しており、あなたの鍵がどれも一致しなかったということです。原因はほぼ必ず次の 5 つのいずれかです:ユーザー名が間違っている、鍵が間違っている/存在しない、公開鍵がサーバーにない、~/.ssh の権限が誤っている、またはサーバーがあなたの認証方式を許可していない。どれが原因かを数分で突き止める方法を説明します。

可能性の高い順に 5 つの原因

1 — まずユーザー名を確認

最も多い原因、特にクラウドサーバーで:各イメージには独自のデフォルトユーザーがあります ── ubuntu(Ubuntu)、ec2-user(Amazon Linux)、root(多くの VPS イメージ)、pi(古い Raspberry Pi OS)、debian、admin……。ユーザー名が間違っていると、サーバーは鍵を検討する前にあなたを拒否し、エラーは見た目がまったく同じになります。

2 — 正しい鍵が提示されているか確認

デスクトップでは、ssh -v user@host がクライアントの試した鍵を表示します(「Offering public key…」)。モバイルクライアントでは、接続設定を開き、この接続に実際に鍵が添付されているか確認してください ── 「パスワードで」作成した接続は鍵をまったく提示しません。TermAI では、接続を編集して認証をあなたの鍵に切り替えます。

3 — 公開鍵をサーバーにインストール

サーバーは、あなたがログインするユーザーの ~/.ssh/authorized_keys に列挙された鍵のみを受け付けます。別の方法(パスワード、コンソール)でまだログインできるなら:

# from a machine that can log in:
ssh-copy-id user@host
# or manually append your public key:
cat your_key.pub >> ~/.ssh/authorized_keys

スマホからなら、TermAI が代行できます:Ed25519 鍵を生成し、ワンタップのサーバーへデプロイで、既存の有効なログインを通じて公開鍵を authorized_keys に書き込みます。注意:鍵は特定のユーザーのホーム配下に入ります ── root 用にインストールしても、ubuntu としてログインする役には立ちません。

4 — サーバー側の権限を修正

ファイルやディレクトリの権限が開放されすぎていると、OpenSSH は authorized_keys を黙って無視します。サーバーで:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

ホームディレクトリ自体がグループ/全員書き込み可能になっていないかも確認してください。これが「鍵をインストールしたのにまだ失敗する」という典型的な原因です ── サーバーの /var/log/auth.log を確認すると、「Authentication refused: bad ownership or modes」と記録されています。

5 — サーバーが何を許可しているか確認

/etc/ssh/sshd_config 内:もし PasswordAuthentication no で鍵がインストールされていなければ、失敗する道に閉じ込められています;もし PermitRootLogin no で root を試しているなら、それが拒否の原因です。設定を修正する(または正しいユーザーを使う)、それから sudo systemctl restart ssh。root ログインを安全に無効化するを参照。

スマホからこれをデバッグする

これがスマホ上で起きると、つらいのは冗長なエラーを読み、診断コマンドを思い出すことです。そのマシンへの何らかの有効なセッションがあるなら、エラー出力を選択してアシスタントに尋ねてください ── TermAI の AI は実際のメッセージとサーバーのコンテキストを読み、5 つの原因のどれかを伝え、確認して実行できる正確な修正コマンドを示します。

よくある質問

Permission denied (publickey) とはどういう意味?
サーバーは SSH 鍵認証のみを受け付け、クライアントが提示した鍵がどれも一致しなかったのです。ユーザー名、鍵の選択、authorized_keys、権限の順で確認してください。

鍵をインストールしたのになぜ失敗する?
たいていは権限:~/.ssh は 700、authorized_keys は 600 で、ログインユーザーが所有している必要があります。あるいは、ログインするユーザーとは別のユーザー配下に鍵がインストールされています。

実際に何が失敗しているか確認するには?
デスクトップでは ssh -v user@host を実行;サーバーでは /var/log/auth.log(または journalctl -u ssh)を確認してください ── 理由が明示的に書かれています。

スマホから修正できる?
はい、何らかの有効な入り口(パスワードログインまたは別の鍵)があれば。TermAI はワンタップで新しい鍵をサーバーにデプロイでき、その AI が auth.log の出力を診断できます。

クイックファクト

• 意味:サーバーが認証を拒否 ── 提示された鍵が一致しなかった(ネットワークではなく認証)
• 主な原因:ユーザー名違い · 鍵が提示されていない · authorized_keys にない · 権限が不正 · サーバー設定
• 権限:~/.ssh 700、authorized_keys 600
• 本当の理由を確認:クライアント側 ssh -v、サーバー側 /var/log/auth.log