dropbearsshサーバーが'接続できません

ルーターへの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を使用してルーターにダウンロードし(ダウンロードしたファイルが所有者/グループとしてrootになるように)、アクセス許可を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). 

mドキュメント( GitHubリポジトリ)の内容を誤解している:

サーバー公開鍵認証:

OpenSSHの場合と同じように〜/ .ssh / authorized_keysを使用できますが、そのファイルにキーエントリを入力するだけです。次の形式にする必要があります:

ssh- RSA AAAAB3NzaC1yc2EAAAABIwAAAIEAwVa6M6cGVmUcLl2cFzkxEoJd06Ub4bVDsYrWvXhvUV + ZAM9uGuewZBDoAqNKJxoIn0Hyd0Nk / yU99UVv6NWV / 5YSHtnf35LKds56j7cuzoQpFIdjNwdxAN0PCET / MG8qyskG / 2IE2DPNIaJ3Wy + Ws4IZEgdJgPlTYUBWWtCWOGc =誰か@ホスト名

このあなたが確認する必要がありますそれの〜/ .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サーバーに接続できます。

dropbearconvert openssh dropbear id_rsa id_rsa.db 

これを試して、機能するかどうかを確認します。しかし、とにかく、サーバーの公開鍵認証は機能するはずです。

コメント

  • dropbear ssh server / configはrootログインを許可しますか?いくつかのsshサーバーでは、デフォルトでセキュリティのためにルートログインが許可されていません。
  • そうだと思いますが、’ (ホストキーのみ)、それを禁止するパラメーターは-w(使用しない)です。
  • 質問の編集:手順に従って、sshキーをドロップベアに変換しました。キーと何もありません(最初の回答からIpor Sircerが指摘しました)。
  • githubリポジトリでドキュメントが見つかりました(’報告できません。問題は有効になっていません) 。質問が再度編集されました。まだ同じ問題:(

回答

簡単な回答:おそらくOpenWrtを実行しているので、次のようにする必要があります。 /root/.ssh/authorized_keysではなく/etc/dropbear/authorized_keysの公開鍵。

長い答え:

GitHubあなたが指摘するリポジトリは、dropbearの作者によって維持されているものです。~/.ssh/authorized_keysは機能し、GitHubによると、少なくとも14年間は機能しているとのことです。 div id = “afb87f4326”>

svr-authpubkey.c 「pw_dir」に/.ssh/authorized_keysを追加します。

ただし、 、あなたと同じ問題があり、OpenWrt18.06.1で提供されているバイナリが実際に /etc/dropbear/authorized_keysを開いていることを発見しました。そのファイルを使用するとうまくいきます。

この動作は、 OpenWrtドキュメントに記載されています。

では、どうしてですか?

上記のコードではそのファイル名を単独で生成できない場合(.sshがありません)、 .sshシンボリックリンクはどこにもありません。バイナリでstringsを実行しました。これは、GitHubコードから期待できる%s/.ssh/authorized_keysの直前に、/etc/dropbear/authorized_keysが明示的に言及されていることを示しています。 OpenWrtバイナリは同じソースからコンパイルされていないと結論します…実際、OpenWrtはアップストリームコードにこのパッチをパッチします。ターゲットユーザーがrootである場合(およびその場合のみ)、/etc/dropbear/authorized_keysに使用されるファイルを変更します。

opkg、OpenWrtも使用していると思いますが、これが問題です。質問にOpenWrtタグを追加しました。

回答

authorized_keysはファイルであり、ディレクトリではありません。

authorized_keysファイルの例:

 # Comments allowed at start of line ssh-rsa AAAAB3Nza...LiPk== [email protected] from="*.sales.example.net,!pc.sales.example.net" ssh-rsa AAAAB2...19Q== [email protected] 

http://man.he.net/man5/authorized_keys

.ssh/およびその中のすべてのファイルは、ユーザー(この場合はroot)のみが所有し、読み取り可能である必要があります。

コメント

  • 修正したばかりですが、まだ運がありません:((更新された質問を参照)。

回答

man dropbearkeys:

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 

コメント

  • 秘密鍵を変換できましたが、それでもうまくいきませんでした:((更新された質問を参照)。

回答

dropbearkeyツールを使用してsshキーを作成する必要があります。RSA_KEYFILE= / etc / dropbear / dropbear_rsa_host_key DSS_KEYFILE = / etc / dropbear / dropbear_dss_host_key

dropbearkey -t dss -f $ DSS_KEYFILE

dropbearkey -t rsa -f $ RSA_KEYFILE

次に、dropbearデーモンを再起動します。接続を試みると、機能するはずです。

回答

DropbearでPKIを使用して接続するのに役立つ可能性のあるいくつかのポインター。これは、OpenSSHクライアントから接続するAlpine Linux3.12パッケージに基づくコンテナーをテストしました。

  1. ユーザーにはシェルが必要です。
  2. ユーザーには必要ありません。ログインパスワードが必要です。
  3. ユーザーの~ グループ/世界で書き込み可能(つまり、 chmod 755少なくとも;ホームディレクトリには700を使用する必要があります。
  4. ユーザーの~/.sshおよび~/.ssh/authorized_keys は、所有者のみがアクセスできる必要があります(例:700、ファイルに600)。
  5. が必要書き込み可能な/tmpディレクトリ
  6. authorized_keysエントリは使用されているものと同じ形式ですOpenSSHによる。

私は高山のパッケージから厳選されたファイルを使用してコンテナを作成しています。上記の要件がすべて満たされている限り、SSHで接続できる最大2MBの画像があります。

回答

I dropbearを介してサーバーに接続することが突然機能しなくなった理由を探しているときに、この質問に出くわしました(数か月間機能していましたが、数週間ごとにたまにしか使用されていません)。

解決策/説明i最終的に見つかったのは、メッセージdebug1: send_pubkey_test: no mutual signature algorithmで、クライアントのssh接続の試行の冗長性が増したため、ビットバケットのトラブルシューティング記事

その記事では、 RSAアルゴリズムは、さまざまなセキュリティの脆弱性[…] が原因で、オペレーティングシステムとSSHクライアント間ですぐに非推奨になり、考えられる回避策がリストされています。いずれか:

  • PubkeyAcceptedKeyTypes +ssh-rsaをクライアントのcfgファイルに追加します(これは一時的な回避策はpoteであるため本質的に安全ではありません!)

  • ECDSAまたはED25519アルゴリズム/キーを使用します。現在、私のシステムにドロップベアバージョンが存在するため、ED25519でドロップベア側で不明なアルゴリズムエラーが発生したため、ECDSAをのみ使用できました。

これが誰かがこの質問に出くわすのに役立つことを願っています。私が難しいことをしたので、おそらく元の質問の解決策ではありません、pls。許してください。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です