Невозможно выполнить 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
(Примечание: вероятно, не рекомендуется в тех случаях, когда высокий уровень безопасности является главным приоритетом)