☰

无法通过 ssh 进入正在运行的 dropbear sshd。“密码尝试错误”...但密码正确

tag-icon • tag-icon linux ssh docker alpine dropbear
无法通过 ssh 进入正在运行的 dropbear sshd。“密码尝试错误”...但密码正确

出于某种原因，我在 Docker 容器中运行的 dropbear sshd 告诉我Bad password attempt，尽管我多次检查用户名和密码是否 100% 正确。

supervisordDropbear通过以下命令启动：

/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。

  • 我尝试设置不同的/更复杂的密码
  • 尝试dbclient从容器内部使用 ssh，使用与 dropbear 相同的用户运行，并且在不使用 supervisedd 的情况下运行 dropbear，没有任何区别。（Bad password attempt for 'mysticbbs' from 127.0.0.1:48110）..
  • /etc/dropbear 文件夹（和密钥）的所有者被更改为 'mysticbbs:mysticbbs'，并且 chmod 被更改为 700
  • 无论我是否使用dropbear来自 alpine 的 apk repo，都会出现同样的问题（v2018.76-r2）或者从 dropbear.nl 源构建（已测试 v2018.76 和 v2017.75）..
  • 删除键并手动运行带有-R参数的 dropbear 没有任何区别。
  • 发现一个符号https://github.com/mkj/dropbear，但我不明白这如何适用，因为用户试图通过 ssh 进入是一样的就像运行 dropbear 一样：

>

如果服务器以非 root 用户身份运行，您很可能无法分配 pty，并且您无法以除运行守护进程的用户之外的任何用户身份登录（显然）。影子密码也将无法以非 root 用户身份使用。

  • 影子密码可能就是罪魁祸首......

密钥是在 docker build 期间生成的，如下所示：

   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 build 期间设置的：

   passwd mysticbbs -d '<password>' -u

我错过了什么？

答案1

正如所指出的@迈克尔·汉普顿在评论中，以及https://github.com/mkj/dropbear：

如果服务器以非 root 身份运行，您很可能无法分配 pty，并且您无法以除运行守护进程的用户之外的任何用户身份登录（显然）。影子密码也将无法使用，因为非 root 用户。

我的问题似乎确实出现在影子密码以非 root 用户身份运行 dropbear 时。

在我的具体情况， 在下面高山：3.9/BusyBox，对我来说，这似乎是一个更有效的解决方案和解决方法根对我的'神秘论坛' 组，并根据需要删除 root 权限，而不是让/etc/shadow其他用户能够访问根 （例如，将“mysticbbs”或专用系统用户添加到“影子”组（？）..我甚至不会测试这一点。不过我猜这也可能是一种潜在的解决方法。）。

编辑：将运行 dropbear 的用户添加到shadow组似乎更容易。毕竟/etc/shadow还是chmod 640（可写入根仅限用户，但可读阴影团体）

ls -la /etc/shadow

-rw-r----- 1 根影子 503 2 月 6 日 16:33 /etc/shadow

（注：在安全性要求较高的场合可能不建议这么做）

相关内容