エラーの内容
$ ssh user@192.168.1.100
user@192.168.1.100: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
クラウドサーバーでよく見られる短いバリアント：
Permission denied (publickey).
SSHが接続を拒否しました。サーバーはサポートしているすべての認証方式を列挙しましたが、どれも機能しませんでした。厄介ですが、解決できます。ほぼ必ず5つの根本原因のいずれかに行き着きます。
根本原因
- 秘密鍵がサーバーの
~/.ssh/authorized_keysにある公開鍵と一致していない ~/.ssh/またはauthorized_keysのファイルパーミッションが緩すぎる — SSHがそれらの使用を拒否する- SSHエージェントに鍵が読み込まれていない
- 間違ったユーザー名で接続しようとしている（EC2、DigitalOceanなどでよくある）
- 鍵ファイルのパスが間違っているか、
-iオプションを指定し忘れている
ステップ1：まずSSHを詳細モードで実行する
推測はやめましょう。SSHに何を試みているか正確に教えてもらいます：
ssh -vvv user@your-server.com
出力をスクロールして、次のような行を探します：
debug1: Offering public key: /home/you/.ssh/id_rsa RSA ...
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
「Offering public key」の後に「No more authentication methods」が表示される場合、サーバーがその特定の鍵を拒否したことを意味します。「Offering」の行が全く表示されない場合は、クライアントが試す鍵を見つけられていません。
修正1：公開鍵がauthorized_keysに登録されているか確認する
最も一般的な原因です。ローカルマシンから公開鍵を取得します：
cat ~/.ssh/id_rsa.pub
# または
cat ~/.ssh/id_ed25519.pub
次にサーバーで、鍵が登録されているか確認します：
cat ~/.ssh/authorized_keys
登録されていない場合は追加します：
# ローカルマシンから：
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server.com
# または手動で — 鍵を追記する：
echo "your-public-key-content" >> ~/.ssh/authorized_keys
確認すべき点として、各鍵は改行のない1行でなければなりません。鍵の途中に改行があると、SSHはそれを認識できません。
修正2：SSHファイルのパーミッションを修正する
パーミッションが緩すぎると、SSHは警告なしに鍵を無視します。警告も分かりやすいメッセージも出ず、ただ拒否するだけです。見落としやすいですが、修正はとても簡単です。
サーバー上で：
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
ローカルマシン上で、秘密鍵を修正します：
chmod 600 ~/.ssh/id_rsa
# または
chmod 600 ~/.ssh/id_ed25519
SSHが適用するルール：
~/.ssh/ディレクトリ —700（所有者のみ）でなければならないauthorized_keys— 最大でも600または640でなければならない- 秘密鍵ファイル —
600でなければならない（誰でも読める状態だとSSHが使用を拒否する）
ヒント：chmodの数字が何を意味するか覚えられない場合は、ToolCraftのUnixパーミッション計算ツールを使うと視覚的にパーミッションを設定でき、対応するchmod番号も確認できます。640と644のどちらが正しいか迷ったときに本当に役立ちます。
修正3：-iで正しい鍵を指定する
システムに複数の鍵がある場合、SSHは自動的に1つを選びますが、間違った鍵を選ぶ可能性があります。明示的に指定しましょう：
ssh -i ~/.ssh/my-specific-key user@your-server.com
AWS EC2の場合は、インスタンス作成時にダウンロードした.pemファイルを使用します：
ssh -i ~/Downloads/my-ec2-key.pem ec2-user@your-ec2-ip
ユーザー名にも注意してください。EC2 Amazon Linuxは ec2-user、Ubuntuは ubuntu、Debianは admin を使用します。正しい鍵を使っていても、ユーザー名が間違っていると接続拒否されます。
修正4：SSHエージェントに鍵を追加する
SSHエージェントは復号された鍵をメモリにキャッシュするため、接続のたびにパスフレーズを入力する必要がなくなります。エージェントが起動していないか鍵が読み込まれていないと、認証時に鍵が提示されない場合があります。エージェントを起動して鍵を追加します：
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
現在読み込まれている鍵を確認します：
ssh-add -l
「The agent has no identities」と表示される場合、何も読み込まれていません。ssh-add を実行してパスフレーズを入力してください。
修正5：サーバーのauthorized_keysを確認する（SELinux／所有者の問題）
CentOSやRHELサーバーはSELinuxを実行しており、標準のUnixパーミッションに加えてファイルコンテキストを強制します。正しいchmod値だけでは不十分な場合があります。ファイルコンテキストを確認します：
ls -laZ ~/.ssh/authorized_keys
コンテキストが正しくない場合は、復元します：
restorecon -Rv ~/.ssh
ついでに、~/.ssh が正しいユーザーによって所有されているか確認します：
ls -la ~ | grep .ssh
# 表示されるべき内容: drwx------ 2 youruser youruser
sudoコマンドを実行した後、~/.ssh がrootの所有になってしまうことは意外とよくあります。修正するには：
sudo chown -R youruser:youruser ~/.ssh
修正6：サーバーのsshdの設定を確認する
最後に確認する価値があります — サーバー自体が公開鍵認証を完全に拒否するよう設定されている場合があります：
sudo grep -E 'PubkeyAuthentication|AuthorizedKeysFile|PermitRootLogin' /etc/ssh/sshd_config
次の設定になっているか確認します：
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PubkeyAuthentication が no に設定されている場合は変更して、sshdを再起動します：
sudo systemctl restart sshd
修正の確認
変更後は、詳細モードでテストします：
ssh -v user@your-server.com
認証が成功した場合は次のように表示されます：
debug1: Authentication succeeded (publickey).
まだ失敗する場合は、修正手順を順番に試してください。パーミッションの問題と間違った鍵が約80%のケースを占めています — 修正2か修正3までに解決できる可能性が高いです。
予防策
ssh-keygen -t ed25519で鍵を生成する — Ed25519は署名操作においてRSA-2048より大幅に高速で、将来の攻撃に対してもより堅牢とされている- 手動でコピー＆ペーストする代わりに
ssh-copy-idで鍵をデプロイする — 自動的に正しいパーミッションが設定される - ユーザー名や鍵のパスを混同しないよう、接続情報を
~/.ssh/configに保存する：
Host myserver
HostName 192.168.1.100
User ubuntu
IdentityFile ~/.ssh/id_ed25519
~/.ssh/ディレクトリをバックアップしておく。秘密鍵を失うと、その鍵が登録されているすべてのサーバーへのアクセスが失われ、復旧する手段はない- SSHキーを定期的にローテーションし、必ず強力なパスフレーズで保護する。ToolCraftのパスワードジェネレーターはここで役立つ — SSHキーのパスフレーズは強力でありながら、実際にタイプできるものである必要がある