OmegaTron
-
Posts
228 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by OmegaTron
-
-
13 часа назад, VladimirTs сказал:
а можешь примером кода поделиться? Хочу то же самое на powershell сделать. Та да проблема.
Проверьте ЛС, отправил.
9 часов назад, VladimirTs сказал:Привет, а можно на код посмотреть? Сделал не Powershell, но где-то ошибка:
С PowerShell я никогда не работал, увы. Но тем не менее, ошибка мне видится тут
9 часов назад, VladimirTs сказал:Token:'SHNNEMKBAPROMVCZHVVSXMWBDRPLUDHG' Realm:'ZyXEL Keenetic Ultra' ToMD5:'admin:ZyXEL Keenetic Ultra:aabbcc' HashMD5:'CF67093EBBF9F768A853D56BEFB747D9' Tosha256:'SHNNEMKBAPROMVCZHVVSXMWBDRPLUDHG' Sha256:'DB7027E420608ACD3EECC82A647425F7F2A97C72857E2B3A4585A4F0FA95D56F'
вы загоняете challenge (token) в sha256 а нужно загонять исходный $challenge + $login:$realm:$pass в md5 и всё без пробелов и одной строкой.
-
На 2.11.C.0.0-2 в netfilter.d были добавлены правила и с тех пор успешно работали. После обновления на 2.13.C.0.0-1 в логах наблюдаю такие строки
ndm: Opkg::Manager: /opt/etc/ndm/netfilter.d/001iptables: exit code 1. ndm: Opkg::Manager: /opt/etc/ndm/netfilter.d/001iptables: iptables: Invalid argument. Run `dmesg' for more information.
В шапке скрипта 001iptables добавлено
[ "$type" == "iptables" ] && exit 0 [ "$table" != "filter" ] && exit 0 xxx xxx
где xxx - правила. При запуске из баша скрипт отрабатывает нормально, правила что им, что вручную добавляются нормально.
В чём затык ? dmesg посмотреть не успел. Сам скрипт, судя по добавленным при старте правилам вполне себе отрабатывает.
-
Сейчас к слову помониторил - авторизация через веб-фейс фиксируется 100%, а вот к /ci как-то непонятно, через раз. Пока системы не понял ибо мониторил недолго.
11 час назад, stefbarinov@mail.ru сказал:И ещё какая-то абра-кадабра отображается, скрин прилагаю.
Это id сессии, которая была авторизована.
-
В 29.10.2018 в 23:07, dvg_lab сказал:
Версия ПО 2.13.C.0.0-3, и у меня все пашет, проверено на Ultra - II, где-то что-то все же не учитывается. Куку обязательно сохранять и пихать ее в ответном пакете, аккуратно со всеми \n, перепроверять хеши...
Перед тем как сегодня отписаться, начал перепроверку кода под микроскопом (всмысле с отладкой) и таки была замечена пара просчётов - md5sum выполнялся без обрезки мусора после выхлопа, а printf в realm из-за пробелов выдавал только первый блок. Разбираться с экранированием буду позже (ибо с printf манипуляций меньше), пока вернулся назад к echo и обрезке \n через tr -d "\n". Теперь наконец всё работает и ответ от роутера "HTTP/1.1 200 OK" ))) C куками к слову всё было в порядке, просто глаз замылился и я в упор не видел ошибку
-
1 час назад, dvg_lab сказал:
Значит никаких проблем с авторизацией в 2.13 нету.
Не факт. eralde писал об аналогичных проблемах, что и у меня. У вас какой билд ? У меня юзается экспериментальная сборка 2.13.C.0.0-1
1 час назад, dvg_lab сказал:Мои предположения почему у тебя не получается: когда ты генеришь на баше json, ты это делаешь с первоначальной кукой (токеном), которую ты получил тем же curl'ом, а когда запускаешь curl второй раз, с уже якобы готовым json'ом, то у тебя по факту уже новая сессия и новая кука (токен), а нужно чтобы сессия не разрывалась и пихалась в ответ та кука которая пришла в этой сессии.
Нет с куками я тоже пробовал.
В 18.10.2018 в 09:56, OmegaTron сказал:upd: При дополнительной отправке куки сессии полученной в первоначальном get-запросе html-выхлопа не происходит, только в ответных хедерах вылезает 401-я ошибка.
Единственный момент, который я не учёл - это было использование echo при генерации хэша, который давал \n на конце и делал кэш не валидным. К сожалению, его замена на printf не привела к желаемому результату - роутер всё равно шлёт меня лесом при авторизации, в том числе с куками (специально сегодня перепроверял разные варианты авторизации после замены echo на printf). Как буду дома - скину скрипт для проверки
-
В 26.10.2018 в 16:23, dvg_lab сказал:
Я все это делал на перле, curl не умеет в новую авторизацию. Не знаю каким образом он может собрать это:
curl не может, но на баше через md5sum и sha256sum можно сгенерировать всё необходимое и потом всё это отправить curl'ом json как data в post запросе. Если интересует, могу скинуть свой скрипт.
Только на 2.13 от него нет проку. Там для авторизации требуется что-то ещё.
-
Ну так ЧЯДНТ ???
-
Спасибо, логгирование авторизации снова включилось.
-
Может я что-то упустил, но вроде раньше при авторизации через браузер или при обращении к ci я видел в логах строки об проведённой аутентификации. Теперь там тишина
Хотя возможно я путаю - у меня параллельно стоит оригинальный Keenetic, который при авторизации сразу отсылает в syslog и по сети уведомление об авторизации. Так что возможно, мне просто показалось, что Омни так же делал. Ежели показалось, то не лишним было бы подобное запилить.
Сессия длительностью в 10 минут, новая схема авторизации, а банального учёта логинился ли кто - нет.
-
1
-
-
В 16.10.2018 в 20:33, eralde сказал:
Авторизация теперь работает так:
Так, то ли лыжи не едут, то ли я
ЦитатаX-NDM-Challenge: ZGENTERUUDCKTARJNNYYNLFLSSCITQVO
X-NDM-Realm: ZyXEL Keenetic Omni IIДанные без хэширования
ZGENTERUUDCKTARJNNYYNLFLSSCITQVOadmin:ZyXEL Keenetic Omni II:aaabbbccc123
X-NDM-Challenge + хэш второго блока в md5
ZGENTERUUDCKTARJNNYYNLFLSSCITQVO5da4a889c4a614daff93dcd11c0734e4
и наконец всё это добро в sha256
672b1977d3daed6538c0fb73cf597b384f4cd96814578ca1dc0d3aa26b982bf9
Отправляю
curl -sv "http://192.168.1.15:10080/auth" -X POST -H "Content-Type: application/json" --data-binary '{"login":"admin","password":"672b1977d3daed6538c0fb73cf597b384f4cd96814578ca1dc0d3aa26b982bf9"}'получаю в отладке
< HTTP/1.1 400 Bad Request HTTP/1.1 400 Bad Request
и аналогичный html-выхлоп
<html> <head> </head> <body> <h1>400: Bad Request</h1> </body> </html>
Ну и где я ошибся ?
p.s. Оригинальный пароль другой и все манипуляции проводились именно с ним, а "aaabbbccc123" - просто пример, с которым я провёл те же манипуляции. С оригинальным паролем была именно 400-я ошибка - Bad Request. Все манипуляции выполнялись под никсами, дабы исключить какие-либо проблемы с кросскомпилированными бинарниками.
upd: При дополнительной отправке куки сессии полученной в первоначальном get-запросе html-выхлопа не происходит, только в ответных хедерах вылезает 401-я ошибка.
-
2 часа назад, eralde сказал:
http://cmder.net/ -- выглядит как хорошая штука, на мой взгляд.
По иронии, буквально на днях познакомился с данной сборкой. Согласен, вещь хорошая - синтез conemu и clink. Т.к. функционала последнего уже перестало хватать, пришлось искать альтернативу.
Добавьте кнопку "Выйти" в веб-интерфейсе.
Понятно. Хотели как лучше, а получилось как всегда )))
где есть wget/curl и всякие другие штуки, не могу вспомнить где и что брал.
С этим проблем нет. Я беру бинарники либо из набора unxtools, либо использую cygwin'овский загрузчик под win для загрузки чего-то специфического.
-
1 час назад, eralde сказал:
Раньше была digest-авторизация. Теперь -- не digest
Понятно. Просто обычно я имел дело с basic-авторизацией, а если попадался digest, то все проблемы решались дополнительным ключём для curl'a и в дебри отладки не лез, если только не попадалось что типа такого
После того как полез увидел по заголовкам нечто напоминающее digest и "завис" ...
1 час назад, eralde сказал:А для тех, кто знает слова digest и curl -- вроде несложно.
Не то чтобы сложно, просто это дополнительный гемморой, который неясно по какой причине появился и который предстоит решать.
1 час назад, eralde сказал:На вопросы по ndmq я ответить не могу. Что вы хотите сделать? Какой-то скрипт для пакетного применения настроек?
Скрипт, но не применения настроек, а для получения и обработки определённых данных с роутера
1 час назад, eralde сказал:Можно написать на любом скриптовом языке. В Windows 10 вроде даже нормальный терминал завезли.
10-ку я не перевариваю, уж не обессудьте ? максимум 7-ка
1 час назад, eralde сказал:Наверняка есть бинарники самых распространенных утилит из linux.
Высчитать хэш не проблема. Просто придётся изобретать дополнительный велосипед для того, что и так уже ранее работало.
***
К слову, с my.keenetic.net каменный цветок так и не вышел
Цитатаcurl -s --digest --user xxx:xxx "http://78.47.125.180:10080/rci/show/interface?name=PPPoE0" -H "Content-Type: application/json"
<html>
<head><title>401 Authorization Required</title></head>
<body bgcolor="white">
<center><h1>401 Authorization Required</h1></center>
<hr><center>Web server</center>
</body>
</html>curl -s --digest --user xxx:xxx "http://my.keenetic.net:10080/rci/show/interface?name=PPPoE0" -H "Content-Type: application/json"
<html>
<head><title>401 Authorization Required</title></head>
<body bgcolor="white">
<center><h1>401 Authorization Required</h1></center>
<hr><center>Web server</center>
</body>
</html>так что займусь велосипедом ...
-
Авторизация теперь работает так:
ОК ! Спасибо
Буду эксперементировать. Я упустил realm + не знал, алгоритм генерации хэша (думаю, это простительно, если учитывать тот момент, что с прямой digest-авторизацией я до этого не имел дела).
Я так понимаю, все эти меры безопасности связаны с тем, что идентичный метод авторизации использует приложение для смартфонов ? Иначе я просто не понимаю, к чему такие сложности на домашнем роутере )))
Судя по количеству манипуляций, под windows получится явно громоздкая конструкция, а это целевая система
Никсы на подхвате на vbox. Функционал для работы с rci будет включён в ndmq ?
Ну и раз уж пошёл разговор про ndmq, существуют ли готовые сборки для cygwin под win (сам я профан в кросс-компиляции) ?
Если 2.13 будет стабильная как танк и выдержит аптайм в месяц - два, буду пользоваться еюНо, если судить по тому, что новый интерфейс вам не нравится -- имеет смысл переключиться на legacy (2.11.D) Последняя 2.11, которой я пользовался (2.11.C.0.0-2), падала раз в пару дней. Судя по ченджлогу, с того момента многое исправили, но пока проверять стабильность не хочется. Если фейс и ещё какие-то моменты окончательно задолбают - перейду на 2.11.D
-
24 минуты назад, eralde сказал:
ОК. Спасибо. Проверять вариант с my.keenetic.net буду завтра, как роутер будет в зоне доступа. Теперь ясно когда всё поломалось.
ЦитатаПодсмотреть как именно происходит авторизация можно в коносоли разработчика браузера. Либо напишите мне в личку.
Я смотрел кстати, только толку от этого было ноль, ибо слишком хитро всё теперь сделано. Там идёт post-запрос с отправкой json'a с логином и паролем в виде 64-х значного криптованного хэша (или типа того), который при каждой новой авторизации перегенеривается, после чего отдаётся кука сессии и браузер получает-принимает запросы. Вот только воспроизвести это curl'ом не получается. Вместо "хэша" (?) я пробовал совать реальный пароль, но на выходе получал не то bad request (400), не то 401 без html, в ответных хедерах. Думается мне, что нужна отправка именно "хэша", вот только я не в курсе алгоритма его генерации.
-
О проблеме я уже отписывался в соседней теме, но там этот вопрос проигнорировали. При запросе rci с digest-авторизацией на 2.13.C.0.0-1 веб-сервер роутера шлёт лесом
curl -s --digest --user xxx:xxx "http://192.168.1.15:10080/rci/show/interface?name=PPPoE0" -H "Content-Type: application/json" <html> <head><title>401 Authorization Required</title></head> <body bgcolor="white"> <center><h1>401 Authorization Required</h1></center> <hr><center>Web server</center> </body> </html>
при отправке запроса к ci (xml) всё отрабатывает, при отправке запроса к rci с кукой сессии из браузера - всё работает. На ранее юзаемой 2.11.C.0.0-2 с rci проблем не было.
Не работает digest-авторизация для rci
in 2.13
Posted
Спасибо. Пригодится, когда буду осваивать PoweShell и начну с ним работать всерьёз