カテゴリー: 未分類

はじめに：パスワードをやめるだけなのに、意外と事故が起きる

サーバーにログインするとき、毎回パスワードを打つのは面倒ですし、安全面でも心もとありません。そこで多くの人が最初に取り組むのが SSH の鍵認証です。仕組み自体はシンプルですが、初めて設定するときには、ちょっとした手順の抜けで自分自身が締め出されることがあります。

この記事では、設定手順の細かいコマンド解説よりも、「どこでつまずきやすいか」「何を先に確認しておくと安全か」という注意点に絞って整理します。

鍵認証の仕組みを一言でつかむ

鍵認証では、「秘密鍵」と「公開鍵」という対になったファイルを使います。公開鍵はサーバー側に置き、秘密鍵は手元のマシンに置きます。ログイン時には、秘密鍵を持っていることをサーバーに証明できれば入れます。パスワード自体はネットワークに流れません。

ここで大切なのは、公開鍵は配っても構わないが、秘密鍵は決して他人に渡さない、という非対称性です。この区別を取り違えると、あとの注意点がすべて意味を失います。

注意点1：秘密鍵と公開鍵を取り違えない

鍵を作ると、たとえば「id_ed25519」と「id_ed25519.pub」のような 2 つのファイルができます。拡張子 .pub が付いているほうが公開鍵です。サーバーに登録するのはこちらだけです。

• サーバーに貼り付けるのは .pub 付きのファイルの中身
• 秘密鍵をメール、チャット、クラウドの共有フォルダに置かない
• 秘密鍵をそのままバックアップに入れる場合は保管先の権限に注意する

注意点2：パスフレーズは付けておく

鍵を作る際、パスフレーズの入力を求められます。面倒で空にしたくなりますが、空のままだと、秘密鍵のファイルが漏れた時点でそのまま使われてしまいます。パスフレーズは、ファイルが盗まれたときの最後の防壁です。

毎回入力するのが煩わしい場合は、ssh-agent に鍵を一時的に預ける方法があります。パスフレーズを守りつつ、入力の手間を減らせます。

注意点3：鍵の種類は新しめのものを選ぶ

現在は Ed25519 という方式が広く使われており、鍵が短く、扱いやすいのが特徴です。古い環境や特殊な機器では対応していないこともあるため、接続先のドキュメントで対応状況を確認しておくと安心です。RSA を選ぶ場合は、十分な長さの鍵にします。

注意点4：サーバー側のパーミッションが厳しすぎる、ではなく緩すぎる

鍵認証がなぜか通らない原因として、とても多いのがファイルやディレクトリの権限です。SSH サーバーは、権限が緩すぎると安全でないと判断して、鍵を無視することがあります。

• ホームディレクトリは、自分以外が書き込める状態にしない
• .ssh ディレクトリは、自分だけが読み書きできる状態にする
• authorized_keys も、自分以外が書き込めないようにする
• 手元の秘密鍵も、自分だけが読める権限にする。緩いと ssh コマンド自身が警告して使用を拒否する

具体的な数値は環境や運用によって変わることもありますが、「自分だけが触れる」状態を目指すのが基本です。

注意点5：公開鍵の登録は ssh-copy-id が楽。ただし手作業でも壊さない

公開鍵の登録には、ssh-copy-id というコマンドが用意されています。接続先に公開鍵を追記し、必要なディレクトリも作ってくれるので、初めてならこれが無難です。

手作業で authorized_keys に貼る場合は、次の点に気をつけます。

• 1 つの鍵は 1 行で書く。途中で改行が入ると無効になる
• 既存の内容を上書きせず、追記する
• 前後に余計な文字や空白が混ざっていないか確認する

注意点6：パスワード認証を切るのは、鍵でログインできると確認してから

いちばん事故が起きやすいのがここです。鍵認証が使えるようになると、安全のためにパスワード認証を無効化したくなります。それ自体は有効な対策ですが、鍵でのログインが成功することを確認する前に切ってしまうと、誰も入れなくなります。

安全な進め方の例を挙げます。

• いま使っているログインセッションは閉じずに残しておく
• 別の端末や別のウィンドウから、鍵でログインできるか試す
• 成功を確かめてから、sshd の設定を変更する
• 設定変更後も、既存セッションを残したまま、新しい接続で動作を確認する
• 設定ファイルの文法チェックを行ってから、サービスを再読み込みする

クラウドや VPS では、コンソール経由で復旧できる場合もありますが、使えるかどうかは事業者次第です。復旧手段があるかを、事前に調べておくと気持ちが楽になります。

注意点7：うまくいかないときは、クライアント側から詳細表示で確かめる

ログインできないとき、いきなり設定をいじるのは避けましょう。ssh コマンドに詳細表示のオプション（-v）を付けると、どの鍵を試し、どこで拒否されたかが見えます。サーバー側では、認証ログを確認すると、権限の問題や鍵の形式の問題が書かれていることがよくあります。

原因を見てから直す、という順番を守るだけで、無駄な試行錯誤はかなり減ります。

あると便利：設定ファイルで接続を整理する

手元の ~/.ssh/config に、接続先ごとのホスト名、ユーザー名、使う鍵を書いておくと、長いコマンドを毎回打たずに済みます。複数の鍵を使い分けるときにも役立ちます。ただし、意図しない鍵を全サーバーに送ってしまわないよう、接続先ごとに使う鍵を明示するのがおすすめです。

まとめ：焦らず、逃げ道を残して進める

SSH の鍵認証は、一度整えてしまえば安全で快適です。初めての設定で押さえておきたいのは次の点でした。

• 公開鍵と秘密鍵の区別を徹底する
• パスフレーズを付け、必要なら ssh-agent を使う
• 権限は「自分だけが触れる」状態にする
• 公開鍵は 1 行で、追記の形で登録する
• パスワード認証を切る前に、別セッションで鍵ログインを確認する
• 詰まったら、設定を触る前にログと詳細表示を見る

最も大切なのは、作業中のセッションを閉じずに、いつでも戻れる状態で進めることです。それさえ守れば、初めての鍵認証でも落ち着いて設定できます。

朝の作業は「同じ手順の繰り返し」でできている

毎朝パソコンを開いて、まず同じことをしている人は多いと思います。ログの確認、バックアップ先の空き容量のチェック、前日分のファイルの整理、決まったフォルダへのレポートの書き出しなどです。一つひとつは数分で終わりますが、毎日続くと意外に集中力を削られます。

Linux には、こうした作業を決まった時刻に実行してくれる cron という仕組みがあります。この記事では、コマンドの細かい書き方よりも、どんな作業を cron に任せ、どう設計すれば長く動き続けるかという考え方を中心にまとめます。

まず「任せてよい作業」を見極める

何でも自動化すればよいわけではありません。cron に向いているのは、次のような性質を持つ作業です。

• 手順が毎回同じで、途中で人が判断する必要がない
• 実行する時刻が決まっている、または決まっていても困らない
• 失敗したときに、やり直しても被害が出にくい
• 結果が「見ればわかる」形で残せる

逆に、実行のたびに内容を確認したい作業や、失敗すると取り返しがつかない作業は、いきなり自動化しないほうが安全です。まずは「確認して通知するだけ」の作業から始めると、失敗しても困りません。

手作業をそのまま書き写さない

自動化の第一歩は、手順をスクリプトにまとめることです。cron の設定そのものには、長いコマンドを直接書かず、スクリプトを一つ呼び出すだけにしておくのがおすすめです。理由は三つあります。

• スクリプトは手で実行して動作を確かめられる
• cron の設定行が短く読みやすいまま保てる
• スクリプトをバージョン管理に入れて変更履歴を残せる

cron に登録する前に、必ず端末から手で実行して、期待どおりに動くことを確認しましょう。「手では動くのに cron からだと動かない」という問題は、次に述べる環境の違いが原因であることがほとんどです。

cron は「いつもの環境」ではない

cron から起動されるプログラムは、ログインシェルとは違う、最小限の環境で動きます。特に次の点でつまずきやすいです。

• PATH が短く、普段使っているコマンドが見つからないことがある
• カレントディレクトリが想定と違うことがある
• シェルの設定ファイルで定義した変数やエイリアスは読み込まれない
• 端末がないので、対話的な入力や画面表示は使えない

対策は単純です。スクリプトの中で使うコマンドはフルパスで書くか、冒頭で PATH を明示します。作業ディレクトリも先頭で明示的に移動します。必要な設定値は、スクリプト内か専用の設定ファイルから読み込むようにします。「環境に頼らない」ことが、cron で安定して動かすための基本です。

時刻の指定は「ずらす」「重ねない」

cron の時刻指定は、分、時、日、月、曜日の五つの欄で書きます。毎朝実行したい場合は、日・月・曜日の欄を * にして、分と時だけを指定します。

設計上のポイントは二つあります。一つ目は、きりのよい時刻に集中させないことです。たとえば 6 時ちょうどに多くの処理を走らせると、互いに重くなります。数分ずつずらしておくと、負荷が分散されます。二つ目は、前回の実行がまだ終わっていないのに次の実行が始まる事態を避けることです。実行時間が延びる可能性のある処理には、flock などによる排他制御を入れておくと安心です。

また、パソコンが起動していない時刻の分は、cron では実行されません。ノート PC など常時稼働でない環境では、この点を前提に考える必要があります。そうした環境向けには、取りこぼしを後から実行する anacron のような仕組みもあります。自分の環境がどちらに当たるかを先に確認しておきましょう。

何が起きたかを必ず残す

自動化で最も怖いのは、止まっているのに誰も気づかないことです。そのため、実行結果は必ず記録します。

• 標準出力と標準エラー出力をログファイルにリダイレクトする
• 各実行の開始と終了の時刻をログに書く
• 失敗時は終了コードが 0 以外になるようにスクリプトを作る
• ログが増え続けないよう、ローテーションや削除の仕組みを用意する

cron は、設定によっては出力をメールで送る機能も持っていますが、メール環境が整っていないと届かないまま捨てられることもあります。そのため、メールだけに頼らず、ログファイルを残すのが確実です。さらに、失敗したときだけチャットやメールに通知する仕組みを足すと、「静かなら正常」と判断できるようになります。

失敗しても安全な作りにする

朝の作業を任せる以上、いつか必ず失敗する日が来ます。そのときの被害を小さくするために、次のことを意識します。

• 同じ処理を二回実行しても結果が変わらないようにする（冪等にする）
• ファイルを消す処理は、対象を厳密に絞り、最初は一覧表示だけで試す
• 変数が空のまま削除コマンドに渡されないよう、スクリプトの先頭でエラー時に止まる設定を入れる
• 書き込みは一時ファイルに行ってから置き換え、中途半端なファイルを残さない

とくに削除を伴う処理は、変数の誤りが大事故につながります。最初の数日は実際に消さず、「消す予定の一覧」をログに出すだけにして、結果を目で確認してから本番に切り替えると安全です。

小さく始めて、見直しながら育てる

最初から完璧な仕組みを作ろうとすると、手が止まってしまいます。おすすめの進め方は次のとおりです。

• 毎朝の作業のうち、最も単純なものを一つだけ選ぶ
• 手で実行できるスクリプトにする
• cron に登録し、数日間はログを毎朝確認する
• 問題がなければ、次の作業を一つ追加する

数週間たったら、ログを見返して、不要になった処理や、頻繁に失敗している処理を整理しましょう。自動化は作って終わりではなく、環境や仕事の変化に合わせて手入れしていくものです。

まとめ

cron で朝の作業を自動化するときに大切なのは、書き方のテクニックよりも、設計の姿勢です。任せてよい作業を選び、スクリプトに切り出し、環境に依存せず、結果を記録し、失敗しても安全にしておく。この積み重ねで、朝の数分間が確実に手元に戻ってきます。まずは「確認して記録するだけ」の小さな作業から、始めてみてはいかがでしょうか。

WordPress へようこそ。こちらは最初の投稿です。編集または削除し、コンテンツ作成を始めてください。