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
в конце лога клиента есть перечень находимого/не_находимого сервером перед отказом в коннекте.
(Временная тема) Статическая сборка dropbear 2018.76
-
adm_
- Сообщения: 13
- Зарегистрирован: 02 мар 2018, 06:23
kaztost,
прикол.
https://pastebin.com/0iwMeQLa
перегрузился, снова отлинковал /etc и засимлинковал на /opt/etc, новый дропбеэ привычно не пустил, passwd root на тот же самый пароль, снова коннект к новому дропбеэ из того же терминала - и я в дамках.
что скопировать в /system/etc из нынешнего /etc (скриптом в init.d?), чтоб это счастье сохранилось?
я правильно понимаю, что проблема в несохраняющемся между перезагрузками пароле рута? или причины/дело в чём-то другом?
прикол.
https://pastebin.com/0iwMeQLa
перегрузился, снова отлинковал /etc и засимлинковал на /opt/etc, новый дропбеэ привычно не пустил, passwd root на тот же самый пароль, снова коннект к новому дропбеэ из того же терминала - и я в дамках.
что скопировать в /system/etc из нынешнего /etc (скриптом в init.d?), чтоб это счастье сохранилось?
я правильно понимаю, что проблема в несохраняющемся между перезагрузками пароле рута? или причины/дело в чём-то другом?
-
kaztost
- Сообщения: 223
- Зарегистрирован: 16 июл 2017, 23:29
adm_, а теперь найдите отличия в этих пастах. Обе заканчиваются датой May 07 09:25:47. Что вы хотите?
В любом случае, после того как вы выложили первый лог (кажется там то же самое было, но сейчас смотреть туда опять не хочется), вам указали про проблему /etc/shells. Зачем вам надо было выкладывать опять эти простыни просто так полностью. Надо было ясно сказать, что проблема осталась - вот соответствующий кусок лога. А не повторять вопрос про ключ, игнорируя наши слова.
Боюсь придется сделать вывод, что вы проблему решать не хотите. А мне смотреть еще ваши простыни без адекватных самостоятельных нормальных комментариев уже совсем не хочется. На трех устройствах у меня сервер работает. Этого уже вполне достаточно, чтобы предварительно считать, что проблем нет. Если же есть, разберитесь и скажите, что надо исправить.
В любом случае, после того как вы выложили первый лог (кажется там то же самое было, но сейчас смотреть туда опять не хочется), вам указали про проблему /etc/shells. Зачем вам надо было выкладывать опять эти простыни просто так полностью. Надо было ясно сказать, что проблема осталась - вот соответствующий кусок лога. А не повторять вопрос про ключ, игнорируя наши слова.
Боюсь придется сделать вывод, что вы проблему решать не хотите. А мне смотреть еще ваши простыни без адекватных самостоятельных нормальных комментариев уже совсем не хочется. На трех устройствах у меня сервер работает. Этого уже вполне достаточно, чтобы предварительно считать, что проблем нет. Если же есть, разберитесь и скажите, что надо исправить.
-
kaztost
- Сообщения: 223
- Зарегистрирован: 16 июл 2017, 23:29
Код: Выделить всё
$ diff -s strace.log strace2.log
Файлы strace.log и strace2.log идентичны
Вопрос закрыт.
-
adm_
- Сообщения: 13
- Зарегистрирован: 02 мар 2018, 06:23
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, то могу пересобрать сам (какие строки искать/править уже однозначно).
ещё раз простите за вчерашнюю глупейшую неаккуратность с логами.
простите, моя ошибка, т.к. первый лог перекинул на карточку в надежде, что при отсутствии файла 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
- Сообщения: 223
- Зарегистрирован: 16 июл 2017, 23:29
adm_ писал(а):Источник цитаты если Вы дадите musle'евский тулчейн х86_64 -> armv7-a, то могу пересобрать сам (какие строки искать/править уже однозначно).
Я же писал выше, что собираю нативно, и, следовательно кросс-компилятора х86_64 -> armv7-a у меня нет. Мне так удобнее, тем более ставится вся шняга на андроид-устройстве очень просто https://wiki.alpinelinux.org/wiki/Insta ... n_a_chroot + "apk add alpine-sdk"
Тема закрыта и со временем будет удалена с частичным переносом. Все новые сообщения здесь будут удаляться. Если есть вопросы - их можно задать в другой подходящей (или новой) теме.
-
kaztost
- Сообщения: 223
- Зарегистрирован: 16 июл 2017, 23:29
Что-то затянули с обновлением 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 с разными префиксами. Теперь можно получить нормальный консольный доступ с правами любой андроид-проги, в которой есть возможность запускать скрипты.
Добавлю, наоборот, свое баловство: статически собранный под 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
- Сообщения: 223
- Зарегистрирован: 16 июл 2017, 23:29
Итак, Dropbear 2018.76 не будет в Entware и OpenWRT, поскольку
Будем надеяться, что в OpenWRT с новой версией не затянут.
Все файлы в этой ветке убрал, поскольку пользоваться ими немного опасно - CVE-2018-15599. Как и termux-ным dropbear - там нет отдельных патчей от CVE-2018-15599, пока не обновят версию.
UPD. Разработчики Termux в этом молодцы - уже обновили. Другое дело - они иногда слишком с обновлениями спешат в некритичных ситуациях.
Код: Выделить всё
~ # dropbear -V
Dropbear v2019.77
Будем надеяться, что в OpenWRT с новой версией не затянут.
Все файлы в этой ветке убрал, поскольку пользоваться ими немного опасно - CVE-2018-15599. Как и termux-ным dropbear - там нет отдельных патчей от CVE-2018-15599, пока не обновят версию.
UPD. Разработчики Termux в этом молодцы - уже обновили. Другое дело - они иногда слишком с обновлениями спешат в некритичных ситуациях.
-
Александр Рыжов
- Сообщения: 433
- Зарегистрирован: 12 авг 2015, 13:14
- Откуда: Смоленск
-
kaztost
- Сообщения: 223
- Зарегистрирован: 16 июл 2017, 23:29
Я не спец по безопасности, но возможно 2017.75 это тоже касается (я думал, что нет)
Отсюда - https://lists.ucc.gu.uwa.edu.au/piperma ... 02108.html
Может критично, может в реалиях Entware устройств и не так критично.
Думаю, патч - https://git.alpinelinux.org/aports/tree ... 5599.patch
применим и к более древним версиям
Этот патч полностью вошел в 2019.77
Код: Выделить всё
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
Вернуться в «Entware на Android»
Кто сейчас на конференции
Всего 1 посетитель :: 1 зарегистрированный, 0 скрытых и 0 гостей (основано на активности пользователей за последние 5 минут)
Больше всего посетителей (162) здесь было 16 ноя 2019, 17:33
Сейчас этот форум просматривают: CommonCrawl [Bot] и 0 гостей