メインコンテンツへスキップ
SSH 経由でサーバーを接続して、Alex（クラウドエンジニア）がホスト上でシェルコマンドを実行できるようにします。ディスク使用量の確認、ログの追跡、サービスの検査、問題の診断をサーバー上で直接行えます。

​
前提条件

要件詳細
到達可能なホストサーバーが SSH ポートで CloudThinker からのインバウンド SSH を受け入れる必要があります
ログインユーザーシェルアクセスを持つ既存のユーザーアカウント
認証済み鍵そのユーザーの ~/.ssh/authorized_keys に公開鍵が登録されていること
鍵認証の有効化そのユーザーに対して sshd が公開鍵認証を許可していること

​
セットアップ

1

鍵ペアを準備する

既存の鍵ペアを使用するか、CloudThinker 専用の鍵を生成します：
ssh-keygen -t ed25519 -C "cloudthinker" -f ./cloudthinker_key
これにより cloudthinker_key（秘密鍵）と cloudthinker_key.pub（公開鍵）が生成されます。OpenSSH 形式（-----BEGIN OPENSSH PRIVATE KEY-----）と PEM 形式（-----BEGIN RSA/EC PRIVATE KEY-----）の両方に対応しており、ed25519・rsa・ecdsa 鍵が使用できます。
2

公開鍵を承認する

サーバー上のログインユーザーの authorized keys に公開鍵を追加します：
ssh-copy-id -i ./cloudthinker_key.pub user@server.example.com
# または cloudthinker_key.pub を手動で ~/.ssh/authorized_keys に追記
3

CloudThinker に接続を追加する

Connections → SSH に移動し、以下を入力します：
  • Host：ホスト名または IP（例：server.example.com または 10.0.0.5）
  • User：ログインユーザー（例：ubuntu）
  • Port：SSH ポート（任意、デフォルト 22）
  • Private key：BEGIN/END 行を含む秘密鍵全体
  • Passphrase：任意。秘密鍵にパスフレーズが設定されている場合のみ必要
CloudThinker は接続をテストし、成功すると Connected ステータスを表示します。

​
ホスト鍵の検証

初回接続時、CloudThinker はサーバーのホスト鍵を記録します。以降の接続では鍵が一致しているか毎回確認されるため、サーバーの識別情報が予期せず変わった場合に警告が表示されます。 鍵が変わると接続は停止し、CloudThinker は以前に信頼されていたフィンガープリントと新しいフィンガープリントの両方を表示します。これは通常、サーバーの再構築や SSH 鍵のローテーション後に発生します。変更が意図したものであると確認できたら、Trust new host key を選択して続行してください。
サーバーの識別情報が変わることを想定していなかった場合は、すぐに新しい鍵を信頼しないでください。予期しない変更は、接続が傍受されている可能性を示しています。まずサーバー側で新しいフィンガープリントを確認してください。

​
接続詳細

フィールド説明例
Host対象サーバーのホスト名または IP アドレスserver.example.com
Userシェルアクセスを持つログインユーザーubuntu
PortSSH ポート22
Private keyBEGIN/END ヘッダーを含む秘密鍵全体-----BEGIN OPENSSH PRIVATE KEY-----...
Passphrase鍵が暗号化されている場合のパスフレーズ—

​
必要な権限

Alex はログインユーザーの権限でコマンドを実行します。エージェントが特権コマンドを実行する必要がない限り、root アクセスは不要です。
ログインユーザーをエージェントが必要とするコマンドとパスのみに絞ってください。authorized_keys の command= および from= オプションを使用して、鍵で実行できる操作と接続元を制限できます。

​
エージェントの機能

接続後、Alex は SSH 経由でサーバー上のシェルコマンドを実行できます。
機能説明
システム検査ディスク・メモリ・CPU・プロセス・サービスの状態
ログ分析アプリケーションおよびシステムログの読み取りと検索
診断ホスト上の障害・接続性・設定の調査
運用確認読み取り専用コマンドでサーバーの状態を報告

​
接続を確認する

@alex #report show system uptime, disk usage, and top memory processes on the server

​
プロンプト例

@alex #report check disk usage on all filesystems and flag anything above 80%
@alex #report tail /var/log/app/error.log and summarize the last 100 error lines
@alex #report show which processes are using the most CPU and memory right now
コマンドはログインユーザーの権限で実行されます。エージェントが実際に必要とする操作のみにユーザーを制限してください。

​
トラブルシューティング

  • ログインユーザーの ~/.ssh/authorized_keys に公開鍵があることを確認してください
  • User がその鍵で認証されているアカウントと一致しているか確認してください
  • BEGIN/END 行を含む秘密鍵全体が貼り付けられているか確認してください
  • 鍵にパスフレーズが設定されている場合は Passphrase を入力してください
  • Host と Port が正しいか確認してください
  • サーバーが CloudThinker からの SSH を受け入れているか確認してください（ファイアウォール、セキュリティグループ、許可リスト）
  • SSH デーモンが起動中でそのポートでリッスンしているか確認してください
  • サーバーの再構築や SSH 鍵のローテーション後は想定内です。新しいフィンガープリントを確認して Trust new host key を選択してください
  • 変更が予期しないものである場合は、再信頼する前に調査してください
  • 接続は正常ですが、コマンドがゼロ以外の終了コードを返しました
  • コマンド、ユーザーの権限、リモートホスト上のパスを確認してください

​
セキュリティ

  • 最小権限 — エージェントがユースケースに必要な権限のみを付与します。まず読み取り専用から始め、後から拡張してください。
  • デフォルトで読み取り専用 — エージェントにこの接続で変更を行わせる場合を除き、読み取り専用の認証情報を使用してください。
  • 認証情報のローテーション — 通常のスケジュールに従ってキーとトークンをローテーションしてください。接続を更新すると、CloudThinker が新しい値を自動的に取得します。
  • オフボーディング時に失効 — 接続を削除するか、チームメンバーが退職する際には、プロバイダー側で認証情報を無効化してください。
  • 専用鍵 — CloudThinker 専用の鍵ペアを生成することで、独立して失効させることができます。
  • ローテーションと検証 — 鍵を定期的に更新し、再信頼する前に必ずホスト鍵の変更を確認してください。

​
関連

Alex Agent

クラウドエンジニアリングとインフラ運用
https://mintcdn.com/cloudthinker/aLd-ttc-SCW-aFky/images/icons/kubernetes.svg?fit=max&auto=format&n=aLd-ttc-SCW-aFky&q=85&s=7c03292954ff635a1994623a5c39971b

Kubernetes 接続

ワークロード分析と運用のためのクラスター接続