(Временная тема) Статическая сборка dropbear 2018.76

[adm_]

kaztost,
я не ошибся, этот лог - последний (и первый незаархивированный, т.к.предназначен был для пэйстбина, а не для аттаченья).
$ ls -lFa |grep strace
-rwxr-x--- 1 admz admz 52239 май 7 13:25 strace1.log*
-rw-r--r-- 1 admz admz 6702 май 7 13:25 strace1.log.zip
-rwxr-x--- 1 admz admz 52239 май 7 18:34 strace2.log*
-rw-r--r-- 1 admz admz 6702 май 7 18:35 strace2.log.zip
-rwxr-x--- 1 admz admz 52239 май 7 19:59 strace3.log*
-rwxr-x--- 1 admz admz 52239 май 7 13:00 strace.log*
-rw-r--r-- 1 admz admz 6700 май 7 13:06 strace.log.zip

в конце лога клиента есть перечень находимого/не_находимого сервером перед отказом в коннекте.

[adm_]

kaztost,
прикол.
https://pastebin.com/0iwMeQLa

перегрузился, снова отлинковал /etc и засимлинковал на /opt/etc, новый дропбеэ привычно не пустил, passwd root на тот же самый пароль, снова коннект к новому дропбеэ из того же терминала - и я в дамках.
что скопировать в /system/etc из нынешнего /etc (скриптом в init.d?), чтоб это счастье сохранилось?
я правильно понимаю, что проблема в несохраняющемся между перезагрузками пароле рута? или причины/дело в чём-то другом?

[kaztost]

adm_, а теперь найдите отличия в этих пастах. Обе заканчиваются датой May 07 09:25:47. Что вы хотите?

В любом случае, после того как вы выложили первый лог (кажется там то же самое было, но сейчас смотреть туда опять не хочется), вам указали про проблему /etc/shells. Зачем вам надо было выкладывать опять эти простыни просто так полностью. Надо было ясно сказать, что проблема осталась - вот соответствующий кусок лога. А не повторять вопрос про ключ, игнорируя наши слова.

Боюсь придется сделать вывод, что вы проблему решать не хотите. А мне смотреть еще ваши простыни без адекватных самостоятельных нормальных комментариев уже совсем не хочется. На трех устройствах у меня сервер работает. Этого уже вполне достаточно, чтобы предварительно считать, что проблем нет. Если же есть, разберитесь и скажите, что надо исправить.

[kaztost]

Код: Выделить всё

$ diff -s strace.log strace2.log
Файлы strace.log и strace2.log идентичны

Вопрос закрыт.

[adm_]

kaztost,
простите, моя ошибка, т.к. первый лог перекинул на карточку в надежде, что при отсутствии файла strace начнёт писать файл заново и не надо будет перегружать погремушку, а команду scp c карточки повторял стрелкой вверх на автомате в отдельном табе терминала, не смотря, что ж делаю.
...м.б. ещё виной и сильный недосып...

/data/local/entware/root # rm /opt/root/strace.log
/data/local/entware/root # mount -o remount,rw /
/data/local/entware/root # unlink /etc
/data/local/entware/root # ln -s /opt/etc /etc
/data/local/entware/root # mount -o remount,ro /
/data/local/entware/root # /system/xbin/strace -f -v -o /opt/root/strace.log /opt/bin/dropbear -p 443 -W 1024
[6862] May 08 01:00:03 Failed loading /etc/dropbear/dropbear_dss_host_key
[6862] May 08 01:00:03 Failed loading /etc/dropbear/dropbear_ecdsa_host_key
[6864] May 08 01:00:03 Running in background
[6932] May 08 01:01:10 Child connection from 192.168.1.2:51586
[6932] May 08 01:01:43 Password auth succeeded for 'root' from 192.168.1.2:51586

$ diff -q strace.log strace6.log
Files strace.log and strace6.log differ

https://pastebin.com/bUtH6ftt

м.б. в этом дело?

/data/local/entware/root # diff -s /opt/etc/shells /system/etc/shells
Files /opt/etc/shells and /system/etc/shells are identical

/data/local/entware/root # diff -s /opt/etc/passwd /system/etc/passwd|grep root
-root:x:0:0:Root:/opt/root:/opt/bin/ash
+root:x:0:0::/data/local/cron:/system/bin/sh

скажите, что надо исправить

по-хорошему, стоило б:
1) возвернуть новую версию к жизни внутри /opt, как было раньше т.к. сейчас серверу при старте требуется проверить серверные ключи в ./ssh (а не в /opt/etc/dropbear как было раньше), а потом при логине проверять /etc (а не /opt/etc, как было раньше) и /root (a не /opt/root, как было раньше).
2) прописать дефолтовое значение ключа -W в 1024, чтоб не надо было набирать ручками.

я засимлинковал вышеперечисленные директории в скрипте init.d в соответствии с пожеланиями новой версии и успешно логинюсь по паролю, но по ключу пока зайти не могу.

АПДЕЙТ: [13765] May 08 06:33:40 Pubkey auth succeeded for 'root' with key sha1!! 15:84:98:24:36:e1:98:e0:f9:3b:ba:ca:c8:73:67:55:88:a8:25:88 from 192.168.1.2:53242
если Вы дадите musle'евский тулчейн х86_64 -> armv7-a, то могу пересобрать сам (какие строки искать/править уже однозначно).

ещё раз простите за вчерашнюю глупейшую неаккуратность с логами.

[kaztost]

Источник цитаты если Вы дадите musle'евский тулчейн х86_64 -> armv7-a, то могу пересобрать сам (какие строки искать/править уже однозначно).

Я же писал выше, что собираю нативно, и, следовательно кросс-компилятора х86_64 -> armv7-a у меня нет. Мне так удобнее, тем более ставится вся шняга на андроид-устройстве очень просто https://wiki.alpinelinux.org/wiki/Insta ... n_a_chroot + "apk add alpine-sdk"

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

[kaztost]

Что-то затянули с обновлением dropbear в OpenWRT. Поэтому данную ветку пока не удаляю.

Добавлю, наоборот, свое баловство: статически собранный под armv7 (hard float) мутант-dropbear с заложенными в нем относительными путями вместо абсолютных:
1. Ключи сервера берутся в папке etc/dropbear относительно текущей директории, при этом демонизация сервера происходит без смены текущей директории на /
2. При авторизации используются файлы etc/passwd, etc/shadow и etc/shells относительно той-же текущей директории
3. После авторизации дочерний процесс попадает в свою домашнюю папку (в соответствии с etc/passwd). Поэтому при SFTP должен быть бинарь или симлинк bin/sftp-server относительно этой домашней папки.
4. Окружение в дочернем процессе не очищается, Роль DEFAULT_PATH играет унаследованная от родителя переменная PATH.

Сделал все это для себя - надоело компилить libc+dropbear с разными префиксами. Теперь можно получить нормальный консольный доступ с правами любой андроид-проги, в которой есть возможность запускать скрипты.

[kaztost]

Итак, Dropbear 2018.76 не будет в Entware и OpenWRT, поскольку

Код: Выделить всё

~ # dropbear -V
Dropbear v2019.77

Будем надеяться, что в OpenWRT с новой версией не затянут.

Все файлы в этой ветке убрал, поскольку пользоваться ими немного опасно - CVE-2018-15599. Как и termux-ным dropbear - там нет отдельных патчей от CVE-2018-15599, пока не обновят версию.

UPD. Разработчики Termux в этом молодцы - уже обновили. Другое дело - они иногда слишком с обновлениями спешат в некритичных ситуациях.

[Александр Рыжов]

Мы затянули из OpenWrt себе dropbear с какой-то критической дыркой?
Или по ссылке просто нет патчей к этой верии?

[kaztost]

Я не спец по безопасности, но возможно 2017.75 это тоже касается (я думал, что нет)

Код: Выделить всё

The user enumeration issue in OpenSSH [0] also exists in Dropbear 2018.76
and earlier; at least going back to w/v2013.58

Отсюда - https://lists.ucc.gu.uwa.edu.au/piperma ... 02108.html

Может критично, может в реалиях Entware устройств и не так критично.

Думаю, патч - https://git.alpinelinux.org/aports/tree ... 5599.patch
применим и к более древним версиям

Этот патч полностью вошел в 2019.77