원클릭으로 Manus에서 모든 스킬 실행

linux-server-ops

스타0

포크0

업데이트2026년 7월 10일 06:05

こんなときに使う: Ubuntu / Linux サーバーに SSH で接続し、sudo、systemd サービス、HTTP 監視を一連で安全に進めたいとき。接続前に SSH_AUTH_SOCK を含む認証状態を固定し、認証で止まらずにサーバー接続・権限確認・サービス起動・停止・再起動・状態確認を一気に行いたいとき。

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

RyoMurakami1983

RyoMurakami1983/happy_ai_life

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

Linux Server Ops

Linux Server Ops は、Ubuntu / Linux サーバーの運用を「認証固定 → 接続 → 権限確認 → サービス操作 → 監視」へ分けて進める skill です。実務でよく使う手順を、短い再利用可能な flow としてまとめ、skill 本体だけで扱えるようにします。

こんなときに使う

Ubuntu / Linux サーバーへ SSH で接続し、認証状態から権限確認・サービス操作まで一気に進めたいとき
SSH_AUTH_SOCK や ssh-agent の状態が怪しく、接続前に切り分けたいとき
systemd サービスの start / stop / restart / status を安全に実行したいとき
サーバーの HTTP 監視や簡単な健康確認の入口を作りたいとき

原理原則

SSH 認証の成否は「鍵ファイルの有無」ではなく「今の shell がどの agent socket を見ているか」で決まる。
CLI / agent のコマンド実行は毎回 fresh process。前回の実行で使えていた SSH_AUTH_SOCK は次の実行へ引き継がれない。毎回明示的に固定する。
パスフレーズ入力などの対話プロンプトで止まりうる操作は、先に非対話モードで検証して即失敗させ、切り分けに入る。

ゴール

接続前に SSH 認証状態（socket・agent・鍵登録）を固定する。
SSH で対象サーバーへ接続し、必要な権限確認を行う。
systemd サービスの起動・停止・再起動・状態確認を安全に実行する。
HTTP 監視や簡単な健康確認の入口を持つ。

成功条件

接続先、ユーザー、ポート、鍵、使用する agent socket の前提が明確になっている。
echo $SSH_AUTH_SOCK と ssh-add -l による接続前チェックを通過している。
sudo を必要とする操作と通常ユーザー操作が分けて書かれている。
start / stop / restart / status のどの操作をするかが明確である。
失敗時にまず見るログ・確認コマンド・失敗パターン表がある。

ワークフロー: サーバー運用の短い導線

ステップ 0 — SSH 認証状態を固定する（接続前チェック・省略禁止）

毎回この順で実行する。fresh process 前提のため「前回動いたから省略」は不可。

# 1. 今の shell が見ている socket を確認
echo $SSH_AUTH_SOCK

# 2. その socket に鍵が入っているか確認
ssh-add -l

# 3. 空・失敗なら候補 socket を総当たりで確認
for s in /tmp/ssh-*/agent.* "$XDG_RUNTIME_DIR/keyring/ssh"; do
  [ -S "$s" ] && { echo "== $s"; SSH_AUTH_SOCK=$s ssh-add -l; }
done

判定と回復:

鍵入り socket が見つかった → その socket を明示して使う
```
SSH_AUTH_SOCK=<socket> ssh -p 22 user@host
```
どの socket にも鍵が無い → agent を起こして鍵を登録し、登録確認まで済ませる
```
eval "$(ssh-agent -s)" && ssh-add ~/.ssh/id_ed25519
ssh-add -l
```
注意: 秘密鍵がパスフレーズ付きの場合、-i で鍵ファイルを直接指定するだけでは不十分。agent への登録（ssh-add -l で確認）が必要。

接続テストは非対話で行い、プロンプト待ちで止まらないようにする:

SSH_AUTH_SOCK=<socket> ssh -o BatchMode=yes -o ConnectTimeout=5 -p 22 user@host 'echo ok'

これが失敗したら、接続に進まず下の失敗パターン表で切り分ける。

ステップ 1 — 接続前提を固定する

接続先、ユーザー、ポート、鍵、使用する socket、sudo の必要性を確認し、最初にやる操作を固定する。

ステップ 2 — 権限と状態を確認する

whoami / id / sudo -v で権限を確認し、systemctl status と journalctl でサービス状態を把握する。

ステップ 3 — 変更と確認を分ける

start / stop / restart / reload を実行したら、status と curl / ss / journalctl で結果を検証する。

注意点

接続前に echo $SSH_AUTH_SOCK と ssh-add -l を確認しないと、認証がどこで止まっているか分かりません。
BatchMode=yes の接続テストを通さずに service 操作に進まないでください。
sudo が必要な操作は、通常ユーザー操作と分けて実行してください。

基本の手順

SSH 認証状態を固定する（ステップ 0 を必ず実行）
- echo $SSH_AUTH_SOCK → ssh-add -l → 必要なら候補 socket 総当たり
- BatchMode=yes の接続テストが ok を返すまで先へ進まない
接続先を確認する
- host, user, port, key, socket, sudo 可能性を確認する
- 例: SSH_AUTH_SOCK=<socket> ssh -p 22 user@host
権限を確認する
- whoami, id, sudo -v
サービス状態を確認する
- systemctl status <service>
- journalctl -u <service> -n 100 --no-pager
必要な操作を実行する
- sudo systemctl start|stop|restart|reload <service>
健康確認を行う
- curl -I http://127.0.0.1:<port>
- ss -ltnp | grep <port>
- ps aux | grep <process>

SSH 認証の失敗パターン表

症状	原因	切り分け	回復
`Permission denied (publickey)` かつ `ssh-add -l` が空	鍵未登録または agent socket が違う	`echo $SSH_AUTH_SOCK` と `ssh-add -l` を確認する	`ssh-agent` を起動し、鍵を登録して再試行する
`Connection timed out`	接続先・ポート・ネットワーク経路の問題	`ssh -o BatchMode=yes -o ConnectTimeout=5` で再確認する	接続先、ポート、ユーザー名、ネットワーク経路を確認する
`sudo: a password is required`	sudo 権限が必要だがパスワード未設定	`whoami` / `id` / `sudo -v` を確認する	sudo が必要な操作はパスワード付き前提で実行する

이 저장소의 다른 Skills

같은 저장소

loop-engineering

RyoMurakami1983/happy_ai_life

調査→修正→検証→ふりかえり/後続 Issue 化までを 1 つの改善ループで回したいときに使う。実装前の再現確認や、review 指摘・検証結果をもとに次のアクションへつなぐ。

2026-07-100

to-prd

RyoMurakami1983/happy_ai_life

こんなときに使う: 現在の会話内容をもとに、実装・エージェント発注に直結する PRD を作りたいとき。追加のインタビューはせず、すでに会話に出ている内容だけから構成する。情報が不足している場合は捏造せず「未確定」として明示する。

2026-07-100

interview-me

RyoMurakami1983/happy_ai_life

こんなときに使う: ユーザーが「インタビューして」「質問して」「設計を詰めたい」などと言ったら使う。計画や設計の重要な判断軸を洗い出し、具体例・反例・影響範囲まで深掘りして要件整理に落とす。

2026-07-100

copilot-authoring

RyoMurakami1983/happy_ai_life

Copilot の custom skill / agent / repository instructions の作成・改善・構造確認を 1 つの入口にまとめる。複合スキルとして、対象に応じて適切な authoring ルートへ分けつつ、実行時のモデル呼び出しを抑止してルーティングを優先する。試作から `plugins/*` 配布へ昇格するときの name / description 整備も扱う。skill / agent / repo-wide instructions / path-specific instructions を新規作成したいとき、既存定義を育てたいとき、公開前に責務や導線を確かめたいとき。

2026-07-050

new-agent

RyoMurakami1983/happy_ai_life

新しい custom agent を既存 agent 群と同じ型で立ち上げる。agent の新規追加、役割分離のための専門 agent 作成、既存群の隙間を埋めたいとき。

2026-07-050

validate-authoring

RyoMurakami1983/happy_ai_life

skill と agent の authoring 資産を出荷前に検証する。draft の骨格確認、改善後の回帰確認、共有前の最低品質確認をしたいとき。

2026-07-050

name	linux-server-ops
description	こんなときに使う: Ubuntu / Linux サーバーに SSH で接続し、sudo、systemd サービス、HTTP 監視を一連で安全に進めたいとき。接続前に SSH_AUTH_SOCK を含む認証状態を固定し、認証で止まらずにサーバー接続・権限確認・サービス起動・停止・再起動・状態確認を一気に行いたいとき。

Linux Server Ops

こんなときに使う

Ubuntu / Linux サーバーへ SSH で接続し、認証状態から権限確認・サービス操作まで一気に進めたいとき
SSH_AUTH_SOCK や ssh-agent の状態が怪しく、接続前に切り分けたいとき
systemd サービスの start / stop / restart / status を安全に実行したいとき
サーバーの HTTP 監視や簡単な健康確認の入口を作りたいとき

原理原則

SSH 認証の成否は「鍵ファイルの有無」ではなく「今の shell がどの agent socket を見ているか」で決まる。
CLI / agent のコマンド実行は毎回 fresh process。前回の実行で使えていた SSH_AUTH_SOCK は次の実行へ引き継がれない。毎回明示的に固定する。
パスフレーズ入力などの対話プロンプトで止まりうる操作は、先に非対話モードで検証して即失敗させ、切り分けに入る。

ゴール

接続前に SSH 認証状態（socket・agent・鍵登録）を固定する。
SSH で対象サーバーへ接続し、必要な権限確認を行う。
systemd サービスの起動・停止・再起動・状態確認を安全に実行する。
HTTP 監視や簡単な健康確認の入口を持つ。

成功条件

接続先、ユーザー、ポート、鍵、使用する agent socket の前提が明確になっている。
echo $SSH_AUTH_SOCK と ssh-add -l による接続前チェックを通過している。
sudo を必要とする操作と通常ユーザー操作が分けて書かれている。
start / stop / restart / status のどの操作をするかが明確である。
失敗時にまず見るログ・確認コマンド・失敗パターン表がある。

ワークフロー: サーバー運用の短い導線

ステップ 0 — SSH 認証状態を固定する（接続前チェック・省略禁止）

毎回この順で実行する。fresh process 前提のため「前回動いたから省略」は不可。

# 1. 今の shell が見ている socket を確認
echo $SSH_AUTH_SOCK

# 2. その socket に鍵が入っているか確認
ssh-add -l

# 3. 空・失敗なら候補 socket を総当たりで確認
for s in /tmp/ssh-*/agent.* "$XDG_RUNTIME_DIR/keyring/ssh"; do
  [ -S "$s" ] && { echo "== $s"; SSH_AUTH_SOCK=$s ssh-add -l; }
done

判定と回復:

鍵入り socket が見つかった → その socket を明示して使う
```
SSH_AUTH_SOCK=<socket> ssh -p 22 user@host
```
どの socket にも鍵が無い → agent を起こして鍵を登録し、登録確認まで済ませる
```
eval "$(ssh-agent -s)" && ssh-add ~/.ssh/id_ed25519
ssh-add -l
```
注意: 秘密鍵がパスフレーズ付きの場合、-i で鍵ファイルを直接指定するだけでは不十分。agent への登録（ssh-add -l で確認）が必要。

接続テストは非対話で行い、プロンプト待ちで止まらないようにする:

SSH_AUTH_SOCK=<socket> ssh -o BatchMode=yes -o ConnectTimeout=5 -p 22 user@host 'echo ok'

これが失敗したら、接続に進まず下の失敗パターン表で切り分ける。

ステップ 1 — 接続前提を固定する

接続先、ユーザー、ポート、鍵、使用する socket、sudo の必要性を確認し、最初にやる操作を固定する。

ステップ 2 — 権限と状態を確認する

whoami / id / sudo -v で権限を確認し、systemctl status と journalctl でサービス状態を把握する。

ステップ 3 — 変更と確認を分ける

start / stop / restart / reload を実行したら、status と curl / ss / journalctl で結果を検証する。

注意点

接続前に echo $SSH_AUTH_SOCK と ssh-add -l を確認しないと、認証がどこで止まっているか分かりません。
BatchMode=yes の接続テストを通さずに service 操作に進まないでください。
sudo が必要な操作は、通常ユーザー操作と分けて実行してください。

基本の手順

SSH 認証状態を固定する（ステップ 0 を必ず実行）
- echo $SSH_AUTH_SOCK → ssh-add -l → 必要なら候補 socket 総当たり
- BatchMode=yes の接続テストが ok を返すまで先へ進まない
接続先を確認する
- host, user, port, key, socket, sudo 可能性を確認する
- 例: SSH_AUTH_SOCK=<socket> ssh -p 22 user@host
権限を確認する
- whoami, id, sudo -v
サービス状態を確認する
- systemctl status <service>
- journalctl -u <service> -n 100 --no-pager
必要な操作を実行する
- sudo systemctl start|stop|restart|reload <service>
健康確認を行う
- curl -I http://127.0.0.1:<port>
- ss -ltnp | grep <port>
- ps aux | grep <process>

SSH 認証の失敗パターン表

症状	原因	切り分け	回復
`Permission denied (publickey)` かつ `ssh-add -l` が空	鍵未登録または agent socket が違う	`echo $SSH_AUTH_SOCK` と `ssh-add -l` を確認する	`ssh-agent` を起動し、鍵を登録して再試行する
`Connection timed out`	接続先・ポート・ネットワーク経路の問題	`ssh -o BatchMode=yes -o ConnectTimeout=5` で再確認する	接続先、ポート、ユーザー名、ネットワーク経路を確認する
`sudo: a password is required`	sudo 権限が必要だがパスワード未設定	`whoami` / `id` / `sudo -v` を確認する	sudo が必要な操作はパスワード付き前提で実行する