信頼できないVPNで、あなたのSSHパスワードを実際に見るのは誰か

自分で運用していないVPNにSSHセッションを通しても、パスワードはあくまでSSHサーバーのもので、途中のネットワークのものではありません。検証済みのホストへの通信が適切に保護されていれば、その経路上の受動的な観測者がパスワードを読める形で手に入れることはありません。しかし条件が一つ変われば答えも変わります。未検証のホスト、弱められた暗号の一覧、侵害された作業端末は、それぞれ別の結果を生みます。以下の確認を順に行い、どれも中断条件として扱ってください。

何かを打つ前に宛先を名指しする

パスワード欄は認証メッセージの中を流れ、そのメッセージは暗号化された通信の中を流れます。機密性は通信の性質であり、保護が交渉されていること、そして意図したホストと交渉されていることに依存します。人々が飛ばすのはまさにその後半です。詐称者に対して暗号化された接続は、機密でありながら同時に無意味です。VPNへのログインはSSHホストについて何も証明せず、事業者の評判は鍵の確認の代わりになりません。

二つの向きを頭の中で分けてください。ホスト鍵が答えるのは、どのサーバーに到達したかです。パスワードや鍵による認証が答えるのは、サーバーがどのユーザーを受け入れるかです。後者を改善しても前者は決して直りません。

ホストの身元、記録、交渉を確認する

クライアント側で、すでに手元にある記録から始めます。信頼できる出所と照合した公開指紋と、まだ一致しているknown_hostsの項目が、認証が始まる前に意味を持つ唯一の証拠になります。

ssh-keygen -F ssh.internal.example.net -f ~/.ssh/known_hosts
ssh -o StrictHostKeyChecking=yes ssh.internal.example.net

サーバー側では、公開する予定の指紋を記憶から写すのではなく出力してください。それを経路の外で配ることが要点です。ホスト名と同じチャット経路から貼られた指紋は、両方が同じ場所から来たことしか証明しません。

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
sudo sshd -T | grep -E 'hostkey|kexalgorithms|cipher'

交渉されるアルゴリズムは双方の共通部分から決まります。クライアント設定が古い機器に届くために旧式の鍵交換を固定しているなら、その選択は通信するすべてのホストに適用されるので、全体ではなくそのホストに限定してください。

サーバーが実際に受け入れる方式を読む

サーバーがどの認証方式を許すかを知ると、パスワードが何のためのものかが分かります。公開鍵だけを受け入れるホストには守るべきパスワード交換がなく、いまもパスワードを受け入れるホストは、引き継がれた既定値ではなく意図的な判断に値します。

sudo sshd -T | grep -E 'passwordauthentication|pubkeyauthentication|permitrootlogin'

利用者を鍵認証へ移すと、その利用者のパスワードはその交換から外れます。それは侵害された作業端末を安全にはせず、信頼できない遠隔セッションを無害にもしません。別の管理策を要する別のリスクです。エージェント転送についても決めてください。信頼できないホストへエージェントを転送すると、セッションの間そのホストがあなたの鍵を使えるようになり、これは発端となったパスワードの問いより大きな露出です。

ホスト鍵の警告はインシデントの手順として扱う

クライアントがホストの識別が変わったと警告したら、止まって、同じネットワーク経路を通らない別の経路で確認します。指紋をサーバーのコンソールか、再構築した運用者と照合してください。警告を黙らせるために古い項目を消すことだけは拒むべき行動です。証拠を捨て、傍受の可能性を通常のログインに変えてしまいます。

ホストが正当に再構築されたのなら、新しい指紋が確認できてから古い項目を削除し、そのうえで再接続して交渉を再確認します。変更は日付と理由を添えて記録してください。次に見る人は同じ警告を見るので、解決済みだと知る必要があります。

この手引きが扱わないこと

通信を眺めるVPN事業者は、あなたの機械でローカル権限を持つソフトウェアとは同じではありません。端末の侵害、敵対的なブラウザ拡張、キーボード記録器は、SSHが交渉できるものすべての下に位置し、どんなトンネルもそれを変えません。作業端末が疑わしいなら、別の出口で再接続して秘匿性を試すのではなく、インシデント手順に従ってください。再接続が証明するのは経路が変わったことであり、端末については何も証明しません。

最後はありふれた場合です。検証済みのホスト、保護された通信、意図して選んだ認証方式、不要な転送をしないこと。この組み合わせが表題の問いへの答えであり、それは一つではなく四つの判断です。