ログイン認証情報

認証情報は常に特定の1台のVMに紐づきます。1台のVMに複数の認証情報を持たせることもできます。 たとえば、日常用の deploy アカウントと、緊急時用の root アカウントなどです。

すべての認証情報は、ディスクに書き込まれる前に vault の鍵で暗号化 されます。

認証情報を追加する

VMのコンテキストメニューを開き → Manage credentials → Add。

パスワード

ユーザー名とパスワードだけです。すぐに使えますが、サーバーが許可している場合はSSH鍵の方が 依然としてより良い選択肢です。

SSH鍵

秘密鍵の内容(ファイルパスではありません)を貼り付けます。アプリは標準的なOpenSSH形式を 受け付けます。

-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAAB...
-----END OPENSSH PRIVATE KEY-----

鍵にパスフレーズがある場合は、別のフィールドに入力してください。パスフレーズは秘密鍵自体と 同じ鍵で保護されるため、無人の監視処理でも、パスフレーズ保護付きの鍵をポーリングのたびに 尋ねられることなく使用できます。

接続時の認証情報の選択

認証情報が1つだけのVMは、確認なしにそれを使用します。複数ある場合は、セッションを開く前に 選択画面が表示されます。監視はVMの監視タブで個別に設定される専用の認証情報を使用するため、 低権限アカウントでポーリングしながら、管理者アカウントで手動ログインする、といった使い分けが 可能です。

監視用アカウント

プローブは読み取り専用で、rootは必要ありません。CPU、RAM、ディスク、ネットワーク、プロセス、 開いているポートの一覧を取得するには、一般的なアカウント1つで十分です。一部のセクションには 追加の権限が必要ですが、権限がない場合はポーリング全体を失敗させるのではなく、その項目だけが 空になります。

項目	必要な権限
SSHログインログ	journalctl -u sshd または /var/log/auth.log の読み取り権限
Sudoersの内容	/etc/sudoers の読み取り権限
他ユーザーのauthorized_keys	/home/*/.ssh/authorized_keys の読み取り権限
ブロック済みIPの一覧	fail2ban-client が利用可能であること

まずは一般的なアカウントで始め、セキュリティ関連のチェックも必要になった時点で読み取り権限を 付与してください。

アプリが行わないこと

• ~/.ssh/id_rsa を自動的に読み取ることは一切ありません。 ~/.ssh/config からインポートする 場合でも、IdentityFile のパスは、どの鍵をそのホストが想定しているかを分かるように表示され るだけで、その内容が暗黙的に読み取られることはありません。その鍵を使うには、意図的に貼り付ける 必要があります。
• どこにも同期されません。 認証情報を同期するサーバー自体が存在しません。