セットアップ SSH Linux 用のキー VPS: ローカルにキーを作成し、公開鍵をインストールし、ログイン設定を変更する前に2つ目の接続をテストします。
このチェックリストを使用して、所有するLinux VPS または管理者に許可されています。 ホスト、アカウント名、SSH ポートから、実際にサービスに割り当てられます。 配布名からユーザー名を推測しないでください。 認証変更が失敗した場合は、アクセスを回復させる方法を確認します。オペレーターが実際に利用できる方法を使用してください。
新規ログイン方法をテストしながら、既存の認証セッションをオープンにしておく。 作業中のアクセスが見つからない場合は、最初に初期接続の詳細を解決します。 パブリックホスティングプランまたは有料注文は、作業中のシェルアカウントではなく、サーバーの指示を適用する前に、実際のサービスの詳細を待ちます。
リモートVPSの内側ではなく、独自のクライアントデバイスでssh-keygenを実行します。 OpenSSH クライアントがサポートするので、 ssh-keygen -t ed25519 は、ファイルの場所とパスフレーズの Ed25519 キーペアとプロンプトを作成します。 既存のキーが既に存在している場合は、新しいファイル名を選択します。別のサーバーがまだ使用しているキーを上書きしないでください。
パスフレーズと安全なデバイスストレージで秘密鍵を保護します。 シェルの履歴に保存されるコマンドにパスフレーズを置くのではなく、インタラクティブなプロンプトを使用します。 鍵の目的と公開鍵の指紋を追跡して、アクセスを見直したり、再発するときに適切なエントリを識別することができます。
公開鍵は通常、.pub と同じファイル名が付属しています。 VPSで利用するアカウントの認証鍵の場所にその公開鍵を追加します。 多くのOpenSSHインストールは、リモートアカウントの~/.ssh/authorized_keysを使用しますが、有効なサーバー設定は異なる場所を指定できます。 システムを想定する代わりに、同じポリシーを使用する場所を確認します。
利用可能な場合、ssh-copy-id は、既存の認可された接続を介して公開鍵をインストールできます。 マニュアルインストールは、既存のキーを保存し、各公開鍵を1行に保つ必要があります。 すべてのアクセス所有者を意図的に見直しない限り、すべてのファイルを単一の新しいエントリに置き換えないでください。 プライベートキーは、自分のデバイスにとどまります。
必要に応じてテーブルを水平にスクロールします。
| アイテム | ミッション | 所属する場所 |
|---|---|---|
| 公衆認証キー | サーバがキーを認識できるように | リモートアカウントの承認されたキーの場所 |
| プライベート認証キー | ログイン時に所持する | クライアントデバイスで保護されたストレージ |
| サーバーホストキー指紋 | サーバ ID の検証を支援 | 検証済みのレコードとクライアント既知のホストエントリ |
サーバホストキーの指紋と、新しいホスト ID を受け入れる前に、オペレータまたは別の検証されたチャネルによって得られる信頼できる値を比較します。 以前に知られた指紋が予期しない変化を調べる。 クライアントの既知のホストエントリを削除し、どの表示が正しいサーバーに達したかを確立しないかどうかを受け入れる.
2番目のターミナルを開き、実際のアカウント、ホスト、選択したプライベートキーパスと接続します。 OpenSSH -i オプションは、ID ファイルを選択し、 -p は、割り当てられたときにデフォルトでないポートを選択します。 ログイン後、想定したアカウントを確認します。 プライベートキーパスフレーズプロンプトがローカルキーをロック解除します。リモートアカウントのパスワードプロンプトとは異なるです。
鍵が拒否された場合、正しいアカウントを指定し、登録した公開鍵がクライアントで選択した秘密鍵と対になっているか確認してください。公開鍵の保存場所、所有者、アクセス権も確認します。一般的なOpenSSHのアカウントでは、.sshを700、authorized_keysを600などの制限されたアクセス権に設定すると、他のユーザーによる認証ファイルの変更を防げます。所有者は対象のアカウントである必要があります。
クライアントの診断とサーバー認証ログを調べます。 サーバポリシーは、ユーザー、キータイプ、認証の組み合わせを制限できます。 拒否されたキーの作業を行わないよう、権限を広げないでください。 プライベートキーではなく、ヘルプを求めるときに赤字のエラーメッセージを共有したり、機密診断ログを完成させます。
ワーキングキーは、サーバーパスワードポリシーを自動的に変更しません。 認証設定を変更する場合は、メインのOpenSSH設定とアカウントに影響する含まれているファイルを確認してください。 パスワード認証とキーボード相互認証は別々の設定であり、オペレータポリシーまたはマッチブロックは有効な結果を変更できます。
関連する設定をバックアップし、変更を適用する前にインストールされたデーモンで検証します。 sudo sshd -t は、コマンドと特権が適用されるシステム上の OpenSSH 構文チェックです。 配布のために文書化されたサービス管理メソッドを使用します。 元のセッションを閉じる前に、変更後に別の新しいキー接続を開いて証明してください。
各管理者に独自のキーを付与して、アクセス変更はプライベートファイルを共有する必要はありません。 デバイスを交換するときは、新しい公開鍵を最初にインストールしてテストし、それを識別した後、古い公開鍵のエントリを削除します。 紛失したパスフレーズは暗号化されたプライベートキーから復元できません。 作業許可されたアクセス方法を使用して置換を作成します。
チームメンバーの葉やデバイスが失われたときにキーを確認します。 公開鍵のエントリを削除することで、そのエントリを通じて将来のキーのログインを防止しますが、アクティブなセッションやその他のアクセス方法も見直します。 承認された回復手順をサービスレコードに保管してください。アクセスは、交換するデバイスに完全に依存しません。