投稿者: autoposter

はじめに：鍵認証は「設定順」で事故が決まる

SSHの鍵認証は、パスワード認証より安全で、毎回の入力も減らせます。ただ、初めて設定するときは「手順どおりにやったのに入れない」「パスワード認証を閉じたらサーバーに入れなくなった」といったつまずきが起こりがちです。この記事では、コマンドの羅列ではなく、初回に気をつけたい点を順番に整理します。

1. 作業中のセッションは絶対に閉じない

いちばん大事な注意点です。リモートのサーバーで sshd の設定を変えるとき、いま繋がっているセッションを残したまま、別の端末から新しく接続して確認してください。設定ミスで入れなくなっても、残しておいた最初のセッションから元に戻せます。

クラウドやVPSなら、コンソール接続やレスキューモードが使えるか、事前に確認しておくと安心です。物理サーバーで現地に行けない場合は、なおさら慎重に進めましょう。

2. 鍵ペアは「手元の端末」で作る

鍵は秘密鍵と公開鍵のペアです。作るのは、接続する側の手元の端末です。サーバー上で作って秘密鍵を持ち帰る、という流れは避けましょう。秘密鍵が通信経路やサーバーに残る余計なリスクが生まれます。

• 秘密鍵：自分の端末だけに置く。他人に渡さない、チャットやメールに貼らない
• 公開鍵：サーバーに登録するもの。拡張子は通常 .pub で、見られても問題ない

鍵の種類は、特別な事情がなければ Ed25519 が扱いやすく、現在広く使われています。古い環境との互換性が必要な場合は RSA を選ぶこともあります。その場合は十分な鍵長を指定してください。

3. パスフレーズは付ける

鍵生成のときにパスフレーズを聞かれます。面倒で空にしたくなりますが、付けておくことをおすすめします。パスフレーズがあれば、万一ノートPCの紛失やバックアップ経由で秘密鍵ファイルが漏れても、すぐには悪用されません。

毎回入力するのが負担なら、ssh-agent を使って、一度入力したら一定時間は使い回す方法があります。「パスフレーズなしで便利に」ではなく「パスフレーズありで便利に」を目指すのが基本です。

4. 公開鍵の登録は ssh-copy-id が楽

公開鍵は、サーバー側のユーザーの ~/.ssh/authorized_keys に1行として追記します。手作業でもできますが、改行が入ったり途中で切れたりしやすいので、ssh-copy-id コマンドが使える環境ならそれを使うのが確実です。このコマンドは、必要なディレクトリを作り、追記まで行ってくれます。

手作業で登録する場合は、次の点を確認してください。

• 公開鍵が1行のまま貼られているか
• 既存の行を上書きしていないか（追記にする）
• ログインしたいユーザーのホームにある authorized_keys か

5. パーミッションが原因で入れないことが多い

鍵認証がうまくいかない原因として非常に多いのが、ファイルやディレクトリの権限です。sshd は、権限が緩すぎると安全でないとみなして、鍵を無視することがあります（設定の StrictModes が有効な場合）。

• ~/.ssh ディレクトリ：自分だけが読み書きできる状態（700）
• authorized_keys：自分だけが読み書きできる状態（600 など）
• ホームディレクトリ：他人から書き込めない状態にしておく
• 手元の秘密鍵：自分だけが読める状態（600）。緩いと ssh クライアント側が使用を拒否する

「ちゃんと登録したのに聞かれる」ときは、まず権限を疑うと解決が早いです。

6. 先に鍵でログインできることを確認してから、パスワード認証を止める

鍵認証の目的の一つは、パスワードによる総当たり攻撃を無効にすることです。そのためには sshd_config で PasswordAuthentication を no にしますが、これは鍵でのログインが確実にできると確認してからです。

確認の手順は次のとおりです。

• 別の端末（または別セッション）から、鍵を使って接続できるか試す
• 接続時に ssh -v を付けて、どの鍵が使われ、どの認証方式で通ったかを見る
• 問題がなければ設定を変更し、sshd の設定ファイルの文法チェック（sshd -t）を行う
• 設定を反映したあと、さらに別の新しいセッションでもう一度ログインを試す

なお、ディストリビューションによっては、設定ファイルを分割して読み込む仕組み（sshd_config.d など）があり、そちらの記述が優先されて、変更したつもりが効いていないことがあります。反映後は、実際の有効値を sshd -T で確認すると確実です。

7. root ログインの扱いも一緒に見直す

鍵認証を整えるついでに、root での直接ログインを許可するかどうかも見直しましょう。一般ユーザーでログインして必要なときだけ権限を上げる運用にすると、攻撃対象を減らせます。ただし、これも自分がsudoを使えることを確認してから変更してください。順番を間違えると、管理者権限を失います。

8. 秘密鍵の管理とバックアップ

鍵認証は、秘密鍵を持っていることが身元の証明になります。つまり、秘密鍵をなくすと入れなくなり、盗まれると他人に入られます。

• 端末を買い替えるときの鍵の移行方法を決めておく
• 複数の端末を使うなら、端末ごとに鍵を分けると、紛失時にその鍵だけを無効にできる
• 不要になった公開鍵は authorized_keys から削除する
• 秘密鍵をクラウドの共有フォルダや公開リポジトリに置かない

とくに、うっかり Git リポジトリに秘密鍵をコミットする事故は珍しくありません。一度公開した鍵は、削除しても漏れたものとして扱い、作り直してください。

9. うまくいかないときの切り分け

入れないときは、慌てて設定を変えず、まずログを見ます。

• クライアント側：ssh -v（必要なら -vvv）で、どの鍵を試し、どこで拒否されたかを確認する
• サーバー側：認証ログ（ディストリビューションにより /var/log/auth.log や journalctl など）を確認する
• 鍵が複数ある場合：ssh -i で使う鍵を明示し、~/.ssh/config に Host ごとの設定を書く

サーバー側のログには「権限が不正」「鍵が受け付けられない」などの理由が書かれていることが多く、原因の特定に役立ちます。

まとめ：手順より「安全に戻れる状態」を優先する

SSH鍵認証の初回設定で大切なのは、次の3点です。

• 作業中のセッションを残し、別セッションで必ず確認する
• 秘密鍵にはパスフレーズを付け、手元だけで管理する
• 鍵でのログインを確認してから、パスワード認証や root ログインを止める

どれも難しい作業ではありませんが、順番を誤ると自分を締め出してしまいます。「いつでも元に戻れる」状態を保ちながら、一つずつ確かめて進めてください。

自動化は「面倒だから」では始まらない

毎朝同じ手順を繰り返していると、「これはcronに任せよう」と思う瞬間が来ます。ログの確認、バックアップの状態チェック、レポートの生成、天気や予定の通知など、候補はいくらでも挙がります。しかし、思いつきでそのままスクリプトを書き、crontabに一行足すだけでは、数週間後に「いつの間にか動いていなかった」という事態になりがちです。

この記事では、cronの書き方そのものよりも、朝の作業を任せるときの考え方に絞って整理します。コマンドの細かい仕様は環境によって差があるため、確実に言える範囲にとどめます。

まず「手でやって成功した状態」を定義する

自動化の最初の一歩は、手作業の手順を書き出すことです。何を入力として、何が出力されれば成功なのかを言葉にします。ここが曖昧だと、スクリプトは動いているのに結果が正しくない、という最も気づきにくい失敗を生みます。

• 入力は何か（ファイル、データベース、外部サービスなど）
• 出力は何か（ファイル、メール、通知など）
• 成功と失敗は何で見分けるか（終了コード、出力ファイルの有無やサイズなど）
• 途中で止まったとき、人は何をするか

この四つが答えられるなら、cronに任せる準備は半分終わっています。

cronは「環境が違う」ことを前提にする

手元の端末で動いたスクリプトが、cronからだと動かない。これは非常によくある話です。cronはログインシェルとは別の、最小限に近い環境でコマンドを実行します。そのため、次の点で差が出やすくなります。

• PATHが短く、普段使っているコマンドが見つからない
• カレントディレクトリが想定と違い、相対パスが壊れる
• シェルの初期設定ファイルで定義した変数やエイリアスが使えない

対策は単純です。スクリプト内では絶対パスを使い、必要な環境変数は冒頭で明示的に設定し、最初に作業ディレクトリへ移動します。「cronから動かす」ことを前提に書いておけば、手元でも同じように動きます。

失敗に気づける仕組みを先に作る

朝の自動化で一番怖いのは、失敗が静かに起きることです。成功したときの通知よりも、失敗したときに自分が気づけるかどうかのほうがずっと重要です。

最低限、標準出力と標準エラー出力をログファイルに残しておきましょう。あとから「その日、何が起きたか」を追えるだけで、原因調査の手間は大きく減ります。ログは増え続けるので、ローテーションや古いものの削除も合わせて考えておくと安心です。

さらに一歩進めるなら、失敗時だけ通知が届くようにします。スクリプトの終了コードを見て、異常のときにだけメッセージを送る形です。毎日届く「成功しました」の連絡は、そのうち読まれなくなります。届いたら必ず意味がある通知だけを残すのが、長続きするコツです。

同時実行と再実行に耐えられるようにする

前日の処理が長引いて、翌朝の実行と重なることがあります。また、失敗した処理を手動でやり直すこともあります。こうした場面で壊れないように、次のことを意識します。

• 同じ処理が二重に走らないよう、ロックの仕組みを用意する
• 何度実行しても結果が同じになるように作る（冪等性）
• 書き込み途中のファイルを他の処理が読まないよう、一時ファイルに書いてから置き換える

とくに冪等性は効果が大きい考え方です。「もう一度実行しても安全」と分かっていれば、失敗したときに迷わず再実行できます。

実行時刻は「人の都合」と「システムの都合」で決める

朝の作業だからといって、何も考えずに毎日同じ分刻みの時刻へ集中させるのは避けたいところです。多くの処理がちょうど同じ時刻に始まると、負荷が重なりやすくなります。自分の作業に合わせた時刻と、他の定期処理との兼ね合いの両方を見て決めます。

また、タイムゾーンや夏時間の扱いは、サーバーの設定によって挙動が変わる可能性があります。日本国内のサーバーだけなら影響は小さいものの、海外のサーバーやコンテナ上で動かす場合は、どのタイムゾーンで解釈されるかを一度確認しておくと安全です。

そしてもう一つ、cronは「その時刻にマシンが起動していること」が前提です。ノートパソコンのように電源が落ちる環境では、実行の取りこぼしが起こりえます。そのような環境では、cron以外の仕組みも検討する価値があります。

小さく始めて、少しずつ任せる範囲を広げる

最初から完璧な自動化を目指す必要はありません。まずは「朝の確認作業の結果をファイルに書き出す」といった、副作用の小さいものから始めます。数日動かして問題がなければ、通知を足し、次に処理の一部を任せる、という順で広げていきます。

データを削除したり、外部へ送信したりする処理は、慣れてからで十分です。最初は「何も壊さない」処理で、仕組みそのものが信頼できるかを確かめます。

まとめ：cronに任せるとは、判断を前倒しすること

cronで朝の作業を自動化するというのは、単に実行を機械に任せることではなく、「うまくいかなかったときにどうするか」という判断を、あらかじめ決めておくことでもあります。成功の定義、環境の違いへの備え、失敗の検知、再実行への強さ、時刻の選び方。この五つを押さえておけば、朝の定型作業は安心して手放せます。

まずは一つ、毎朝やっている小さな作業を選んで、手順を書き出すところから始めてみてください。それだけでも、一日の始まりが少し軽くなるはずです。