Невозможно выполнить ssh для запуска dropbear sshd. "Попытка неверного пароля" ... Но пароль верный

По какой-то причине мне говорит работающий DropBear sshd в контейнере Docker. Bad password attempt, хотя я дважды проверял, что имя пользователя и пароль верны на 100%.

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', чтобы предотвратить сохранение множества различных ключей, сгенерированных во время тестирования / сборки файла Docker)

..ш, как и ожидалось, дает мне:

Отпечаток ключа ECDSA: SHA256:0WadKddpa*[..blabla.]* Вы уверены, что хотите продолжить подключение (да / нет)?

Затем меня попросили ввести пароль. Но могу ли я напечатать или вставить это, 100% правильно.. Я все еще получаю Permission denied, please try again. и dropbear регистрирует попытку с Bad password attempt for 'mysticbbs' from 172.17.0.1:35152..

  • Я пытался установить другой / более сложный пароль
  • Попытка ssh с dbclient изнутри контейнера, с тем же пользователем, под которым работает dropbear, и запуск dropbear без использования supervisord не имеет значения. (Bad password attempt for 'mysticbbs' from 127.0.0.1:48110) ..
  • Папка /etc/dropbear (и ключи) преобразуются в 'mysticbbs:mysticbbs' и chmod в 700
  • Та же проблема возникает независимо от того, использую ли я dropbear из apk репо Alpine (v2018.76-r2) или соберите его из источника dropbear.nl (протестированы как v2018.76, так и v2017.75)..
  • Удаление ключей и запуск дропбэра вручную с помощью -R аргумент не имеет значения.
  • Нашел нотацию по адресу https://github.com/mkj/dropbear, но я не понимаю, как это можно применить, поскольку пользователь попытался выполнить ssh, совпадает с тем, который запускает dropbear:

>

Если сервер запущен как не-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

Что мне не хватает?..

1 ответ

Решение

Как указано Michael Hampton в комментарии и примечании на https://github.com/mkj/dropbear:

Если сервер запущен как не-root, вы, скорее всего, не сможете выделить pty, и вы не сможете войти в систему под любым другим пользователем, кроме того, который запускает демон (очевидно). Теневые пароли также будут непригодны для использования без полномочий root.

Кажется, мои проблемы действительно возникают при теневых паролях при запуске dropbear от имени пользователя без полномочий root.

В моем конкретном случае, под alpine: 3.9 / BusyBox, мне кажется более приемлемым решение и обходной путь для добавления root в мою группу ' mysticbbs ' и удаления привилегий root по мере необходимости, а не make /etc/shadow доступный для пользователя, отличного от root (например, путем добавления mysticbbs или выделенного системного пользователя в теневую группу (?)). Я даже не собираюсь это проверять. Хотя, полагаю, это также может быть потенциальный обходной путь.).

РЕДАКТИРОВАТЬ: Добавление пользователя, под которым запускается dropbear shadow группа просто кажется проще.. а ведь /etc/shadow все еще chmod 640 (доступно для записи только пользователю root, но доступно для теневой группы)

ls -la /etc/shadow 

-rw-r ----- 1 root shadow 503 Feb 6 16:33 / etc / shadow

(Примечание: вероятно, не рекомендуется в тех случаях, когда высокий уровень безопасности является главным приоритетом)

Другие вопросы по тегам