パスワードなしの認証でSSH DSAキーが機能しなくなりました


25

Fedora 23にアップグレードした後、パスワードなし(公開鍵ベース)認証はSSHで機能しなくなりました。あるホストにSSHしようとすると、リモートホストでパスワードの入力を求められます。SSH秘密鍵を使用することができません。すべてがFedora 22で正常に機能しました。

私の公開キーはDSAキー(~/.ssh/id_dsa.pub)です。OpenSSH 7.1(openssh-7.1p1-5.fc23.x86_64)を使用しています。

パスワードなしの認証を再度正常に機能させるにはどうすればよいですか?



1
ありがとう、@ dave_thompson_085。これはsuperuser.com/q/962918/93541の duではありません。その質問は使い方を尋ねていますssh -Q。これは、SSHの障害のトラブルシューティング方法を尋ねています。superuser.com/q/962918/93541やその他の場所でこのソリューションを特定するのに役立つ資料を見つけましたが、そこのssh -Q答えはこの質問の使い方を説明しており、この質問には答えません(たとえば、修正方法の説明はありません)この問題)、だから私の見解では、それは二重ではありません。UnixとLinuxの場合非常に似ています。私は以前にそれを見たことを望みます。リンクをありがとう。
DW

ええ、あなたは正しいです。私はそれらを両方とも「OpenSSH 7.0 no DSA」としてブックマークしましたが、前者の場合は十分ではありません。ごめんなさい。
dave_thompson_085

回答:


40

これは、OpenSSH 7.0へのアップグレードの結果です。通りのOpenSSH 7.0と言うのリリース・ノート、「SSH-DSSのホストとユーザーのキーのサポートは、実行時にデフォルトで無効になっています」。

解決策は~/.ssh/config、すべてのクライアントマシン(SSHクライアントを実行するすべてのマシン)に次の行を追加することです。

PubkeyAcceptedKeyTypes=+ssh-dss

サーバーがOpenSSH 7.0以降を使用している場合は、各サーバーマシンにこの行を追加する必要があり/etc/ssh/sshd_configます。

または、まったく新しいSSHキーを生成し、ログインするすべてのサーバー上のauthorized_keysファイルに追加することもできます。 互換性の問題を避けるために、RSAを使用することをお勧めします。明らかにgnome-keyring-daemonはタイプECDSAのSSHキーを自動的に取得しないため、ECDSAはお勧めしません


編集者のコメント:OpenSSHの人々がDSAキーを無効にしたのはなぜですか?知りません。私が確認できる限り、DSAキー(ssh-dss)のセキュリティに問題はありません。OpenSSHのウェブページのssh-DSSは弱いですが、私の知る限り承知しているとして、1024ビットのssh-DSSは、1024ビットのRSAよりも弱いではありません、1024ビットのRSAキーが無効になっていないことを主張。


1
キータイプの選択については、しばらくの間セキュリティで説明されています。DSAキーのセキュリティは最初から疑わしく、優れたランダムジェネレーターがない場合は安全性が低下します(これは確認できません)。また、使用できるキータイプは他にもあるため、疑わしいキータイプを保持する理由はありません。
Jakuje

2
@Jakuje、はい、キータイプの選択については、情報セキュリティについてここここで説明します。私は編集上のコメントを書く前にそれらすべてを読みましたが、DSAキーが無効にされた理由には戸惑っています。同じ長さのRSAキーは無効ではありません。これらのスレッドには、DSAが「疑わしい」ことを示すものは何もありません。ThomasPorninが言うように、「十分なキーを想定して、あるタイプを他のタイプよりも優先するセキュリティ関連の理由はありません」。(続き)
DW

詳細については、こちらをご覧ください。
DW

0

私の2セント

これ.ssh/configを許可するためにファイルを編集するのはあまり良い考えではないようなので、私は提案します

  1. 最近のツールを使用して、新しいキーを作成します。

    次に、新しい公開キーを(クリップボードに)コピーします

  2. 古いキーを使用して最後にもう一度ログインします。

    ssh -i .ssh/id_dsa.pub -o PubkeyAcceptedKeyTypes=+ssh-dss user@host
    

    次に、新しいpubkeyとログアウトを追加して、@hostauthorized_keysファイルをアップグレードします

    cat >>.ssh/authorized_keys
    

    paste、次にCtrl+D

  3. デフォルトの構文を使用して、新しいキーでログを記録します。

    ssh user@host
    
    1. 次に、古いpubkeyを削除して、@hostauthorized_keysファイルをアップグレードします(古いpubkeyがこのファイルの行にあるときに使用します)。sed -e 1d -i .ssh/authorized_keys1

    2. 可能であれば、sshサーバーをアップグレードすることをお勧めします。

    3. ログアウト
  4. 古いキーが機能しなくなったかどうかをテストします。

    ssh -i .ssh/id_dsa.pub -o PubkeyAcceptedKeyTypes=+ssh-dss user@host
    ...
    Permission denied...
    

    これは動作しません;-)

  5. すべてが正常かどうかを再確認することもできます。

    ssh user@host uptime
    

編集が~/.ssh/configそれほど良いアイデアではないと思う理由は私には明らかではありません。
DW

これは非推奨であり、ssh作成者は使用しないことを推奨しているためです。openssh.com/legacy.html
F.ハウリ

ああ、わかりました。あなたの懸念は、~/.ssh/configそれ自体を編集するという考えではなく、DSAを許可するという考えにあるようです。説明してくれてありがとう。それは理にかなっている。(この勧告が不可解であると思う理由についてはすでに回答コメントで対処している思いますが、ここではそれについて議論しようとはしません。)
DW

編集.configを行うsshと、長時間実行することができ、弱いアルゴリズムを使用していることを忘れてしまいます。-o Pubkey...コマンドラインで使用することにより、アップグレードするものがあることを許しません。
F.ハウリ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.