web-dev-qa-db-ja.com

実行中のdropbearsshdにsshできません。 「不正なパスワードの試行」...しかし、パスワードは正しい

何らかの理由で、Dockerコンテナで実行しているdropbear sshdが、ユーザー名とパスワードの両方が100％正しいことを何度も再確認したにもかかわらず、Bad password attemptと言っています。

Dropbearは、次のコマンドを使用してsupervisordによって開始されています。

/ usr/local/sbin/dropbear -F -E -p 2222

ユーザーとグループによる「mysticbbs」。 dropbearの実行時にエラーは発生しません。

ただし、ホストコンピューターからコンテナーにSSHで接続しようとすると、次のようになります。

ssh -o UserKnownHostsFile =/dev/null localhost -l mysticbbs -p 2222

（ '-o UserKnownHostsFile =/dev/null'、dockerfileのテスト/ビルド中に生成された多くの異なるキーの保存を防ぐため）

..sshは、予想どおり、次のようになります。

ECDSAキーの指紋はSHA256：0WadKddpa * [.. blabla。] *です。接続を続行してもよろしいですか（はい/いいえ）。

次に、パスワードの入力を求められます。しかし、100％正しく入力するか、貼り付けるかどうかに関係なく、まだPermission denied, please try again.を取得し、dropbearはBad password attempt for 'mysticbbs' from 172.17.0.1:35152で試行をログに記録します。

  • 別の/より複雑なパスワードを設定してみました
  • 同じユーザーdropbearが実行されている状態で、コンテナー内からdbclientを使用してsshを実行しようとしても、supervisordを使用せずにdropbearを実行しても違いはありません。 （Bad password attempt for 'mysticbbs' from 127.0.0.1:48110）..
  • / etc/dropbearフォルダー（およびキー）は「mysticbbs：mysticbbs」にchownされ、chmodは700にchownされます。
  • 同じ問題は、Alpineのapkリポジトリ（v2018.76-r2）のdropbearを使用するか、dropbear.nlソース（v2018.76とv2017.75の両方をテスト済み）..
  • キーを削除し、-R引数を指定してdropbearを手動で実行しても違いはありません。
  • https://github.com/mkj/dropbear で表記が見つかりましたが、ユーザーがでsshを試みたのと同じであるため、どのように適用できるかわかりませんドロップベアを実行しているものとして：

>>

サーバーがroot以外で実行されている場合、ptyを割り当てることができない可能性が高く、デーモンを実行しているユーザー以外のユーザーとしてログインすることはできません（明らかに）。シャドウパスワードもroot以外として使用できなくなります。

  • シャドウパスワードが原因である可能性があります..

キーは、Dockerのビルド中に次のように生成されます。

   export RSA_KEYFILE=/etc/dropbear/dropbear_rsa_Host_key
   export DSS_KEYFILE=/etc/dropbear/dropbear_dss_Host_key
   export ECDSA_KEYFILE=/etc/dropbear/dropbear_ecdsa_Host_key
   dropbearkey -t dss -f $DSS_KEYFILE
   dropbearkey -t rsa -f $RSA_KEYFILE
   dropbearkey -t ecdsa -f $ECDSA_KEYFILE
   chown -R mysticbbs:mysticbbs /etc/dropbear
   chmod -R 700 /etc/dropbear

mysticbbsユーザーのパスワードは、Dockerのビルド中に次のように設定されます。

   passwd mysticbbs -d '<password>' -u

何が足りないのですか？..

linuxsshdockeralpinedropbear
1
DhP

コメントの @ michael-hampton と、 https://github.com/mkj/dropbear のメモで指摘されているように：

サーバーがroot以外で実行されている場合、ptyを割り当てることができない可能性が高く、デーモンを実行しているユーザー以外のユーザーとしてログインすることはできません（明らかに）。 シャドウパスワードもroot以外として使用できなくなります。

私の問題は、root以外のユーザーとしてdropbearを実行しているときに、shadow passwordsで実際に発生するようです。

私の特定のケース 、Alpine：3.9/BusyBoxの下、 rootを 'mysticbbs'グループに追加し、必要に応じてroot権限を削除する方が、より有効な解決策と回避策のようです。 、root以外のユーザーが/etc/shadowにアクセスできるようにするのではなく（たとえば、「mysticbbs」または専用のシステムユーザーを追加することにより、 to'shadow 'group（？）..私はそれをテストするつもりはありません。それも潜在的な回避策になる可能性があると思いますが。）。

編集：dropbearが実行されているユーザーをshadowグループに追加するのは簡単なようです。結局のところ /etc/shadow はまだです chmod 640 （rootユーザーのみに書き込み可能、​​ただしには読み取り可能）シャドウグループ）

ls -la /etc/shadow

-rw-r ----- 1ルートシャドウ503Feb 6 16:33/etc/shadow

（注：高セキュリティが最優先事項である場合はおそらくお勧めしません）

0
DhP