LinuxのSSH公開鍵認証をSE時代に「なんとなく」使っていた話|仕組みを理解せずコピペで設定していた頃と現役講師が語る「理解する」大切さ

HOMEリナックスマスター.JP 公式ブログLinux学習ガイド > LinuxのSSH公開鍵認証をSE時代に「なんとなく」使っていた話|仕組みを理解せずコピペで設定していた頃と現役講師が語る「理解する」大切さ
宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
「SSH公開鍵認証の設定方法は調べれば出てくる。でも、なぜ鍵が2つあるのかよく分からない」
Linuxを使い始めて間もない頃、こんな疑問を持った方は多いのではないでしょうか。

かくいう私も、SE時代の数年間はほぼそんな状態でした。設定手順は覚えた。でも「どうして公開鍵と秘密鍵で認証できるのか」を誰かに説明できるかと言われたら、自信を持って答えられなかった。

この記事では、仕組みを理解しないまま公開鍵認証を使い続けた私の体験を、20年以上Linuxサーバーを運用してきた経験から正直に振り返ります。「なんとなく動いている」から「なぜ動くのかが分かる」に変わることで、現場での対応力がどれほど変わるかをお伝えします。

この記事のポイント

・公開鍵認証は「手順の暗記」より「仕組みの理解」が学習効率を大きく左右する
・仕組みを知らないとエラー時に原因を絞り込む軸が持てない
・「2つの鍵の役割の違い」を説明できるかどうかが理解の分岐点
・理解が深まると、セキュリティ設計の判断力が格段に上がる


LinuxのSSH公開鍵認証をSE時代に「なんとなく」使っていた話|仕組みを理解せずコピペで設定していた頃と現役講師が語る「理解する」大切さ
「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

SE時代、SSH公開鍵認証の設定を「呪文の詠唱」のようにやっていた

2003年頃、私は社内のLinuxサーバー管理を任されたSEでした。SSHによるサーバーアクセスは日常業務の一部で、公開鍵認証もすでに一般的な手法として使われていました。

当時の私の設定手順は、おそらく次のようなものでした。

・クライアント側でssh-keygenを実行して鍵のペアを生成する
・生成された~/.ssh/id_rsa.pubの内容をサーバーの~/.ssh/authorized_keysにコピーする
~/.sshのパーミッションを700authorized_keys600に設定する
・SSHで接続を試みて認証が通ればOK

手順通りやれば動く。問題が起きなければ誰もそれ以上深掘りしない。当時の私はそういうサイクルで仕事をしていました。

振り返ってみると、「なぜ公開鍵と秘密鍵の2つが必要なのか」「なぜ秘密鍵をサーバーに置いてはいけないのか」を、自分の言葉でスラスラ説明できたか怪しいです。コピペで動かすことには慣れていても、理解は伴っていなかった。

セミナーで3,100名以上を指導してきた中で、同じ状態の受講生を何人も見てきました。「設定手順は知っている。でも理由は説明できない」という状態は、決して珍しくありません。

「なんとなく設定できる」状態で困った3つの場面

仕組みを理解しないまま使い続けると、いくつかの場面で必ず詰まります。私が実際に困った体験を3つ振り返ります。

1. エラーが出ても原因の見当がつかなかった

あるとき、いつも通りの手順で公開鍵認証を設定したのに、接続がパスワード認証に落ちてしまう事象が起きました。ssh -vで詳細ログを確認しましたが、どこで何が起きているか見当がつかない。

# ssh -v で接続の詳細ログを確認するコマンド例 $ ssh -v -i ~/.ssh/id_rsa user@192.168.10.xx # 認証失敗(鍵を拒否される)時の出力例(IPはマスク済み) debug1: Offering public key: /home/user/.ssh/id_rsa RSA SHA256:xxxxxxxxxxxxxxxx debug1: Authentications that can continue: publickey,password # ← 鍵が受け入れられず次の認証方式に移行している # 認証成功時の出力例 debug1: Offering public key: /home/user/.ssh/id_rsa RSA SHA256:xxxxxxxxxxxxxxxx debug1: Server accepts key: /home/user/.ssh/id_rsa RSA SHA256:xxxxxxxxxxxxxxxx debug1: Authentication succeeded (publickey).

原因は~/.ssh/authorized_keysのパーミッションを644にしていたことでした。SSHdはパーミッションが緩い鍵ファイルをセキュリティ上の理由で使用しません。しかし当時の私はパーミッション設定の「なぜ」を理解していなかったため、ログのどの行に注目すればよいか分からず、30分以上格闘しました。

仕組みが分かっていれば、「SSHdが鍵認証を受け付けない原因は大抵3つ。①鍵の内容の不一致、②authorized_keysの場所の問題、③パーミッションの問題」と絞り込めます。でも当時の私には、その「絞り込みの軸」がなかった。

2. 新人に「なぜ鍵が2つあるんですか?」と聞かれて答えられなかった

私がチームリーダーになって1年後、新人SEから「公開鍵と秘密鍵って何が違うんですか?どちらをサーバーに置けばいいですか?」と聞かれたことがあります。

私の答えは「公開鍵をサーバーに置いて、秘密鍵は手元に持っておくもの」という手順の説明に終始しました。「なぜそうするのか」という原理を説明できなかった。

新人は「分かりました」と言って席に戻りましたが、その後しばらくして「秘密鍵をサーバーにも置いてしまっていた」という事象が発覚しました。手順を教えても、理由が伴わなければ人は応用できない。そのことを痛感した場面でした。

3. セキュリティの判断を「なんとなく」でやっていた

「パスワード認証を無効にすべきか」「AllowUsersで接続ユーザーを制限すべきか」といった設定の判断を、当時の私は「ネットでみんなそうしているから」という理由でやっていました。

なぜその設定が必要なのか、どんなリスクをどのように軽減するのかを、自分の言葉で説明できないまま設定していた。セキュリティ設定の本質が分かっていなければ、設定の抜け漏れに気づくこともできません。

公開鍵認証でエラーが出たときの絞り込み法

実際に私のセミナーでは、この「鍵認証が通らない」というトラブルを受講生から何度も相談されてきました。20年以上の運用経験から言うと、原因のほぼ全てが次の3点のどれかです。

# サーバー側でパーミッションを確認するコマンド(鍵認証が通らない場合) $ ls -la ~/.ssh/ drwx------. 2 user user 29 Aug 12 10:45 . # 700 必須 drwx------. 5 user user 115 Aug 12 10:44 .. -rw-------. 1 user user 391 Aug 12 10:45 authorized_keys # 600 必須 # authorized_keysのパーミッションが644になっている場合(NGの例) -rw-r--r--. 1 user user 391 Aug 12 10:45 authorized_keys # ← これが原因 # 修正コマンド $ chmod 700 ~/.ssh $ chmod 600 ~/.ssh/authorized_keys

①鍵の不一致:クライアントのid_rsaと、サーバーのauthorized_keysに登録した公開鍵が対応していない
②パーミッション:~/.ssh700未満、またはauthorized_keys600より緩い
③sshdの設定:/etc/ssh/sshd_configPubkeyAuthenticationnoになっている

この絞り込みができるかどうかは、「公開鍵認証の仕組みを知っているかどうか」に直結しています。仕組みが分かれば、どの原因がどのログに現れるかを読めるようになります。

仕組みが「腑に落ちた」転換点

転換点になったのは、あるセキュリティ研修でRSA暗号の仕組みを図解で学んだときです。「公開鍵で暗号化したものは秘密鍵でしか復号できない」「秘密鍵で署名したものは公開鍵で検証できる」という非対称暗号の原理を、初めてきちんと理解しました。

そこで初めて「なるほど、だからサーバーには公開鍵を置くのか。秘密鍵が手元から漏れない限り、公開鍵をどこに置いても安全が保たれる。サーバーが公開鍵を持つことで、秘密鍵の持ち主だけが認証を通れる仕組みになっている」という全体像が見えました。

この理解を得てから、設定上のトラブル対応が劇的に速くなりました。エラーが出ても「鍵の検証フローのどこで詰まっているか」を原理から考えられるようになったからです。また、新人への説明も「公開鍵は南京錠(錠前)、秘密鍵はその鍵(カギ)と考えると分かりやすい。サーバーに南京錠(公開鍵)を置いておいて、本人だけが持つカギ(秘密鍵)で開ける仕組み」と、原理から話せるようになりました。

現役講師として今伝えたいこと

私のセミナーでは3,100名以上のエンジニアを指導してきましたが、「設定はできるが仕組みが分からない」という状態の受講生は今も少なくありません。それ自体は恥ずかしいことではないし、学習の初期段階では手順の習得が先でも構わない。

ただ、一定の経験を積んだタイミングで「仕組みを理解し直す」フェーズが必要です。特に次のような状況になったら、それが合図です。

・エラーが出たときに「とりあえず再起動」しか思いつかない
・設定の理由を聞かれると「ネットにそう書いてあったから」しか言えない
・同じエラーが繰り返し起きるたびに、毎回一から調べ直している

SSH公開鍵認証は、Linuxの基礎的な仕組みを理解するための格好の題材です。暗号の原理・ファイルのパーミッション・sshdの動作フロー、これらが一つのテーマの中に凝縮されています。

関連記事として、Linuxのポート確認コマンド(ss・lsof)chkconfig・systemctlの使い方も参考にしてみてください。サーバー管理の基礎をひとつひとつ「理解」として積み上げることが、現場で頼られるエンジニアへの近道です。

まとめ

SSH公開鍵認証を「なんとなく動かせる」状態から「仕組みを理解して使える」状態に変えることは、Linux学習の重要な転換点のひとつです。

状態 対応力の違い
手順だけ知っている コピペで設定できるが、エラー時に原因を特定できない
仕組みを理解している エラーを原理から絞り込め、他者への説明や応用設計もできる

「動いているから分かった」は危険なシグナルです。特にセキュリティ関連の設定は、理解の深さが現場での判断力に直結します。

20年以上の運用経験の中で一番後悔したことのひとつが、「もっと早く仕組みを理解しておけばよかった」ということです。手順の先にある「なぜ」を追いかけることを、ぜひ意識してみてください。

「仕組みから理解するLinux」、体系的に学んでみませんか?

SSH公開鍵認証に限らず、Linuxの設定ミスや運用トラブルの多くは「手順の暗記」で済ませていることが原因です。まずは全体像を体系的に掴んでください。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。

「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。