この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
この記事では、その原因が「鍵の内容ではなく、.sshディレクトリのパーミッション設定」だったという実体験をもとに、LinuxがなぜSSHの権限設定にここまで厳密にこだわるのかを解説する。
20年以上Linuxサーバーを運用してきた経験から言うと、この失敗はLinuxの「パーミッションで守る」という設計思想を体で理解する、最良のきっかけになった。
この記事のポイント
・SSH鍵認証の失敗原因の多くは鍵の内容でなく.sshのパーミッションにある
・.sshは700、authorized_keysは600でなければOpenSSHは鍵認証を拒否する
・ssh -vで詳細ログを確認すると、認証失敗の原因を素早く特定できる
・この仕様はLinuxの「パーミッションで守る」設計思想の典型的な実装例
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
SE時代に経験した「鍵認証が通らない」謎
私がSSH鍵認証を初めて本格的に設定したのは、SE時代の2003年頃だった。サーバー間でスクリプトを自動実行させるため、パスワードなしでSSH接続できる構成を作る必要があった。
当時の上司から「そのくらいなら自分でやってみろ」と言われ、技術書を参考に設定を始めた。
しかし、どれだけ丁寧に手順を踏んでも、接続するたびにパスワードを求められる。
1. 何度確認しても鍵の内容は正しかった
最初に疑ったのは、公開鍵のコピーミスだった。ssh-keygenで生成した公開鍵の内容を接続先のauthorized_keysに貼り付け、何度見直しても内容は一致している。
改行が余分に入っていないか、スペースが混ざっていないかと、目を皿のようにして確認した。
それでも結果は変わらない。接続するたびに「Permission denied (publickey)」が返ってくる。
「設定方法が古いのか」「バージョンによって挙動が違うのか」——いろいろな可能性を考えながら1時間以上格闘したが、原因がどこにあるのか見当もつかなかった。
2. 先輩に見てもらって分かったこと
行き詰まったところで、隣の席にいた先輩エンジニアに声をかけた。先輩は私の画面をのぞき込み、一言「ssh -vでやってみろ」と言った。
-vオプション（verboseモード）で接続すると、認証の詳細ログが画面に流れた。
その中に、こんな1行があった。
# ssh -v 接続先ホスト で実行した際のログ（抜粋） Authentication refused: bad ownership or modes for directory /home/miyazaki/.ssh
先輩がls -la ~/の結果を確認し、すぐ原因を見つけた。
「.sshディレクトリのパーミッションが755になってるぞ」と言われ、700に変更したらすぐに鍵認証が通った。
あれだけ格闘した原因が、たったこれだけだったのかと思うと、拍子抜けするほどあっけなかった。
3. なぜ「755」と「700」でこれほど違いが出るのか
その後、先輩に理由を聞いた。755とは「所有者は読み書き実行できる」「グループと他のユーザーは読み取りと実行ができる」という設定だ。
つまり、.sshディレクトリの中身を、同じシステムの他ユーザーが参照できる状態になっていた。
OpenSSHはこの状態を「安全ではない」と判断し、鍵認証を意図的に拒否する仕様になっている。
「認証に使う鍵が他人から読める可能性があるなら、そんな鍵は使わない」という考え方だ。
技術書通りに鍵を設定しても、ディレクトリのパーミッションが緩ければ動かない。
「手順通りにやったのになぜ」と思い続けた理由がようやく分かった瞬間だった。
OpenSSHがパーミッションにこだわる理由
この経験から、私はOpenSSHの「パーミッションチェックの厳しさ」が、実はセキュリティ設計として理にかなっていることを理解した。1. 鍵ファイルが他人から読める状態では、鍵として機能しない
SSH鍵認証の仕組みは「秘密鍵を持っている人だけが接続できる」という前提に立っている。ところが、秘密鍵ファイルやauthorized_keysを他ユーザーが読めてしまうなら、その「秘密」が保証されない。
OpenSSHが「パーミッションが緩ければ鍵認証を使わない」と判断するのは、誤った設定のまま運用するリスクを避けるためだ。
私が現場でよく見かけるのが、「鍵を設定したのに繋がらない」と言いながらパーミッションを確認していないケースだ。
OpenSSHが明示的に拒否しているのに、鍵の内容だけを疑い続けて時間を消費してしまう。
2. Linuxのパーミッション設計が「守る仕組み」として機能している
この経験で気づいたのは、Linuxの権限設計が「誤った設定をすると意図した動作をしない」という形でセキュリティを保証しているということだ。chmod・chown・SELinuxをはじめ、Linuxのセキュリティの多くは「パーミッションで制御する」という思想でできている。
SSHのパーミッションチェックも、その一環だ。
セミナーで3,100名以上を指導してきた中で、Linuxを「コマンドが動く道具」として見ている段階では、こうした設計思想に気づきにくいと感じる。
でも、「なぜそのコマンドがその挙動をするのか」を意識し始めると、Linuxが「意図した設計で動いている」ことが見えてくる。
それが「Linuxが分かってきた」と感じる転換点の一つだと私は思っている。
「Permission denied (publickey)」エラーになる原因と3つの対処方法
この経験をもとに、SSH鍵認証でよく遭遇する「Permission denied (publickey)」エラーの原因と、確認すべき設定を整理しておく。1. .sshディレクトリのパーミッションは700か
接続先サーバーの~/.sshディレクトリは700（所有者のみが読み書き実行できる状態）でなければならない。755や775になっていると、OpenSSHは鍵認証を拒否する。まずここを確認してほしい。
# パーミッション確認（700になっているかチェック） ls -la ~/ # .sshのパーミッションを700に設定する chmod 700 ~/.ssh
2. authorized_keysのパーミッションは600か
~/.ssh/authorized_keysのパーミッションは600（所有者のみ読み書き可能）でなければならない。グループや他ユーザーへの読み取り権限が残っていると拒否される。644や664は要注意だ。
# authorized_keysのパーミッションを600に設定する chmod 600 ~/.ssh/authorized_keys # 接続元PCの秘密鍵も600になっているか確認する chmod 600 ~/.ssh/id_rsa
3. ssh -vで詳細ログを確認する
鍵認証が通らない場合は、まずssh -vを実行してほしい。詳細ログには「なぜ認証が失敗しているか」が具体的に出力される。
「Authentication refused: bad ownership or modes」であればパーミッション問題と判断できる。
エラーメッセージを丁寧に読む習慣は、SSH鍵認証に限らずLinuxの問題切り分け全般に効く。
英語のエラーでも、単語ごとに読んでいけば「何を言っているか」は理解できるはずだ。
エラーメッセージを読む力については、「Linuxのエラーメッセージが読めれば障害対応は3倍速くなる｜現場で差がつく英語力の身につけ方」も参考にしてほしい。
まとめ
SSH鍵認証の「Permission denied (publickey)」が返ってくる場合、原因の多くは鍵の内容ではなく.sshディレクトリやauthorized_keysのパーミッション設定にある。| 確認ポイント | 正しいパーミッション | よくある間違い |
|---|---|---|
| ~/.sshディレクトリ | 700 | 755・775（他ユーザーが参照できる） |
| ~/.ssh/authorized_keys | 600 | 644・664（他ユーザーが読める） |
| 秘密鍵ファイル（接続元のPC） | 600 | 644・755（他人が読める状態） |
LinuxのSSH設定についてさらに詳しく学びたい方は、「sshd_configの設定ガイド｜Port変更・rootログイン禁止・鍵認証設定の手順」も参考にしてほしい。
また、SSH接続の全体的な仕組みについては「LinuxでSSHを本当に理解した日の話」で体験をまとめているので、あわせて読んでほしい。
SSH鍵認証の落とし穴も「型」で防ぐ——Linuxサーバー構築の基礎を体系的に身につけませんか？
パーミッションのミスは「知識不足」ではなく「体系的な理解の欠如」から来ることがほとんどです。まずはサーバー構築の全体像を掴んでください。
ネットの断片的な情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：Linuxサーバーの時刻ズレで障害調査が迷宮入りした日の話｜NTP設定の重要性を痛感した経験
- 前のページへ：Linuxのcpコマンドで本番設定ファイルを上書きしてしまった日の話｜現役講師が語る上書き事故の恐怖と作業前バックアップの鉄則
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます