最近、ワークステーションFedora 31をFedora 34にアップグレードしました。通常はアップグレード後に発生するため、一部のSSHアルゴリズムは廃止され、.ssh / configに追加の行を追加する必要があります。安全のために最善を尽くすことに同意します。
今回はssh-rsaという用語が私を混乱させました。たとえば、Debian 10、Debian 8、および Cisco 4k ルータに対して openssh クライアントに権限を付与する以前の RSA 公開鍵があります。
アップグレード後、PubkeyAcceptedKeyTypes +ssh-rsaほとんどの古いホストに対して.ssh / configに追加する必要があります。この場合、Debian 8およびCisco 4kルータになります。これで以前のようにログインできます。ただし、Cisco 4k は次のメッセージを記録します。
Public-key Algorithm compliance violation detected.Kindly note that weaker Public-key Algorithm 'ssh-rsa' will be disabled
私の質問は次のとおりです。
- Cisco 4kがssh-rsaより高いPKを許可している場合、デフォルトのSSH設定が利用できないのはなぜですか？
- キータイプ"ssh-rsa"と許可されたPKアルゴリズムの間に接続がありますか？たとえば、公開鍵タイプは、許可されるアルゴリズムを鍵長などに制限しますか?
- この認証は常にssh-rsaと呼ばれますが、設定に手動で追加する必要がある場合、デフォルトではどのような実際のPK認証が使用されますか？ ssh-rsa型か別の型ですか？
- パスワードと同様に、サーバーとクライアントがどのPKアルゴリズムをサポートしているかを明確に理解する方法はありますか（Sshデバッグとsshdデバッグを試みました）。
修正する:
Cisco 4kルータに関する新しい情報：シスコはデフォルトでホストキーアルゴリズムをサポートしています：rsa-sha2-512、rsa-sha2-256、ssh-rsa
これを追加してPubkeyAcceptedKeyTypes +rsa-sha2-512ログインできますが、まだssh-rsaに関する警告が表示されます。
rsa-sha2-512を一種のssh-rsaと考えてください（どちらも最近opensshからダンプされたためです）。他の質問は次のとおりです。
- ルータ宣言は、ssh-rsaをrsa-sha2-512を含むすべての種類のssh-rsaとして扱うようです。
- ルータで有効になっているホストキーアルゴリズムが他の方法で制限されているように見えますか？
ベストアンサー1
背景として...
このトピックに良い答えがありますセキュリティスタック交換opensshへのリンクssh-rsa サポートの中止に関するガイドライン。
問題はもともとssh-rsaアルゴリズムのようです（RFC 4253に記載されている）頼るSHA-1これで暗号化の場合、デフォルトでは消えました。
2005年以来、SHA-1は資金が十分な敵に効果的ではないと考えられており、2010年現在、多くの組織がそれらを交換することをお勧めします。 NISTは2011年に正式にSHA-1を使用しなくなり、2013年にデジタル署名の使用を禁止しました。 2020年現在、SHA-1に対する選択されたプレフィックス攻撃が可能です。
ただし、鍵自体ではなく SHA-1 署名アルゴリズムが使用されます。
これを念頭に置いて...
Cisco 4kがssh-rsaより高いPKを許可している場合、デフォルトのSSH設定が利用できないのはなぜですか？
変更点は、opensshがデフォルトでssh-rsaを許可しないことです。あなたが行った変更は顧客によって受け入れられますssh-rsa。したがって、ルータはまだそれを受け入れます（うめき声が出ても）。しかし、アルゴリズムの厳格な階層はなく、一部のアルゴリズムが他のアルゴリズムよりも「優れている」だけです。したがって、「より高い」アルゴリズムを許可しても、ルーターとクライアントが同じ「より高い」アルゴリズムを共有するという意味ではありません。
別の考えられる理由は、クライアントとルーターの両方が「より良い」アルゴリズムを共有しているが、元のRSAキーと互換性がないためです。たとえば、SSH証明書を受け入れますが、キーはありますが、証明書はありません。この場合、デフォルト設定を使用できますが、既存のキーをデフォルト設定として使用することはできません。
キータイプ"ssh-rsa"と許可されたPKアルゴリズムの間に接続がありますか？
私がそのテーマについて見つけたところによると、そうです。彼らのアルゴリズムは単一に制限することができます。パスワードしかし、一般的にキーの長さにはあまり気にしません。キーは基本的に[一部]非常に大きい数です。サイズは重要ではありませんが、アルゴリズムはそれをどのように処理するかを知る必要があります。
パスワードと同様に、サーバーとクライアントがどのPKアルゴリズムをサポートしているかを明確に理解する方法はありますか（Sshデバッグとsshdデバッグを試みました）。
やや難解ですが、-vvopensshレベル2のデバッグ（）で達成できます。あなたは見ることができますdebug2: KEX algorithms: ...とdebug2: host key algorithms: ...。また、どのアルゴリズムが選択されているかを確認する必要があります。-vvvさらに詳しく知りたい場合は、3番目のレベルのデバッグ（）もあります。