Denis_____

Так если сделать сертификаты, то весь трафик будет в TLS завернут не?

В общем-то да, но не особо просвещенные пользователи могут и admin-ом подключаться к transmission, более просвещенные - создадут отдельно admin, отдельно - regularUser, с доступом не только к торрентам, а, например, еще и ftp. Если там только basic, можно, например как-нибудь заблокировать права доступа - чтобы не было одновременно доступа к transmission и к настройкам ОС. Обновился до 2.13 - да, там можно сделать сертификат и все будет очень здорово. Встроенный ftp в NDMS (Pure FTPD, насколько я понял) - не поддерживает SNI -> нельзя иметь доступ к FTP из внешнего мира? Но в настройках есть пункт "Разрешить доступ из Интернета" - при любом его значении я могу подключиться внутри локальной сети к серверу ftp. Видимо, этот чекбокс все-таки влияет на внешний интернет за NAT-ом, как это работает в transmission. Но сделать так, чтобы он работал, не получилось. Это возможно или нет?

Так, а если я запущу какой-нибудь WebUI на каком-нибудь порту с HTTP.1/1, чтобы он эмулировал терминал и все это было достаточно секьюрно? есть похожие готовые решения?

(С) Википедия. Тут видимо либо был какой-то баг, либо меня пытались mitm-нуть. .cap я естественно не сохранил. Хотя сейчас попробовал - (внимание!) transmission всегда работает по basic. Это вот вообще никуда не годится, типа есть у меня HDD на кинетике, я хочу управлять торрентами, а в итоге ими управляет кто хочет, потому что basic. Причем, он делает это по HTTP/1.1! Скриншот во вложении. Поискал, нашел ничего. Можно поподробнее? Насчет 3 вопроса - понятно. То есть вообще никакими средствами не получится сделать из маршрутизатора мини-debian server? Подойдут любые варианты

По запросу myname.mykeenetic.com:443 (порт для https) страница не грузится. По http-запросу на 80 порт - да, digest-auth со всеми этими , причем иногда все же сбрасывается до basic auth (трафик смотрел wireshark-ом). Трафик с мобильного приложения не ловится (странно), по этому поводу ничего сказать не могу. Идея начет SSL - круто, только у меня версия 2.08 (последняя). Бета-канал тоже не выбирается, говорит 404. Насчет ssh - понятно, но разве облако не просто проксирует sshAccess.keeneticName.mykeenetic.com: -> 192.168.1.1:22, где sshAccess - доменное имя 4 уровня, настроенное во вкладе KeenDNS? Как тогда иначе работает эта фича? PS: учитывая скорость перебора md5 на гпу и ограничение в 32 символа на пароль, digest auth не особо и лучше basic-а

1. Как я понял, если ISP выдает серый IP адрес есть возможность пройти за NAT к маршрутизатору через DyDNS, в частности - встроенный KeenDNS. Его я настроил, все работает. Вопрос в том, что подключение идет на 80 порт -> авторизация там basic, просто в base64 кодируются login:password. Достаточно перехватить пакет авторизации и данные учетки утекут. Получается, что при работе через мобильное приложение тоже используется такая система? Если да, то как переопределить такое поведение - кроме как поднять VPN только для этой цели, это слишком накладно будет. 2. Вопрос связан с предыдущим: если настроить проброс портов в KeenDNS для, например, transmission, встроенного в NDMS, то соединение инициируется тоже через 80 порт и тоже через Basic Autorization. Вопрос как переопределить, если это возможно. 3. Тоже связанный вопрос: поставил Debian в OPKG, настроил проброс на 22 порт кинетика в KeenDNS, но подключиться не могу. То есть клиентский ssh видит, что соединение открыто, но через какое-то время "Connection closed by foreign host". В локалке все нормально работает если подключиться к 192.168.1.1:22 PS: если зайти с браузера на URL ssh-а, то всегда было "не могу открыть страницу", кроме 1 раза, тогда было вот что: То есть протокол браузер даже увидел.