Windows 8 / Windows Server 2012 から Linux サーバーへ SSH 接続し、plink で shutdown -r now を流し込んで再起動したいのに、「Access granted. Press Return to begin session.」で待機して進まない——。この症状の原因と、スクリプトで確実に停止／再起動させるための実用的な対処方法をまとめます。
症状：plink 実行後に「Press Return…」で止まり、shutdown が流れない
Windows 側で PuTTY 付属の plink.exe を使い、Linux に対してコマンドを 1 行投げる運用はよくあります。ところが、次のようなメッセージが出たまま処理が止まり、後続のコマンド（今回なら shutdown）が実行されません。
Access granted. Press Return to begin session.
対話環境なら Enter を押せば先へ進みますが、バッチやタスクスケジューラ、監視システムのアクションなど 無人実行 では致命的です。Linux を一括で再起動・停止したいのに、押下待ちで “半分だけ止まる” 事故につながります。
原因：plink の「アンチスプーフィング」待ちと、対話プロンプトの存在
この「Press Return…」は、plink がログイン直後に表示する アンチスプーフィング（anti-spoofing） 系のメッセージが原因です。対話シェルを開く前にユーザー操作を要求し、表示内容のなりすましを防ぐ目的があります。
また、plink は SSH 接続時に状況に応じて確認プロンプトを出すことがあります。代表例は次の 2 つです。
- 初回接続でホスト鍵が未登録のときの確認（「このホスト鍵をキャッシュしますか？」系）
- 対話ログインや追加認証が必要なときの入力待ち
つまり、スクリプトを止める要因は「Press Return…」だけではありません。自動化するなら、対話が起きた時点で止まる のではなく、対話を出さない（または対話が必要なら即座に失敗する） 方向へ寄せるのが安全です。
最短の解決策：-batch と -no-antispoof を付けて非対話（バッチ）モードにする
結論から言うと、plink を 非対話（バッチ）モード で動かし、「Press Return…」を抑止します。使うのは次の 2 オプションです。
| オプション | 役割 | 効く症状 | 運用上のポイント |
|---|---|---|---|
-batch | 対話的な確認待ちを無効化（スクリプト向け） | ホスト鍵確認や追加入力が必要な状況で “待たずに失敗” させる | 自動化では必須。対話が必要な状態を検知でき、戻り値で分岐できる |
-no-antispoof | ログイン後の「Press Return…」等のアンチスプーフィング待ちを抑止 | 「Access granted. Press Return to begin session.」で止まる | 無人実行では有効。保護機能を弱めるので、ホスト鍵検証は別途きちんと行う |
質問にあった形に沿うと、最小構成は次のようになります（例の IP、ユーザー、パスワードは環境に合わせて置き換えてください）。
"C:\Program Files\PuTTY\plink.exe" -ssh 10.0.1.57 -l root -pw 123abc1 -no-antispoof -batch "shutdown -r now"
これで「Press Return…」待ちが出ず、shutdown が実行されるようになります。
スクリプト運用で失敗しやすいポイント：-batch で “止まらない” 代わりに “落ちる”
-batch は便利ですが、「対話が必要な状況」を自動で解決してくれるわけではありません。むしろ 対話が必要なら即失敗 します。これは欠点ではなく、自動化においては大きな利点です。
よくある失敗パターンと、事前に潰す方法を整理します。
| よくある失敗 | 起きること | 対策 |
|---|---|---|
| ホスト鍵が未登録 | 初回接続で確認が必要になり、-batch だと接続自体が失敗 | 最初に手動で 1 回接続してホスト鍵を登録する／もしくは運用上、ホスト鍵を固定して管理する |
| sudo がパスワードを要求 | 無人実行でパスワード入力できず失敗 | sudo -n を使って非対話にし、sudoers で許可コマンドを絞って NOPASSWD 化する |
| 鍵・パスワードが誤り | 認証失敗で終了 | 鍵認証へ移行し、認証情報の保管方法を見直す（後述） |
| 接続先が変わった（IP/ホスト鍵） | セキュリティ的には危険。自動で “はい” と答えると乗っ取りに繋がる | ホスト鍵の変更は変更管理に載せ、登録を更新する。原因が不明な変更は止める |
自動化で大切なのは、「成功時は成功、失敗時は失敗として確実に検知できる」ことです。対話で止まるより、明確にエラーで落ちた方が復旧も監視もやりやすくなります。
ホスト鍵（Host Key）をどう扱うか：自動化で一番ハマりやすい落とし穴
-batch を付けた途端に “繋がらない” となる場合、原因の多くは ホスト鍵の未登録 か ホスト鍵の不一致 です。これはセキュリティ的には重要な挙動で、無理に自動承認させると中間者攻撃（なりすまし）を見逃す危険があります。
おすすめの運用は次のどちらかです。
- 初回だけ手動で接続してホスト鍵を登録し、その後は
-batchで自動化する - 構成管理の一部として、接続先のホスト鍵を事前に確定・配布し、変更があった場合は変更管理の手順で更新する
現場でありがちな “IP は同じだが別サーバーへ差し替えた” ケースでは、ホスト鍵が変わるため自動化が失敗します。ここで慌てて例外対応をすると危険です。ホスト鍵が変わった理由が説明できない限り、停止／再起動ジョブは走らせない くらいのルールにしておくと、後々の事故が減ります。
なお、plink には接続先のホスト鍵を明示的に指定し、想定と違う鍵なら即失敗させる方法もあります。大量のサーバーを扱う場合は「登録済みかどうか」よりも「想定の鍵かどうか」を機械的にチェックできるため、運用の品質が上がります（鍵の取得・配布はセキュリティ方針に従ってください）。
タスクスケジューラや監視ツールから実行する場合の注意点
Windows のタスクスケジューラや監視ソフトのアクションから plink を呼ぶときは、同じコマンドでも動作が変わることがあります。特に次の 3 点は事前に確認しておくと詰まりにくいです。
- 実行ユーザー：誰の権限でタスクが走るか（ホスト鍵の保存先、鍵ファイルの参照権限が変わる）
- カレントディレクトリ：相対パスで鍵やログを指定すると見つからないことがある（絶対パス推奨）
- 標準出力の扱い：ツールによっては標準出力／標準エラーが捨てられる（ログファイルへリダイレクトする）
「手元のコマンドプロンプトでは成功するのに、本番ジョブだと失敗する」場合は、ほぼこのあたりが原因です。特にホスト鍵は “ユーザープロファイルに紐づいて保存される” 形になりやすいため、実行アカウントが違うと “初回扱い” になってハマります。
大量サーバーでの一括再起動：並列実行よりも「失敗時の扱い」を先に決める
複数台を一気に再起動する用途では、スクリプトの書き方よりも運用設計が重要です。例えば、次のような点を決めておくと現場が回ります。
- 失敗したホストは リトライするのか、手動対応に回すのか
- 再起動対象のリストは どこで管理するのか（テキスト、CMDB、監視ツール）
- 再起動後の 復帰確認 をどこで行うのか（ポート疎通、サービス起動、監視復帰）
バッチ例としては、ホスト一覧ファイルを読み取り、1 台ずつ plink を実行してログを残す形がシンプルです。並列化は速い反面、ログが追いにくくなりがちなので、まずは直列で安定させてから必要に応じて並列数を増やすのが無難です。
パスワード平文（-pw）を避ける：鍵認証（-i）に寄せるのが安全
例のように -pw でパスワードをコマンドラインへ埋め込むと、次のようなリスクが現実に起きます。
- バッチファイルを閲覧できる人に漏れる
- 運用サーバーのログ・履歴・監視ツールの収集対象に混ざる
- プロセス一覧やコマンドライン履歴から見える場合がある
- 同じパスワードを使い回していると被害が広がる
可能なら 鍵認証 に切り替え、plink 側は -i で秘密鍵（.ppk）を指定する構成にしましょう。PuTTY では PuTTYgen で鍵を作り、Linux 側の ~/.ssh/authorized_keys に公開鍵を登録する流れが一般的です。
| 方式 | 自動化のしやすさ | 情報漏えい耐性 | おすすめ度 |
|---|---|---|---|
-pw パスワード指定 | 簡単 | 低い（ファイル・ログ・履歴に残りやすい） | 短期の検証以外では非推奨 |
-i 鍵指定（.ppk） | 慣れれば簡単 | 高い（鍵の権限管理がしやすい） | 推奨 |
| Pageant（エージェント）利用 | 運用次第 | 高い（鍵をファイルで渡さない設計も可能） | 多数サーバー運用で有効 |
鍵認証にする際は、秘密鍵ファイルのアクセス権（誰が読めるか）と、鍵自体のパスフレーズ運用（無人実行との両立）をセットで設計してください。無人実行が最優先でも、少なくとも “root のパスワードを平文で配る” よりは事故りにくくなります。
root 直ログインを避ける：shutdown だけ許可する専用ユーザー＋sudo が堅い
「再起動・停止」だけが目的なら、root で SSH ログインするより、運用専用ユーザーを作って 必要最小限の権限 を与える方が安全です。
おすすめの構成例は次の通りです。
- Linux 側に
opsなどの専用ユーザーを作成 - SSH は鍵認証のみ許可（可能ならパスワードログインを無効化）
- sudoers で
shutdown（またはsystemctl reboot/poweroff）だけを NOPASSWD で許可 - plink からは
sudo -nを使って非対話実行
sudoers の設定はディストリビューションやパスにより差があります。まず Linux 側で次のようにパスを確認してください。
which shutdown
which systemctl
パスが分かったら、sudoers（visudo 推奨）に “必要なコマンドだけ” を書きます。例としてイメージを示します（環境に合わせて必ず調整してください）。
ops ALL=(root) NOPASSWD: /sbin/shutdown, /usr/sbin/shutdown
そして plink では次のように実行します。
"C:\Program Files\PuTTY\plink.exe" -ssh 10.0.1.57 -l ops -i "C:\keys\ops_shutdown.ppk" -no-antispoof -batch "sudo -n shutdown -r now"
sudo -n を付けるのがポイントです。sudo がパスワードを要求する状況だと、対話に入らずに即エラーになります。監視やジョブで「失敗」を検知できるため、原因調査が格段に楽になります。
実行結果を安定させる：終了コード（戻り値）とログを必ず取る
バッチ化でよくある “なんとなく動いている” 状態を避けるため、plink の終了コードと標準出力・標準エラー出力を拾うのがおすすめです。Windows のバッチなら %ERRORLEVEL%、PowerShell なら $LASTEXITCODE を使います。
バッチファイル例（ログ保存＋戻り値チェック）
@echo off
set PUTTY="C:\Program Files\PuTTY\plink.exe"
set HOST=10.0.1.57
set USER=ops
set KEY=C:\keys\ops_shutdown.ppk
set LOG=C:\logs\reboot_%DATE:~0,4%%DATE:~5,2%%DATE:~8,2%_%TIME:~0,2%%TIME:~3,2%%TIME:~6,2%.log
%PUTTY% -ssh %HOST% -l %USER% -i %KEY% -no-antispoof -batch "sudo -n shutdown -r now" 1>> %LOG% 2>&1
set RC=%ERRORLEVEL%
if not "%RC%"=="0" (
echo plink failed. rc=%RC% >> %LOG%
exit /b %RC%
)
exit /b 0 ログは “いつ誰が何をしたか” の証跡にもなります。特に shutdown 系はインシデントに直結しやすいので、運用ルールとして残す価値が高いです。
それでも「止まる」「実行されない」場合の切り分けチェック
-no-antispoof と -batch を付けても期待通りに動かないときは、「どこで対話が起きているか」を分解すると早いです。よくある論点をチェックリスト化します。
| チェック項目 | 症状の例 | 確認・対策 |
|---|---|---|
| ホスト鍵未登録 | 初回だけ失敗する／環境移行後に失敗する | 手動で 1 回接続し、ホスト鍵を正しく登録してからバッチ化する |
| sudo の tty 要求 | sudo が “tty が必要” などで失敗する | そのサーバーの sudo 設定（requiretty 等）を確認し、運用方針に合わせて調整する。必要なら plink 側で tty を割り当てる選択肢も検討 |
| 権限不足 | shutdown が許可されず失敗する | root 実行にせず、sudoers で必要コマンドのみ許可する／コマンドパスを正確に指定する |
| コマンドの実行方法 | 引用符やエスケープのせいでコマンドが崩れる | Windows のクォート規則に注意し、複雑なコマンドは sh -lc 等にまとめる |
| ネットワーク・FW | ときどき繋がらない／タイムアウトする | 疎通確認、22 番の許可、踏み台の有無、名前解決を確認。大量並列ならレート制限も疑う |
特に “初回だけ失敗” はほぼホスト鍵周りです。自動化前に、接続先が正しいこと（IP/名前解決）、ホスト鍵が想定通りであることを確認し、運用ドキュメントに残してください。
実務で役立つ小ワザ：shutdown の種類と使い分け
Linux の停止・再起動には複数のコマンドがあります。ディストリビューションや systemd の有無で使い勝手が変わるため、目的に合わせて使い分けるとトラブルが減ります。
| 目的 | コマンド例 | 備考 |
|---|---|---|
| 即時再起動 | shutdown -r now | 古くからある定番。運用上の説明もしやすい |
| 即時停止 | shutdown -h now | 停止後に電源断する環境では確認が必要 |
| systemd で再起動 | systemctl reboot | systemd 環境で素直。ログも追いやすい |
| systemd で停止 | systemctl poweroff | クラウドや仮想環境では “停止” の扱いが異なることがある |
「plink で止まる」問題自体はオプションで解決しますが、運用としては “何のコマンドを、どの権限で、どのタイミングで” 実行するかが重要です。停止・再起動は影響範囲が大きいので、専用ユーザー＋許可コマンド最小化＋ログ保存まで含めて設計すると、事故が起きにくく復旧も速くなります。
まとめ：自動化の要点は「対話を潰す」＋「失敗を検知する」
- 「Access granted. Press Return…」で止まるのは、plink のアンチスプーフィング待ちが原因
-no-antispoofで待ちを抑止し、-batchで対話プロンプトを無効化してスクリプト向けにする- 実運用では
-pwの平文埋め込みを避け、鍵認証（-i）＋専用ユーザー＋sudo の最小権限が安全 - 戻り値とログを取り、失敗を確実に検知できる形にしておく
この 4 点を押さえるだけで、Windows 側のバッチから Linux を再起動・停止する処理が “止まらず、事故らず、追跡できる” 形に近づきます。
コメント