☰

dropbear SSHサーバーに接続できません

tag-icon • tag-icon linux ssh openwrt key-authentication dropbear
dropbear SSHサーバーに接続できません

SSH経由でルーターにアクセスしようとしています。現在はTelnetアクセスのみ可能で、dropbearをインストールして実行しています（ルーターに接続されたUSBドライブのopkgを使用）。

最初から私がしたことは、秘密鍵を生成してそれを解読したこと（dropbearはまだそれをサポートしていないため）と公開鍵だけでした。

cd .ssh
openssl genrsa -des3 -out id_rsa
openssl rsa -in id_rsa -out id_rsa
ssh-keygen -y -f id_rsa > authorized_keys

authorized_keys公開鍵（）をにアップロードしました/root/.ssh。私はファイルをApacheサーバー（私のローカルコンピュータ）に入れ、wgetを使ってルーターにダウンロードし（ダウンロードしたファイルの所有者/グループがルートである）権限を0600（クライアントでも同じですが）に変更しました。私のユーザーと）。

アクセスしようとすると、「許可拒否（公開鍵）」エラーが発生します。

$ ssh -v -i ~/.ssh/id_rsa [email protected]
OpenSSH_7.4p1, OpenSSL 1.0.2j  26 Sep 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 192.168.1.1 [192.168.1.1] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/chazy/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/chazy/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version dropbear
debug1: no match: dropbear
debug1: Authenticating to 192.168.1.1:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha1 compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha1 compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-rsa SHA256:1EFA75uwLp+4hBW0t3aaY05QjLzYd4jjDWoULAzF/8o
debug1: Host '192.168.1.1' is known and matches the RSA host key.
debug1: Found key in /home/chazy/.ssh/known_hosts:1
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/chazy/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

私が文書を誤って読んでいない限り（GitHubリポジトリ）説明する：

サーバー公開鍵の確認：

OpenSSH のように ~/.ssh/authorized_keys を使用できます。そのファイルにキー項目を入れます。形式は次のようにする必要があります。

ssh-rsaAAAAB3NzaC1yc2EAAAABIwAAAIEAwVa6M6cGVmUcLl2cFzkxEoJd06Ub4bVDsYrWvXhvUV+ZAM9uGuewZBDoAqNKJxoIn0Hyd0Nk/yU99UV d jNwdxAN0PCET/MG8qyskG/2IE2DPNIaJ3Wy+Ws4IZEgdJgPlTYUBWWtCWOGc=someone@hostname

~/.sshファイルとキーファイルは、ユーザーのみが書き込み可能であることを確認する必要があります。エディタがキーを複数行に分割することに注意してください。

Dropbearはauthorized_keysエントリのいくつかのオプションをサポートしています。マンページを参照してください。

原はやったが、どこが問題なのか分からない。

ドキュメントには他の方法が記載されています。

クライアント公開鍵認証：

Dropbearはクライアントとして公開鍵認証を実行できますが、OpenSSHスタイルキーをDropbear形式に変換するか、dropbearkeyを使用して生成する必要があります。

OpenSSHスタイルの秘密鍵~/.ssh/id_rsaがある場合は、次のことを行う必要があります。

dropbearconvert openssh dropbear ~/.ssh/id_rsa ~/.ssh/id_rsa.db dbclient -i ~/.ssh/id_rsa.db

Dropbearは暗号化されたホストキーをサポートしていませんが、ssh-agentに接続できます。

つまり、秘密鍵を dropbear 秘密鍵に変換すると、dropbear クライアントを使用して dropbear サーバーに接続できます。

dropbearconvert openssh dropbear id_rsa id_rsa.db

私はそれを試して、それが動作していることを確認しようとしています。ただし、とにかくサーバー公開鍵認証は機能する必要があります。

答え1

短い答え：おそらくOpenWrtを実行してい/etc/dropbear/authorized_keysます/root/.ssh/authorized_keys。

長い答え：

あなたが指すGitHubリポジトリはdropbearの作者によって維持されており、~/.ssh/authorized_keysGitHubによると、少なくとも14年間維持されてきました。コードを見るsvr-authpubkey.c/.ssh/authorized_keys「pw_dir」に追加されます。

しかし、私はあなたと同じ問題に直面し、OpenWrt 18.06.1で提供されているバイナリが次のようになることがわかりました。実際に開かれる/etc/dropbear/authorized_keys。このファイルを使用すると私に役立ちました。

この動作は次に文書化されています。OpenWrt ドキュメント。

どうやってそのようなことが起こりますか？

上記のコードがそのファイル名を独自に生成できず（見つからない）、.sshどこにも.sshシンボリックリンクがないことを考慮してstringsバイナリを実行しました。これは、予想されるGitHubコードで/etc/dropbear/authorized_keys以前にこれが明示的に言及されたことを示します。%s/.ssh/authorized_keys私の結論は、OpenWrtバイナリが同じソースでコンパイルされていないことです。実際、OpenWrtは以下を使用してアップストリームコードをパッチしました。今回のパッチ。/etc/dropbear/authorized_keysターゲットユーザーがrootの場合にのみ使用されるファイルを変更します。

あなたが言及したので、opkgあなたもOpenWrtを使用していると仮定し、それがあなたの問題です。あなたの質問にOpenWrtタグを追加しました。

答え2

dropbearを介して私のサーバーに接続することが突然機能しない理由を探している間、私はこの問題に直面しました（数ヶ月間働きましたが、数週間に一度だけ働きました）。

最後に見つかった解決策/説明は、debug1: send_pubkey_test: no mutual signature algorithmクライアントSSH接続試行に長いメッセージを追加することでした。ビットバケットのトラブルシューティングドキュメント。

その記事が言及されました。さまざまなセキュリティの脆弱性により、RSAアルゴリズムはオペレーティングシステムとSSHクライアントですぐに廃止されました[...]理由を説明し、考えられる解決策をリストします。

  • クライアントcfgファイルに追加PubkeyAcceptedKeyTypes +ssh-rsa(このファイルは次の目的にのみ使用)一時的な解決策安全ではないかもしれないからです！ )

  • ECDSAまたはED25519アルゴリズム/キーを使用してください。これでシステムにdropbearバージョンがあるので、次のことができます。ただED25519でECDSAを使用すると、私に不明なアルゴリズムドロップベアがあるバグ。

私のように、この問題で苦しんでいる人たちにこれが役立つことを願っています。これは元の問題に対する解決策ではないかもしれません。許す

答え3

男はクマの鍵を置きます。

NOTES
       The program dropbearconvert(1) can be used to convert between  Dropbear
       and OpenSSH key formats.

       Dropbear does not support encrypted keys.

EXAMPLE
       generate a host-key:
        # dropbearkey -t rsa -f /etc/dropbear/dropbear_rsa_host_key

       extract a public key suitable for authorized_keys from private key:
        # dropbearkey -y -f id_rsa | grep "^ssh-rsa " >> authorized_keys

答え4

PKIを使用してDropbearに接続するのに役立ついくつかのヒントは、OpenSSHクライアントから接続するAlpine Linux 3.12パッケージベースのコンテナをテストしました。

  1. ユーザーにはシェルが必要です。
  2. ユーザーにはログインパスワードは必要ありません。
  3. ユーザー~ 必然ではないグループ/完全書き込みは可能ですか（つまり、少なくともホームディレクトリchmod 755に使用する必要があります）。700
  4. ユーザー~/.sshと~/.ssh/authorized_keys 〜しなければならない所有者だけがアクセスできます（700ディレクトリや600ファイルなど）。
  5. そこ〜しなければならない/tmp書き込み可能なディレクトリです。
  6. これらのauthorized_keys項目の形式は OpenSSH で使用される形式と同じです。

私はalpineパッケージで慎重に選択したファイルを使ってコンテナを作成しています。上記のすべての要件が満たされている限り、SSH経由でアクセスできる約2MBのイメージがあります。

関連情報