あなたが座っているマシンでキーを生成する
サーバー上ではありません。秘密鍵の半分は、アクセスを失う可能性のあるホストに存在してはならず、コピーして回ることは、鍵を持つ意味を損なう。
ssh-keygen -t ed25519 -a 100 -C "laptop-2026"-a 100 はパスフレーズを保護する KDF ラウンド数を設定します。これは、盗まれたラップトップとあなたのフリートの間に立つ唯一のものです。パスフレーズを使用してください。ハードウェアトークンをお持ちの場合は、代わりにそれを使用してください:
ssh-keygen -t ed25519-sk -O resident -C "token-1"公開鍵をインストールする
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@<ipv4>手動で、root セッションから、アカウントにまだパスワードがない場合:
install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
install -m 600 -o deploy -g deploy /dev/null /home/deploy/.ssh/authorized_keys
cat >> /home/deploy/.ssh/authorized_keys1 行を貼り付けて、Ctrl-D を押します。パーミッションは人々が期待する以上に重要です: sshd はグループ書き込み可能なホームディレクトリまたは .ssh ディレクトリを拒否し、その理由をクライアントには決して説明せず、デーモンのログにのみ説明します。
キーを制限する
authorized_keys のオプションはキーごとに適用されます。restrict はすべてを無効にし、その後、キーが本当に必要とするものを追加します:
restrict,pty ssh-ed25519 AAAAC3Nza... deploy@laptop1 つのジョブを実行するために存在するキーは、1 つのジョブを実行することが許可されるべきです:
restrict,command="/usr/local/bin/backup-receive" ssh-ed25519 AAAAC3Nza... backupロックする前にテストする
最初のセッションを接続したままにします。2 番目のターミナルから:
ssh -o PreferredAuthentications=publickey deploy@<ipv4> idそれがあなたの uid を出力すれば、キーパスは機能します。そうでない場合、クライアントの ssh -vvv とサーバーの journalctl -u ssh -n 50 が、どちらの側が問題かを示します。およそ半分はパーミッションで、残りのほとんどは間違ったユーザー名です。
パスワードを無効にする
cat > /etc/ssh/sshd_config.d/20-keys-only.conf <<EOF
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no
AuthenticationMethods publickey
EOF
sshd -t && systemctl reload sshAuthenticationMethods publickey は吊り革の下のベルトです。後でドロップインがパスワードを静かに再び有効にしても、デーモンはキー以外のものはすべて拒否します。
クライアントからドアが閉まっていることを確認します:
ssh -o PreferredAuthentications=password deploy@<ipv4>期待される結果は Permission denied (publickey) です。
デプロイ時のキー
パネルはアカウントごとにキーリストを保持しています。必要なものをオンにすると、cloud-init が最初の起動時にそれらを書き込みます。つまり、インスタンスはパスワード認証をすでにオフにして初めて存在できます。キーを注文に添付すると、上記の 10 分が 1 分になります。
キーを失った場合
ここではアイデンティティベースのリカバリはありません。なぜなら、私たちはアイデンティティを保持していないからです。帯域外コンソールが戻る道です: それは sshd に触れないパスでインスタンスに到達し、レスキューシェルから新しいキーを追加して続行できます。
2 台目のマシンに 2 つ目のキーを保持しておけば、その記事を読む必要はありません。