В рамках проекта ssh-chat (https://github.com/shazow/ssh-chat) подготовлена довольно необычная реализация чата, автор которой предлагает (https://medium.com/@shazow/ssh-how-does-it-even-9e43586...не ограничиваться использованием SSH для организации удалённого доступа, а также применять SSH и для других задач, воспользовавшись уже готовыми и проверенными средствами аутентификации и шифрования.
Приложение для организации работы чата оформлено в виде специализированного SSH-сервера, который позволяет использовать для подключения любой SSH-клиент, но вместо доступа к терминалу, выводит интерфейс чата. Похожим способом предлагается поступать и для других областей применения, например, SSH можно применять для создания работающей поверх SSH распределённой хэш-таблицв (DHT), разработки многопользовательских игр (MUD (https://ru.wikipedia.org/wiki/%D0%9C%D0%... организации шифрованных каналов связи между приложениями (для этих целей уже развивается библиотека Duplex (https://github.com/progrium/duplex)), обращения к RPC API через SSH ("ssh api.example.com multiply a=4 b=5") и даже обеспечения доступа к HTTP по SSH (предлагается использовать соединение к web-серверу по SSH как альтернативу HTTPS).
<center><a href="https://pbs.twimg.com/media/B4wmkzwCIAAj33U.png"><... src="https://www.opennet.ru/opennews/pics_base/0_1420277396.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>URL: https://medium.com/@shazow/ssh-how-does-it-even-9e43586...
Новость: https://www.opennet.ru/opennews/art.shtml?num=41389
Был бы ещё gate в IRC, я бы прямо сегодня запустил бы.
SILC
Мне нужен именно IRC.
> Мне нужен именно IRC.Ну так по идее пропихать IRCшное соединение не поверх ssl а поверх ssh ничему не противоречит. Наверное можно при сильном желании даже голыми руками изобразить. Осталось придумать - нафига.
Ну я и работаю в irssi to localhost in screen over ssh. Но эта штука мне нужна для других пользователей, а не для себя.
> Ну я и работаю в irssi to localhost in screen over ssh.
> Но эта штука мне нужна для других пользователей, а не для
> себя.По идее точно так же, только сделать для них юзера со специфическими ограничениями ssh.
>> Ну я и работаю в irssi to localhost in screen over ssh.
>> Но эта штука мне нужна для других пользователей, а не для
>> себя.
> По идее точно так же, только сделать для них юзера со специфическими
> ограничениями ssh.Как сделать автоматическую регистрацию пользователей? Через https? Или через костыли с pam?
> Как сделать автоматическую регистрацию пользователей?По fingerprint ключа, как на том ресурсе? Ну то-есть юзеры без ключа - гуесты, а ключи у всех по идее разные (если кто сгенерил приватный ключ как у Васи то он всяко сможет логиниться как Вася).
>Как сделать автоматическую регистрацию пользователей? Через https? Или через костыли с pam?Здесь это тоже никак не решено, сервер любой ключ принимает. Да через pam тоже можно всех подряд пускать.
>>Как сделать автоматическую регистрацию пользователей? Через https? Или через костыли с pam?
> Здесь это тоже никак не решено, сервер любой ключ принимает.Здесь, как я понимаю, вполне может быть реализована авторизация для уже занятых логинов по fingerprint или по другим признакам. Разница между данным решением и костылями через pam в том, что не придётся продумывать и реализовывать мегатонну деталей:
1. Сделать по изолированному контейнеру каждому пользователю (которых, грубо говоря, бесконечное количество). Это необходимо по большому количеству мелких причин, _например_ (один из _многих_ примеров) один пользователь может замусорить какой-нибудь IPC, и тем самым не дать всем другим пользователям нормально работать. К тому же в рамках данного примера, в случае с unshare(CLONE_NEWIPC) [который используют в частности и контейнерные системы в Linux] появляется элегантный GC для IPC, предотвращая исчерпания IPC-ресурсов (например семафоров или shm) из-за мелких утечек.
2. Запретить SFTP и прочую фигню.
3. Выставить дисковые квоты каждому контейнеру, чтобы не мешали друг другу работать.
4. Сделать screen с irssi шеллом по умолчанию
5. Модифицировать irssi так, чтобы люди не занимались ничем левым, кроме как chat-ом на данном сервере.
6. Безопасно организовать сеть во всей этой мешанине контейнеров так, чтобы не наплодить мегатонну интерфейсов.
n. т.д. и т.п.В результате придётся сделать огромный мега-костыль. Который, вероятно, будет очень неудобен, не очень надёжен, и возможно будет содержать какие-то дыры безопасности (так как поверхность для атаки очень велика, а делано всё собственноручно и без сторонних проверок).
> Да через
> pam тоже можно всех подряд пускать.Вы это уже делали когда-нибудь? _IIRC_, это сложнее, чем может показаться, ибо pam пытались делать безопасно, и в результате там запрещена авторизация несуществующих пользователей (ещё у них пароль подменяется на "*INVALID*", IIRC, но это сейчас не важно). Однако допускаю, что тут я могу что-то неправильно помнить.
Но вообще, если идти таким путём, то нужно будет придумать костыль, который пускает любого пользователя с любым логином (кроме root и других уже занятых, а также кроме логинов в виде чисел), а потом при следующих авторизациях вспоминает, что данный логин уже занят другим, и позволяет его использовать только при верном пароле, ключе или других признаках. + не стоит забывать задачи, перечисленные в начале данного комментария.
В результате можно будет случайно допустить ошибку, которая умному хацкеру даст возможность получить root от машинки.
Я имел в виду разрешить только форвардинг на конкретный порт чата одному юзеру, без шелла, без всего и без авторизации. Соответственно все через него и будут подключаться любыми клиентами. У себя в качестве туннеля они могут ssh использовать, или pussy.exe, не важно.
Если нужно авторизовать по ssh, тогда всё сложнее.
> Здесь, как я понимаю, вполне может быть реализована авторизация для уже занятых
> логинов по fingerprint или по другим признакам. Разница между данным решением
> и костылями через pam в том, что не придётся продумывать и
> реализовывать мегатонну деталей:Те перцы написали кастомный сервер. Который умеет ровно то что умеет. Если ты хочешь юзануть обычный sshd - ты дорвешься до того что хомяки взломают твою систему через кучу неочевидных фич.
Лучший способ разобраться с проблемными фичами - это выпилить их нафиг. Или точнее, не реализовывать совсем. От ssh там только шифрование и протокол. А сервер и его логика кастомные. Он не умеет запускать программы. Он не умеет sftp. Он плевал на попытки форварда портов и прочие впн-ы. А вот обычный sshd - out of the box совсем не предназначен для отдачи его на растерзание недоверяемым внешним юзерам которые могут дергать его фичи. И если ты надеешься что сможешь его закостылить - я думаю что закончится это фееричным взломом серверной машины. Кернелорг подтверждает!
> 1. Сделать по изолированному контейнеру каждому пользователю
Это вообще зачем? Иначе недостаточно энтерпрайзно чтоли? Сделать кастомный сервер который умеет только то что нужно и ни битом больше. Иначе вам машину поадминят через тул сделанный для администрирования.
> _многих_ примеров) один пользователь может замусорить какой-нибудь IPC,
А зачем пользователю чЯтика возможность вообще что-то делать с IPC? Это сначала создать себе проблемы, а потом пытаться их героически замазать? Вы вроде компетентнее казались...
> 2. Запретить SFTP и прочую фигню.
Вы хотите использовать обычный sshd? Вон kernel.org уже использовали. Закончилось тем что их сломал. Автоматический червяк вообще.
> 4. Сделать screen с irssi шеллом по умолчанию
Зашибись - еще и решить за пользователя какой клиент ему должен быть удобен.
> 5. Модифицировать irssi так, чтобы люди не занимались ничем левым, кроме как
> chat-ом на данном сервере.И заметить что в паре мест вышла лажа. Так что сервак тихой сапой ломанули.
В общем совершенно гнилая затея с поиском проблем на свой зад.
> Но эта штука мне нужна для других пользователей,А ты уверен что "другим пользователям" это нужно?
>> Но эта штука мне нужна для других пользователей,
> А ты уверен что "другим пользователям" это нужно?Да.
Очень здравая идея, особенно про SSH как безопасный транспорт для HTTP.
В ssh же закрытый ключ находится у клиента. Т е это пригодно только для закрытых сайтов с предварительной регистрацией (и навыками у пользователя)
Ну так для абсолютного большинства сайтов в инете это и ни к чему. А вот для гиковских или тематических, чтоб отсеять всяких клоунов - самое то.
Клоунов полно и среди гиков, и среди просто продвинутых юзеров. Не спасёт.
закрытый ключ пользователя у пользователя, а закрытый ключ сервера у сервера, когда мы подключаемся к серверу он нам преъявляет пруф, что не подставной, либо клиент говорит, что этот сервер непонятный, либо тупо шлет в сад. а вот потом пользователь доказывает серваку, что не гомосек ключем или паролем.В сущности ssh и https одно и тоже, на стадии установки соединения, но неужели ssl обосрался настолько? и может проще Берштейна попросить написать stcpserver и клиент к нему.
И как клиент понимает, что сайт не подставной? Просто 1 раз ключ принимается клиентов, а тот и это ключ хз.
Не понял сути вопроса, на каком этапе узнает?, в любом случае алгоритм простой и железобетонный, с разницей для ssh и https в том, что у ssh нет никаких центров удостоверяющих и рубящих капусту из воздуха, хочешь реально быть уверен, что нет мэна_ин_мидла, попроси админа сервера те ключ почтой прислать, конечно и почту можно подделать, но так и центр можно поломать.
Эмм... закрытый ключ пользователя или пароль нужны же вроде только для аутентификации пользователя в системе. А если аутентификация не нужна, может там и пароли с ключами не нужны, а? Ну вот баннер же по SSH передать можно без аутентификации, почему бы не передавать таким же образом и HTTP...
> Ну вот баннер же по
> SSH передать можно без аутентификации, почему бы не передавать таким же
> образом и HTTP...А смысл?
Этот баннер то выпилить пора из апстрима давно.
не пора... во всяких там америках и прочих "свободных демократиях" отсутствие баннера, уведомляющего о запрете входа неавторизованными лицами, может быть использовано преступником как обстоятельство, доказывающее его невиновность, типа "ну нигде же не написано, что нельзя подбирать пароли к этому серверу и что это преступление..."но сейчас не о том, а о самой возможности передавать данные шифрованым каналом БЕЗ аутентификации клиента.
чем плох https с самоподписанными сертификатами?
Тем, что браузер выдает "страааааашное" предупреждение.
Да еще человечка в фуражке рисует при этом.
2/3 юзеров запаникуют от него.
> чем плох https с самоподписанными сертификатами?Например:
1) а ты знаешь каким ауторити на момент конекта к "вон тому серверу" будет доверять "вот эта программа для чатика"? В смысле, кто из этих ауторити сможет выписать сертификат "очень похожий на твой".
2) а ты видел как программы валидируют сертификаты? Половина, допустим, IRC клиентов просто не показывает fingerprint совсем. Не говоря о сверке оного с ранее запомненым (что в ssh обычное дело). Поэтому с практической точки зрения - сертификат могут заменить а заметить это будет нелегко. Единственное исключение которое я видел в этом плане - Pidgin, где это реализовано на удивление вменяемо. С запросом при изменении сертификата относительно ранее известного и все такое.
Ага. Теперь собираем ssh с поддержкой x509. И что внезапно получается?
> Ага. Теперь собираем ssh с поддержкой x509.Наккой чёрт?
> Наккой чёрт?Увеличим attack surface.
> SSH как безопасный транспорт для HTTPSSH не является безопасным транспортом. Он дискредитирован.
Автор узнал про фичу SSH - туннелировать любое TCP-соединение?
Всё новое - хорошо забытое старое :)
Ssh, а точнее ssh2, не туннелирует tcp, а просто позволяет организовать шифрованную передачу потока данных. Никакой tcp специфики внутри шифроканалов нет.
man ssh
> Автор узнал про фичу SSH - туннелировать любое TCP-соединение?Упомянутая реализация ssh сервера ничего туннелировать не желает. И sftp отвергает.
Для начала прекрасно
На данный момент: ssh: Could not resolve hostname chat.shazow.net: Name or service not knownЧто-то подозреваю что он не обслужит даже 1000 клиентов на самой слабой виртуалке с DO.
Большой плюс что из коробки как докер машина идет.
>Что-то подозреваю что он не обслужит даже 1000 клиентов на самой слабой виртуалке с DO.Там на каждого клиента отдельный инстанс запускается.
> Там на каждого клиента отдельный инстанс запускается.Настоящий макофаг сделает и из ирц подобие апача :).
> На данный момент: ssh: Could not resolve hostname chat.shazow.net: Name or service
> not knownКажыся это интимные проблемы твоего провайдера, если у тебя hostname в IP не резолвится. При чём тут мощности их сервака?
я когда-то делал angband шелом - можно было коннектиться и ангбандить :)
> я когда-то делал angband шелом - можно было коннектиться и ангбандить :)Или переназначить шелл/запросить выполнение иной команды и что-нибудь порутать. С упомянутым сервером этот номер не проходит, равно как и попытки форварда портов, использования sftp и прочая.
Список пользователей бы ещё. А так неплохо.
SSH+write+who для чата вполне достаточно. Поделить папку для обмена файлами. Если добавить простейший Voip ,то получим сервер с универсальными коммуникациями.И никакого поделия на Go, костыль излишен.
> SSH+write+who для чата вполне достаточно. Поделить папку для обмена файлами. Если
> добавить простейший Voip ,то получим сервер с универсальными коммуникациями.И никакого
> поделия на Go, костыль излишен.Ещё нужно сделать соответствующий restricted shell, как-то решить проблему с мешаниной в stdout (при использовании write), интегрировать всё предоставив безгоморройное решение конечному пользователю и мн. др.
> Ещё нужно сделать соответствующий restricted shell,В том сервере вроде как решили проблему намного фундаментальнее - он не умеет ничего кроме чатика. Все очевидные попытки вылезти за его пределы, которые в 2 счета нагнут обычный sshd - ни к чему не приводят.
> как-то решить проблему с мешаниной в stdout (при использовании write),
Пустить irc over ssh вместо irc over ssl, а дальше пусть клиенты сами разбираются.
> И никакого поделия на Go, костыль излишен.Чет мне кажется, что этот проект родился после того, как автору пришла мысль: "У меня два любимых инструмента: Go и ssh, - чего бы мне еще эдакого замутить?"
Ну даже если и так - то что?
Все это уже было двадцать лет назад на основе telnet. ssh естественная замена telnet. В чем собственно новшество? А если добавить встроенные возможности туннелирования openssh, то вообще идиотизм получается. Ведь можно поднять на сервере абсолютно любой сервис, слушающий на локалхосте, а клиенты делают ssh соединение с пробросом портов, после чего соединяются с сервисом своим любимым клиентом. И не надо ничего по стопицот раз переписывать на модном молодежном языке.
> В чем собственно новшество?Автор тогда еще не родился...
новшество - програмка написана на Go. Всё. новшества закончились :) кому оно надо? странно что такую хрень здесь постят это да.
Не правильно готовишь :))там нет нормальных логинов, через которые можно делать проброс
Скриншот сделан в Мак Ос :)
Да, типичное яблочное ШГ. )
> Скриншот сделан в Мак Ос :)Странно что макосятник пишет на го, а не на руби.
скажите уже кто-нибудь этому пи… пионеру, что не надо бабушке усы клеить. что в протоколе SSH предусмотрены такие вещи, как различные каналы в рамках соединения. и что libssh/libssh2 в это умеют. и что написать программу, которая «применяет SSH и для других задач, воспользовавшись уже готовыми и проверенными средствами аутентификации, шифрования и мультиплексирования соединений» можно не надевая ласты в гамаке.
Ты еще скажи что можно взять какой-нибудь протокол типа ирца и туннельнуть. Между нормальным клиентом и нормальным сервером. С флудконтролем и без лага по 3 секунды на каждую букву. И вообще без занятий сервера отрисовкой экрана и обработкой ввода.Но это будет слишком просто, NIH будет зудеть.
Можно: ssh -L6667:irc.ololo.net:6667 user@gate.ololo.net
Остальные опции самостоятельно поищите.
Кстати, можно и так: ssh -D1080 user@gate.ololo.net
> Кстати, можно и так: ssh -D1080 user@gate.ololo.netЭто действительно будет конкретное ololo.net - у юзера на системе образуется прокся. Если у машины есть выход в интернет и админ не очень крут в настройке фаера - у него будет много траффика, завались. Потому что открытые прокси всегда пользуются спросом.
> Это действительно будет конкретное ololo.net - у юзера на системе образуется прокся. Если у машины есть выход в интернет и админ не очень крут в настройке фаера - у него будет много траффика, завались. Потому что открытые прокси всегда пользуются спросом.Прежде чем нести чушь, почитай умолчания конфига sshd. Прокси таким образом будет работать только для локалхоста. За тебя уже подумали и решили.
> работать только для локалхоста. За тебя уже подумали и решили.Насколько я помню, -D - динамический форвард портов. На локальной машине появляется как бы проксик, который реально туннелирует все по ssh на ремотную машину и то что попрошено по протоколу socks реально разруливается ремотно. И так в принципе можно например исходящие соединения куда угодно делать и прочая. Но даже если соединения будут только к локалхосту - это позволяет сканить/юзать вообще все сервисы на локалхосте, а не только ирц сервак. Что как бы грабли.
> С флудконтролемСлона едят по частям.
> без лага по 3 секунды на каждую букву.
Ну так может не будете по GPRS из Австралии подсоединяться к серверу. Что насчёт того, чтобы развернуть этот сервис в рамках своей локалки и перепроверить на лаги?
> И вообще без занятий сервера отрисовкой экрана и обработкой ввода.
Это в упрёк дополнительным задержкам на отрисовку? При хорошей сети это будет совершенно незаметно.
> Ну так может не будете по GPRS из Австралии подсоединяться к серверу.
> Что насчёт того, чтобы развернуть этот сервис в рамках своей локалки
> и перепроверить на лаги?а зачем? вот где-где, а «в рамках своей локалки» он вообще нужен как свинье папиросы.
>> Ну так может не будете по GPRS из Австралии подсоединяться к серверу.
>> Что насчёт того, чтобы развернуть этот сервис в рамках своей локалки
>> и перепроверить на лаги?
> а зачем? вот где-где, а «в рамках своей локалки» он вообще нужен
> как свинье папиросы.Я уверен, что бывают разные use case-ы. И что дополнительная свободная программа, занимающая новую нишу -- это всегда хорошо... пока её не форсируют.
так никто ж автору не запрещает ерундой заниматься. как и нам — говорить, что он ерундой занимается.
> так никто ж автору не запрещает ерундой заниматься. как и нам —
> говорить, что он ерундой занимается.Прошу простить данный переход на личности, но мне кажется, что вам так не нравится данное решение лишь потому, что оно уродское, а не потому, что оно бесполезное. Было бы больше таких людей как вы, мир был бы действительно лучше, ибо всякие systemd не взлетели бы, но всё-таки как-то некрасиво засирать чей-то труд лишь за то, что он не понравился. Для этого нужны более объективные причины.
А объективно говоря, subj-вый сервер занимает нишу отличную от IRC, поэтому сравнивать их некорректно. Напомню пример. Бывают конторы, где запрещают установку дополнительного ПО, но где разрешено работать с ssh. И на всякий случай также напомню, что далеко не у каждого человека есть тонна шеллов раскиданных по всей планете.
> Прошу простить данный переход на личности, но мне кажется, что вам так
> не нравится данное решение лишь потому, что оно уродское, а не
> потому, что оно бесполезное.верно. именно уродливое. ну, поэтому *в* *таком* *виде* — бесполезное. сама же идея вполне имеет право существовать, и может быть вполне полезна.
> но всё-таки как-то некрасиво засирать чей-то труд лишь за то, что
> он не понравился. Для этого нужны более объективные причины.уродливая архитектура — вполне достаточная причина.
> А объективно говоря, subj-вый сервер занимает нишу отличную от IRC, поэтому сравнивать
> их некорректно.а я ни слова про IRC не говорил, кстати. я как раз имел в виду намного более простую архитектуру, с кучкой очень тупых клиентов, общающихся с сервером на той же машине по IPC/unix socket. просто есть смысл в любом случае отделять тупого клиента, который будет запущен для юзера, от непосредственно сервера, который занимается обработкой всего. меньше вектор атаки.
> также напомню, что далеко не у каждого человека есть тонна шеллов
> раскиданных по всей планете.с точки зрения клиента это неважно в данном случае. а с точки зрения сервера — всё равно же допсофт туда ставить.
собственно, менее уродливой её вполне можно сделать именно перестав заниматься созданием монстриков, и перейдя к созданию мелких запчастей. вполне возможно иметь логин guest, ключ для которого лежит в открытом доступе. а дальше человек может залогиниться гостем и создать себе акк, получив личный ключ. всё это реализуемо при помощи простенького клиента, который запускается вместо login shell, и сервера (работающего на той же технике, вполне), который заведует остальным.со стороны клиента надо только ssh, терминал и возможность скопировать символы из терминала (чтобы забрать сгенерированый ключ при регистрации). то есть, именно то, что и постулировано в сабже.
со стороны же сервера имеем архитектуру из «сервер болталки», «сервер ssh», «клиентский интерфейс». всё красиво побито на части, всё взаимозаменяемо, всё обновляемо по отдельности. вдобавок предусматриваем в клиенте команду «перейти на машиночитаемый протокол» — и тогда при желании люди смогут ещё и сторонние клиенты писать к этой фиговине.
все довольны, всё то же самое, архитектура по максимуму использует уже существующие компоненты, не пытаясь их заменять на доморощеные хаки. «ура-ура!» — закричали тут швамбраны все.
> guest, ключ для которого лежит в открытом доступе.У вон того перца с его сервером логиниться можно совсем без ключа. А можно с ключом, тогда сервер fingerprint видит. Как я понимаю он админов так и авторизует, по фигнерпринтам их ключей. По ним же можно и ники резервировать. Наверное одна из немногих вещей которые в сабже сделаны относительно адекватно.
> Слона едят по частям.В IRC его уже завалили, распилили на части и приготовили. А вы только точите копье, аргументируя это тем что вон тот слон неправильный. А ваши у...щные костыли с попыткой запретить sshd всякиe sftp и выполнение произвольных программ, запустить только один конкретный ирц клиент и прочая - это что, такой чемпионат "кто сделает самый у...щный аналог IRC?"
> Ну так может не будете по GPRS из Австралии подсоединяться к серверу.
А в обычном IRC все это жить особо не мешает. Поскольку ввод обрабатывает мой локальный клиент и задержка ввода около нуля, даже если до сервера пинг в 3 секунды. А когда я считаю что закончил - клиент сообщение уже пихает на сервак. Как нечто атомарное. Это подперто буферами и на клиенте и на сервере и если там даже что-то протупит, меня это напрягать будет крайне слабо. И с сервера едут сугубо сообщения. А как я их там парсить и рендерить буду - проблемы моего клиента. Настрою как мне удобно и будет радовать лично мой глаз (у меня hexchat с весьма кастомной схемой которую я сделал себе сам, желая видеть разные события в разном виде). А не какие-то горбатые потуги рендера всего экрана. С навязкой мне цветовых схем и прочего крапа. Вот реально - до того как делать очередное кривое у...ще - посмотрите как делали 30 лет назад. Даже это - просто шедевр инженерной мысли на фоне того что затеваете вы.
> Что насчёт того, чтобы развернуть этот сервис в рамках своей локалки
> и перепроверить на лаги?Negative. Зачем мне некая НЕХ, которая сносно работает только в тепличных условиях, а к реальной жизни непригодна?
> Это в упрёк дополнительным задержкам на отрисовку? При хорошей сети это будет
> совершенно незаметно.Это упрек к общей у...щности такого подхода. Зачем-то свалить на сервер кучу несвойственных ему задач и попутно сильно обуть клиента на возможность кастомизировать отображение, зато добавить кучу тормозов, слать явно больше траффика чем надо и прочая. Эталонный пример клиентсервра сделанного максимально через анyc, при том непонятно зачем.
ИМХО нормальный вариант использования ПРОТОКОЛА ssh - запилить субсет ssh (с использованием libssh?) который согласен только форвардить трафф клиента к серверу. И больше не умеет вообще ни-че-го. И тунельнуть например обычный ирц к обычному ирцд. При сильном эстетстве можно парочке клиентов и серверов привинтить либу по типу того как с openssl, чтобы показать "как надо". А то что вы предлагаете с irssi в контейнерах - это форменный, простите, онанизм. И больше всего напоминает BNC сделанный максимально через задний проход.
> скажите уже кто-нибудь этому пи… пиoнeрyМой юн.ый друг, зайдите в чат и выскажите автору своё "фэ" персонально. Он там присутствует.
Иначе ваша реплика будет восприниматься как: "Я тут кy.кaрeкнyл, а там хоть не рассветай!"
когда мне понадобится узнать мнение идиота — я тебя спрошу.
> Мой юн.ый друг, зайдите в чат и выскажите автору своё "фэ" персонально.
> Он там присутствует.А смысл? Там периодически кто-то вгоняет ботов адски флудящих все. И чЯтик адово тормозит, так что каждая буква пропечатывается по паре секунд.
На фоне этого п...ца, irc клиент который компонует всю строку, редактируя ее локально и потом отправляя на сервер одним махом - смотрится просто технологическим прорывом, а IRC сервер с флудконтролем, способностью обслужить 5000 юзерей на 1 средненьком сервачке без ощутимых тормозов и присылкой именно сообщений а не потуг с рендерингом экрана и ввода - вообще шедевр инженерной мысли. По сравнению с этой кривой и тормозной буитой.
> А смысл?Ну так говорить с автором здесь — ещё бессмысленнее. Там-то автор хоть присутствует.
> Там периодически кто-то вгоняет ботов адски флудящих все. И чЯтик адово тормозит
Не замечал тормозов. Кстати, там во время флуда его спрашивали как с нагрузкой дела обстоят, ответ был — la 0.01.
> каждая буква пропечатывается по паре секунд
А это, наверное, из-за RTT под 300 и потери пакетов.
> irc клиент который компонует всю строку,
> редактируя ее локально и потом отправляя на сервер одним махомВключите локальное редактирование в вашем pussy.exe и будет точно так же как в IRC.
> IRC сервер … По сравнению с этой кривой и тормозной буитой.
☻
> Ну так говорить с автором здесь — ещё бессмысленнее. Там-то автор хоть присутствует.Не вижу смысла с ним говорить - его долбил злостный NIH, поэтому он сделал эрзац IRC, максимально через ж...у. Тот финн который сделал прототип IRC в лохматых 80-х был на порядок вменяемее. Ну а если человек хочет игнорировать чужие наработки, потому что свое гoвнo не пахнет - его право. Но глядя на то как это работает - это именно гoвнo. По сравнению с IRC, впервые появившимся в 80-х годах прошлого века.
> Не замечал тормозов. Кстати, там во время флуда его спрашивали как с
> нагрузкой дела обстоят, ответ был — la 0.01.Ну да, совсем не заметно что чЯтик скроллится еле-еле, с большой задержкой. И реакция на все операции по несколько секунд. В паре с отрисовкой ввода сервером все это работает на редкость погано. По сравнению с обычным IRC, умеющим в 100 раз больше (например, именованные каналы вместо 1 большой помойки), давно разобравшимся с спамерами и флудерами, раздачей прав и прочая и протоколом который прост и для сервера и для клиента, а также оперирует целыми линиями. И на отправку и на прием. И человеческим механизмом буферизации, что в паре с лимитом размера сообщения с одной стороны не дает круто и быстро флудить, с другой - если немного превысить лимит, постепенно накапает из буффера. А если флудануть на совесть - буфер заполнится и сервак скинет клиента. Это не позволяет в IRC сильно и быстро гадить. Там же и лимиты по айпи/подсетям, штуки типа BOPM и ему подобные. Они дают время операторам канала размахнуться по негодяю банхамером. А не так что сначала прилетает ядерный взрыв на 3 экрана, а потом можете попробовать забанить, если вас не клинит при таком потоке данных. Ну то-есть все это можно и сюда прикрутить. Годков 10 эволюции протоклола - и все будет! :)
> А это, наверное, из-за RTT под 300 и потери пакетов.
А в IRC это вообще индифферентно. Им можно комфортно пользоваться даже через Tor или GPRS, с пингом в 2-5 секунд, в большинстве случаев не замечая что этот RTT есть. Потому что нормальная буферизация и оперирование целыми скомпонованными сообщениями :)
> Включите локальное редактирование в вашем pussy.exe и будет точно так же как в IRC.
1) А у меня нет никакого pussy.exe. У меня xfce terminal и ssh. Внезапно, да? Ждем рецепта на этот случай.
2) Вы это как, всем пользователям кривого протокола готовы рассказывать?
3) Честно говоря я не пнимаю как можно пользоваться pussy. Он кривой до невозможности. Даже выделение текста и копипаст сделаны инопланетянами и работают сильно иначе чем в остальных программах. Этот крап есть и под пингвины, но после xfce terminal - ненене, Дэвид Блэйн.Вот честно - если мне надо будет крЮтой чЯтик - я возьму Unreal IRCD или InspIRCD. И нормальный клиент. А если перец хотел чтобы между ними был ssh - ну, делал бы в своем сервере туннель, с возможностью туннелить только 1 порт - того сервака. А лучше прикрутил бы libssh какой-нибудь к серверу и паре клиентов, показать как это делать. К остальным другие прикрутят, если идея понравится. А вот так NIH'ать гунявенький кривой протокол - им поиграются пару дней и забудут.
> Не вижу смысла с ним говорить - его долбил злостный NIHВы или не понимаете смысл аббревиатуры NIH, или намеренно пітаетесь ввести читателей ваших опусов в заблуждение.
> он сделал эрзац IRC
Вы действительно считаете, что тот товарищ замахнулся на наш, так-сказать, IRC? Нигде в его статье я не нашёл упоминания того, что он пытался заменить IRC.
> 1) А у меня нет никакого pussy.exe. У меня xfce terminal и
> ssh. Внезапно, да? Ждем рецепта на этот случай.Нет? Так поставьте, делов-то…
Не хотите pussy? — Юзайте mosh.> Вот честно - если мне надо будет крЮтой чЯтик - я возьму
> Unreal IRCD или InspIRCD. И нормальный клиент. А если перец хотелПерец захотел, сел и сделал. Не вижу в этом ничего плохого.
> А вот так NIH'ать
:facepalm:
> гунявенький кривой протокол - им поиграются пару
> дней и забудут.И это совершенно естественно.
> Вы или не понимаете смысл аббревиатуры NIH, или намеренно пітаетесь ввести читателей
> ваших опусов в заблуждение.В данном случае налицо явный синдром переизобретения клиент-серверного взаимодействия в максимально кривом формате.
> Вы действительно считаете, что тот товарищ замахнулся на наш, так-сказать, IRC?
Я думаю что если уж он полез писать кастомный сервер - мог бы сделать нечто типа туннеля для IRC и не загаживать атмосферу своими кривыми потугами отрисвать чЯтик самому. Идея рисовать чЯтик и рисовать ввод со стороны сервера вообще пахнет конкретным идиотизмом.
> Нигде в его статье я не нашёл упоминания того, что он пытался
> заменить IRC.Это не отменяет того что общий смысл чЯтика похож на круто урезанный и сделанный через ж..у ирц.
> Нет? Так поставьте, делов-то…
Зачем мне это у...ще? Мне оно не нравится. Хреновый терминал. Не, ну виндузоидам и такое сойдет, потому что системная консоль еще поганее, но я то не виндузоид. Я к хорошему уже привык.
> Не хотите pussy? — Юзайте mosh.
Ну да, юзабилити протокола получилось на высоте, нечего сказать. Надо самому какие-то костыли доустанавливать чтобы приемлимо работало. А почему в ирц мне пофиг что пинг в пять секунд по GPRS, вы не знаете? Может, потому что протоколы стоит делать не через aнус?
> Перец захотел, сел и сделал. Не вижу в этом ничего плохого.
Ну да, кроме того что получилась позорная пародия на ирц которая работает как г-но.
> И это совершенно естественно.
Ну так я и говорю - основным достоинством этого уродства является то что чувак его написал. Стандартный зуд по части NIH-а. В смысле, заинвентить свой протокол. Правда поскольку котелок хорошо варит не у всех - зачастую единственным достоинством оказывается "зато изобретено здесь". По поводу чего про это через пару дней все и забудут. Ведь работает как полное г-но. Поэтому поприкалываться полчаса сойдет. А если чатик такого плана надо всерьез - проще ircd поставить и нормальные IRC клиенты взять.
Слушайте, никто не обижает ваше IRC. Успокойтесь и не порите чуши.
И намёка не было чтобы как-то где-то уязвить IRC.Просто поймите, что не IRC единым…
> скажите уже кто-нибудь этому пи… пионеру, что не надо бабушке усы клеить.
> что в протоколе SSH предусмотрены такие вещи, как различные каналы в
> рамках соединения. и что libssh/libssh2 в это умеют. и что написать
> программу, которая «применяет SSH и для других задач, воспользовавшись уже готовыми
> и проверенными средствами аутентификации, шифрования и мультиплексирования соединений»
> можно не надевая ласты в гамаке.Мне почему-то кажется, что вы предлагаете способ решения, который решает другую задачу. Например, в некоторых конторах запрещено устанавливать дополнительное ПО, но разрешено работать с SSH. Или, например, данный сервис может быть применен как локальный аварийный gate в какой-нибудь чат. А ваше решение в свою очередь требует установки дополнительной программы на клиентскую машину... Притом клиентская программа должна быть портирована и на FreeBSD, и на Windows, и на Android и на другие с системы, а также на различные архитектуры (e.g. arm, ppc64el), но это уже отдельная тема.
То есть ваше решение в целом существенно красивее, но всё-таки решает совсем не ту задачу, IMHO.
а сабж вообще никаких задач не решает, окромя «look ma i can ssh!»не надо писать ещё один дырявый сервер для занятий ерундой, достаточно сменить login shell на какой-нибудь убертупой клиент для какой-нибудь болталки. собственно, если бы проект и был про убертупую болталку с убертупым клиентом, то никаких проблем. но нет, чувак делает аж целый custom ssh server! зачем он так? затем, что он идиот.
> а сабж вообще никаких задач не решает, окромя «look ma i can
> ssh!»Откуда такая информация?
> не надо писать ещё один дырявый сервер для занятий ерундой, достаточно сменить
> login shell на какой-нибудь убертупой клиент для какой-нибудь болталки. собственно, если
> бы проект и был про убертупую болталку с убертупым клиентом, то
> никаких проблем.https://www.opennet.ru/openforum/vsluhforumID3/101068.html#77
> но нет, чувак делает аж целый custom ssh server!
> зачем он так? затем, что он идиот.Как вы сделаете авторизацию логина (в данном чате) через ssh-ключи с помощью предложенного вами решения? Какой именно клиент вы предлагаете использовать? Как вы предлагаете разрешить использование логина "root" в данном чате?
>> а сабж вообще никаких задач не решает, окромя «look ma i can
>> ssh!»
> Откуда такая информация?из исследования проекта.
> Как вы сделаете авторизацию логина (в данном чате) через ssh-ключи с помощью
> предложенного вами решения?ты это… прикинь… ssh именно так и авторизуется. сам. не надо ничего писать для этого. да, заводим нового юзера и радуемся.
> Какой именно клиент вы предлагаете использовать?
самописный, очевидно. к самописному же серверу.
> Как вы
> предлагаете разрешить использование логина "root" в данном чате?зачем?
но да, конечно, это всё нестильно. фу делать модульные решения из простых частей, фу! то ли дело — сразу свой ssh-сервер забабахать! да ещё и на go.
>> Как вы сделаете авторизацию логина (в данном чате) через ssh-ключи с помощью
>> предложенного вами решения?
> ты это… прикинь… ssh именно так и авторизуется. сам. не надо ничего
> писать для этого. да, заводим нового юзера и радуемся.Наверное я плохо сформулировал. В IRC часто запускают так называемые "services", одним из которых нередко является "NickServ". И этот NickServ, в частности, обычно следит за тем, чтобы конкретными nick-ами пользовались только те пользователи, которые их зарегистрировали (как вам наверняка и без меня известно).
Так вот, как сделать авторизацию ника через SSH-ключи? Если вы развязываете ssh-сервер и irc(/whatever else)-сервер друг от друга, то тогда авторизация по ssh -- это одно, а авторизация на чат-сервере -- это уже другое. Как объединить эти вещи?
>> Как вы
>> предлагаете разрешить использование логина "root" в данном чате?
> зачем?Затем, что запрещать использование ника "root" в чате из-за внутренних особенностей системы -- это как-то криво. Я знаю пользователей в IRC-сетях, которые используют данный ник.
> но да, конечно, это всё нестильно. фу делать модульные решения из простых
> частей, фу! то ли дело — сразу свой ssh-сервер забабахать!Лучше готового решения пока никто не написал. Во всяком случае из мне известного. Хотя и данное решение далеко от готового, но это уже другой вопрос.
> да ещё и на go.
Ну, это всяко лучше, чем на Python или Ruby. :)
> Так вот, как сделать авторизацию ника через SSH-ключи?логином. точно как ssh это и делает, собственно.
> Если вы развязываете ssh-сервер
> и irc(/whatever else)-сервер друг от друга, то тогда авторизация по ssh
> -- это одно, а авторизация на чат-сервере -- это уже другое.
> Как объединить эти вещи?у никсов есть такое забавное апи, при помощи которого можно узнать, под каким же юзером мы запущены. самоочевидно, что для нашего случая это будет тот самый юзер, под которым мы залогинились. вот эту информацию клиент и передаёт серверу. поскольку сервер снаружи недоступен, а юзер ничего, окромя клиента, запустить не может, то есть смысл поверить клиенту, если он говорит, что это vasya.
>>> Как вы
>>> предлагаете разрешить использование логина "root" в данном чате?
>> зачем?
> Затем, что запрещать использование логина "root" в чате из-за внутренних особенностей системы
> -- это как-то криво. Я знаю пользователей в IRC-сетях, которые используют
> данный ник.а нулевые символы в нике можно? как это «нельзя»? КРИВИЗНА!!!1111
нельзя «root». нельзя — и всё. eat it or GTFO. я сильно сомневаюсь, что это именно тот ужасный недостаток, из-за которого надо городить свой монолитный ssh-сервер вместо модульной системы.
>> но да, конечно, это всё нестильно. фу делать модульные решения из простых
>> частей, фу! то ли дело — сразу свой ssh-сервер забабахать!
> Лучше готового решения пока никто не написал.потому что никому нафиг не нужно. ну, из тех, кто может сделать нормальное решение. потому что если тем, кто может сделать нормальное решение, заявят, что «на работе нельзя ставить софт, но можно ssh» — эти люди покрутят пальцем у виска.
однако же вышенаписаное — ни разу не причина приветствовать решение, сдизайненое обезьяной-наркоманом.
>> да ещё и на go.
> Ну, это всяко лучше, чем на Python или Ruby. :)одна фигня. но руби хотя бы забавный.
>> Если вы развязываете ssh-сервер
>> и irc(/whatever else)-сервер друг от друга, то тогда авторизация по ssh
>> -- это одно, а авторизация на чат-сервере -- это уже другое.
>> Как объединить эти вещи?
> у никсов есть такое забавное апи, при помощи которого можно узнать, под
> каким же юзером мы запущены. самоочевидно, что для нашего случая это
> будет тот самый юзер, под которым мы залогинились. вот эту информацию
> клиент и передаёт серверу. поскольку сервер снаружи недоступен, а юзер ничего,
> окромя клиента, запустить не может, то есть смысл поверить клиенту, если
> он говорит, что это vasya.Ок, но работает только для самописного клиента к чат-серверу.
>>>> Как вы
>>>> предлагаете разрешить использование логина "root" в данном чате?
>>> зачем?
>> Затем, что запрещать использование логина "root" в чате из-за внутренних особенностей системы
>> -- это как-то криво. Я знаю пользователей в IRC-сетях, которые используют
>> данный ник.
> а нулевые символы в нике можно? как это «нельзя»? КРИВИЗНА!!!1111Одно дело какие-то символы "<32 || >127" (зачастую вредность которых выше пользы), и совсем другое дело выколотые слова (состоящие из 4 lower latin characters) из-за кривоты реализации.
> нельзя «root». нельзя — и всё. eat it or GTFO.
Это одна из мелочей, с которой нужно смириться. Другая из мелочей, что будет использовано намного больше ОЗУ. Третья из мелочей -- замусоривание /etc/{passwd,shadow,group,gshadow} и исчерпание UID-ов и GID-ов (что можно обойти через сомнительные по безопасности костыли). И т.п.
> я сильно
> сомневаюсь, что это именно тот ужасный недостаток, из-за которого надо городить
> свой монолитный ssh-сервер вместо модульной системы.Ну, естественно модульное решение предпочтительнее. Но его кто-то уже сделал?
>>> но да, конечно, это всё нестильно. фу делать модульные решения из простых
>>> частей, фу! то ли дело — сразу свой ssh-сервер забабахать!
>> Лучше готового решения пока никто не написал.
> потому что никому нафиг не нужно. ну, из тех, кто может сделать
> нормальное решение. потому что если тем, кто может сделать нормальное решение,
> заявят, что «на работе нельзя ставить софт, но можно ssh» —
> эти люди покрутят пальцем у виска.Не надо мешать в одну кучу пользователей и администраторов сервиса.
> однако же вышенаписаное — ни разу не причина приветствовать решение, сдизайненое
> обезьяной-наркоманом.Причина приветствовать -- грубо говоря, лучшее решение из существующих для определённой ниши проблем. Меньшее из зол, так сказать.
>>> да ещё и на go.
>> Ну, это всяко лучше, чем на Python или Ruby. :)
> одна фигня. но руби хотя бы забавный.Совсем не одна фигня. Golang хотя бы компилируемый.
> Ок, но работает только для самописного клиента к чат-серверу.о котором я изначально и говорил все сообщения. мне кажется, тут есть недопонимание: этот самый «самописный клиент» — он является частью софта, который запускается на сервере после ssh-аутентификации. естественно, писать надо будет. так в любом же случае писать надо будет — кое-кто вон цельный ssh-сервер даже отгрохал там, где оно не надо.
> Одно дело какие-то символы "<32 || >127" (зачастую вредность которых выше пользы),
> и совсем другое дело выколотые слова (состоящие из 4 lower latin
> characters) из-за кривоты реализации.не вижу разницы. если кому-то жизнь не мила без любимого ника «root», пусть примет таблетку от мегаломании.
>> нельзя «root». нельзя — и всё. eat it or GTFO.
> Это одна из мелочей, с которой нужно смириться. Другая из мелочей, что
> будет использовано намного больше ОЗУ.«намного больше» — по сравнению с чем? я повторно скажу, что большинство страниц будут shared. кого-то действительно волнует, сколько слопано VIRT, а не сколько слопано RES?
> Третья из мелочей — замусоривание /etc/{passwd,shadow,group,gshadow}
кто мешает посадить это в отдельный контейнер? кстати, и безопасней будет. и даже рута можно позволить регистрировать. и безопасно, и мегаломаньяки могут ЧСВ потешить.
> и исчерпание UID-ов и GID-ов (что можно обойти через сомнительные по
> безопасности костыли).десятки тысяч пользователей? (впрочем, насколько я помню, uid-ы таки 32-битные, так что…) без очистки дохлых хотя бы по дате последнего логина? ну ок. на таком беспризорном сервере это будет меньшая из проблем.
> И т.п.
реашется методом «и т.п.»
> Ну, естественно модульное решение предпочтительнее. Но его кто-то уже сделал?
а никому не надо. сабжевое — тоже.
>>>> но да, конечно, это всё нестильно. фу делать модульные решения из простых
>>>> частей, фу! то ли дело — сразу свой ssh-сервер забабахать!
>>> Лучше готового решения пока никто не написал.
>> потому что никому нафиг не нужно. ну, из тех, кто может сделать
>> нормальное решение. потому что если тем, кто может сделать нормальное решение,
>> заявят, что «на работе нельзя ставить софт, но можно ssh» —
>> эти люди покрутят пальцем у виска.
> Не надо мешать в одну кучу пользователей и администраторов сервиса.и где я смешивал?
>> однако же вышенаписаное — ни разу не причина приветствовать решение, сдизайненое
>> обезьяной-наркоманом.
> Причина приветствовать -- грубо говоря, лучшее решение из существующих для определённой
> ниши проблем. Меньшее из зол, так сказать.нет. это и ни то, и ни другое, это куча говна. куча говна — вообще никакое не решение.
>>>> да ещё и на go.
>>> Ну, это всяко лучше, чем на Python или Ruby. :)
>> одна фигня. но руби хотя бы забавный.
> Совсем не одна фигня. Golang хотя бы компилируемый.и какая разница? шифрование везде делается библиотеками в машинном коде, а всё остальное совершенно некритично.
>> Ок, но работает только для самописного клиента к чат-серверу.
> о котором я изначально и говорил все сообщения. мне кажется, тут есть
> недопонимание: этот самый «самописный клиент» — он является частью софта,
> который запускается на сервере после ssh-аутентификации. естественно, писать надо будет.
> так в любом же случае писать надо будет — кое-кто вон
> цельный ssh-сервер даже отгрохал там, где оно не надо.Просто из-за моей лени перечитать данную ветку комментариев, вместе с прочтением других веток комментариев, в моей голове сформировалась небольшая каша. Приношу извинения.
>> Одно дело какие-то символы "<32 || >127" (зачастую вредность которых выше пользы),
>> и совсем другое дело выколотые слова (состоящие из 4 lower latin
>> characters) из-за кривоты реализации.
> не вижу разницы. если кому-то жизнь не мила без любимого ника «root»,
> пусть примет таблетку от мегаломании.Разница в том, как это выглядит перед пользователями, если делать настолько же удобно для тупого пользователя, как начали делать в subj-вом проекте. Там нет необходимости заходить сначала на guest-а, чтобы получить ник, а только потом логиниться с данным ником. Можно сразу заходить с новым ником. Предлагаете в motd высветить запрет использования root или как? Или это принципиальный запрет заходить сначала из под guest-а, а только потом под своим ником?
>>> нельзя «root». нельзя — и всё. eat it or GTFO.
>> Это одна из мелочей, с которой нужно смириться. Другая из мелочей, что
>> будет использовано намного больше ОЗУ.
> «намного больше» — по сравнению с чем?В сравнении с хорошо написанным сервером, который всех обрабатывает одним процессом (но не потоком).
> я повторно скажу, что большинство страниц будут shared.
1. Страница - это обычно от 4КБ. Это конечно мелочь, но изменяем один байт и все 4КБ сжирают дополнительную страницу.
2. Если имеется процесс A, который форкается на A и B (и на этом конец), то да. Но если есть процесс A, который форкается на A и B, а потом в каждом делается exec (который перезатрёт всё в его памяти нафиг), то тогда уже нет. С другой стороны память можно дедуплицировать назад с помощью KSM. Хотя это не очень удобно, не очень быстро и слегка не очень безопасно (за счёт потенциальной возможности создания условий для дополнительных timing attack), но со всем можно смириться, конечно.
3. Возможно у каждого процесса будет полностью свой (без всяких shared) stack. Нужно проверить, таких тонкостей лично я не помню.
4. Это ещё одна мелочь, но всё-таки проблема не только в fork(), но и в том, что будет больше разных процессов. Каждый раз будет иметь свои какие-то прилинкованные библиотеки, "обёртки" (для обработки аргументов, конфигов и т.п.), реализации интерфейсов для взаимодействия между процессами и др.>> Третья из мелочей — замусоривание /etc/{passwd,shadow,group,gshadow}
> кто мешает посадить это в отдельный контейнер? кстати, и безопасней будет. и
> даже рута можно позволить регистрировать. и безопасно, и мегаломаньяки могут ЧСВ
> потешить.Да, я это предполагал такое решение в другом комментарии выше. Но тогда начинается новая волна проблем:
- Новая весьма немалая зависимость (как и в user-space, так и в kernel-space).
- Портируемость улетучивается нафиг (что следует из предыдущего пункта, но требует отдельного внимания).
- Как быть с сетью между хостом и контейнерами? Наиболее разумное решение, это вырубить unshare(CLONE_NEWNET), но не уверен, что это позволяется в docker/lxc.
- Потребность в OverlayFS для удобного обновления окружения (с AUFS есть отдельные проблемы, которые можно обсудить, если интересно). Что создаёт зависимость на новые ядра и создаёт мусор в /proc/mounts.
- Как быть, если потенциальным хостом является контейнер (предоставленный хостером на 1$ в месяц), и в нём вырублены capabilities, необходимые для создания дочерних контейнеров?
- ... Дальше думать лень, но мне кажется, что это далеко не конец.>> и исчерпание UID-ов и GID-ов (что можно обойти через сомнительные по
>> безопасности костыли).
> десятки тысяч пользователей? (впрочем, насколько я помню, uid-ы таки 32-битные, так что…)
> без очистки дохлых хотя бы по дате последнего логина? ну ок.
> на таком беспризорном сервере это будет меньшая из проблем.Да, только что перепроверил, вы правы. Около-16-битное ограничение было лишь со стороны /etc/login.defs.
>> Ну, естественно модульное решение предпочтительнее. Но его кто-то уже сделал?
> а никому не надо. сабжевое — тоже.Так пусть это решит свободное сообщество. Другими словами, время покажет. Хотя там уже почти 1200 star-ов на github-е, что очень много для столь молодого проекта (проекту лишь почти месяц).
>>>>> но да, конечно, это всё нестильно. фу делать модульные решения из простых
>>>>> частей, фу! то ли дело — сразу свой ssh-сервер забабахать!
>>>> Лучше готового решения пока никто не написал.
>>> потому что никому нафиг не нужно. ну, из тех, кто может сделать
>>> нормальное решение. потому что если тем, кто может сделать нормальное решение,
>>> заявят, что «на работе нельзя ставить софт, но можно ssh» —
>>> эти люди покрутят пальцем у виска.
>> Не надо мешать в одну кучу пользователей и администраторов сервиса.
> и где я смешивал?Тем, кому запрещают ставить другой софт -- это пользователи. А те, кто делает решение -- это администраторы.
>>> однако же вышенаписаное — ни разу не причина приветствовать решение, сдизайненое
>>> обезьяной-наркоманом.
>> Причина приветствовать -- грубо говоря, лучшее решение из существующих для определённой
>> ниши проблем. Меньшее из зол, так сказать.
> нет. это и ни то, и ни другое, это куча говна. куча
> говна — вообще никакое не решение.То есть с вашей точки зрения лучше никакое "решение", чем такое. Я правильно понял?
>>>>> да ещё и на go.
>>>> Ну, это всяко лучше, чем на Python или Ruby. :)
>>> одна фигня. но руби хотя бы забавный.
>> Совсем не одна фигня. Golang хотя бы компилируемый.
> и какая разница? шифрование везде делается библиотеками в машинном коде, а всё
> остальное совершенно некритично.Почему некритично? Шифрование бывает легковесным. Например, есть всем известный hpn-ssh. IIRC, я утилизировал Gbps, используя scp на i7 (на клиентской стороне) и ещё много ресурсов CPU осталось свободными. Если нужно, могу перепроверить. А пока давайте поделим на 1000, чтобы дойти до уровня сравнительно высоконагруженного чат-сервера. Хотите сказать, что RPi в 1000 слабее i7 (в рамках данной задачи)?
> Просто из-за моей лени перечитать данную ветку комментариев, вместе с прочтением других
> веток комментариев, в моей голове сформировалась небольшая каша. Приношу извинения.ерунда, бывает.
> Разница в том, как это выглядит перед пользователями, если делать настолько же
> удобно для тупого пользователя, как начали делать в subj-вом проекте. Там
> нет необходимости заходить сначала на guest-а, чтобы получить ник, а только
> потом логиниться с данным ником. Можно сразу заходить с новым ником.без разницы. те, кому это «с разницей», с воплями убегут уже от одного вида терминала.
> Предлагаете в motd высветить запрет использования root или как?
зачем? ник занят — это получается само просто потому, что система проверяет существующих пользователей. ну, если кому-то нечего делать — пусть долбится и пытается угадать ключ. авось умрёт от истощения.
>>> Это одна из мелочей, с которой нужно смириться. Другая из мелочей, что
>>> будет использовано намного больше ОЗУ.
>> «намного больше» — по сравнению с чем?
> В сравнении с хорошо написанным сервером, который всех обрабатывает одним процессом (но
> не потоком).без проверок это чистой воды спекуляция. думаю, нет особого смысла обсуждать, не имея в руках чисел.
>> я повторно скажу, что большинство страниц будут shared.
> 1. Страница - это обычно от 4КБ. Изменяем один байт и все
> 4КБ сжирают дополнительную страницу.и фиг с ним. сто пользователей — 400 кб. да полноте, пусть даже четыре мегабайта. тысяча — сорок мегабайт. даже на плате с 512 это совершенно пофигу, она загнётся намного раньше.
> 4. Это мелочь, но всё-таки проблема не только в fork(), но и
> в том, что будет больше разных процессов. Каждый раз будет иметь
> свои какие-то прилинкованные библиотеки, "обёртки" (для обработки аргументов, конфигов
> и т.п.), реализации интерфейсов для взаимодействия между процессами и др.всё это как раз и идёт в shared. shared libraries — они ещё и потому shared, что система умеет их mmap'ить. если, конечно, сборщик потрудился их с -fPIC собрать.
> Да, я это предполагал такое решение в другом комментарии выше. Но тогда
> начинается новая волна проблем:один из вариантов. а вообще — ну, будет куча пользователей в системе. ну и что? как часто надо усердно читать соответствующие файлы глазами? и что мешает при нужде выгрепнуть оттуда всех, у кого в login shell клиент прописан? да пусть будут. ну реально, обработать текстовый файл даже с сотней тысяч строк, учитывая, что это надо далеко не каждую минуту даже… пофигу. нет в этом никакой проблемы. ну, уйдёт на логин пол-секунды.
>>> Ну, естественно модульное решение предпочтительнее. Но его кто-то уже сделал?
>> а никому не надо. сабжевое — тоже.
> Так пусть это решит свободное сообщество.да пусть себе решает, разве же я кому могу запретить?
> уже почти 1200 star-ов на github-е, что очень много для столь
> молодого проекта (проекту лишь почти месяц).на гитхабе обитают идиоты. три с половиной нормальных и идиоты.
>>>>> Лучше готового решения пока никто не написал.
>>>> потому что никому нафиг не нужно. ну, из тех, кто может сделать
>>>> нормальное решение. потому что если тем, кто может сделать нормальное решение,
>>>> заявят, что «на работе нельзя ставить софт, но можно ssh» —
>>>> эти люди покрутят пальцем у виска.
>>> Не надо мешать в одну кучу пользователей и администраторов сервиса.
>> и где я смешивал?
> Тем, кому запрещают ставить другой софт -- это пользователи. А те, кто
> делает решение -- это администраторы.я мягко намекаю на то, что те, кто могут сделать решение не через задницу, не испытывают в нём нужды. если пользователю нельзя ставить софт — значит, пользователь использует технику работодателя. в любой нормальной конторе необходимость нечто доставить для работы решается без проблем. а если оно для работы не надо, а надо, чтобы заниматься ИБД… тьфу.
> То есть с вашей точки зрения лучше никакое "решение", чем такое. Я
> правильно понял?совершенно верно. потому что сабж — не решение, а куча говна. причём куча говна, которая «решает» несуществующую проблему.
>> и какая разница? шифрование везде делается библиотеками в машинном коде, а всё
>> остальное совершенно некритично.
> Почему некритично?потому что дальше всё всё равно упирается в скорость сети.
> Шифрование бывает легковесным. Например, есть всем известный hpn-ssh.
э… это, кагбэ, прямая противоположность «легковесному». оно как раз предназначено для того, чтобы по максимуму жрать процессор, который иначе простаивает.
> IIRC, я утилизировал Gbps, используя scp на i7 (на клиентской стороне)
> и ещё много ресурсов CPU осталось свободными.если кто-то сможет печатать с такой скоростью, пусть даже не особо осмысленно… мы всё ещё о чате говорим?
> А пока давайте поделим на 1000, чтобы дойти до уровня сравнительно
> высоконагруженного чат-сервера. Хотите сказать, что RPi в 1000 слабее i7 (в
> рамках данной задачи)?вообще-то, загрузить в максимум одно соединение и загрузить сотни — задачи совершенно разные. по многим причинам — начиная от замусорености кэшей процессора.
>> Разница в том, как это выглядит перед пользователями, если делать настолько же
>> удобно для тупого пользователя, как начали делать в subj-вом проекте. Там
>> нет необходимости заходить сначала на guest-а, чтобы получить ник, а только
>> потом логиниться с данным ником. Можно сразу заходить с новым ником.
> без разницы. те, кому это «с разницей», с воплями убегут уже от
> одного вида терминала.Моя девушка не убегает от вида терминала. Но осилить идею захода из под guest-а для регистрации она уже может не суметь.
>> Предлагаете в motd высветить запрет использования root или как?
> зачем? ник занят — это получается само просто потому, что система проверяет
> существующих пользователей. ну, если кому-то нечего делать — пусть долбится и
> пытается угадать ключ. авось умрёт от истощения.Если делать без guest-овой учётки (то есть сделать мега-костыль в pam, разрешающий логиниться каждому незнакомому пользователю), то попытка залогиниться из под уже занятых логинов будет неуспешной, но без разжёвывания причины в достаточной мере, чтобы понял тупой пользователь (который впервые сталкивается с ssh).
Но я так понял, вы настаиваете на том, чтобы заходить сначала из под guest-а, так что ладно, пусть данная проблема пока будет неактуальной.
>>>> Это одна из мелочей, с которой нужно смириться. Другая из мелочей, что
>>>> будет использовано намного больше ОЗУ.
>>> «намного больше» — по сравнению с чем?
>> В сравнении с хорошо написанным сервером, который всех обрабатывает одним процессом (но
>> не потоком).
> без проверок это чистой воды спекуляция. думаю, нет особого смысла обсуждать, не
> имея в руках чисел.Ок, согласен.
>>> я повторно скажу, что большинство страниц будут shared.
>> 1. Страница - это обычно от 4КБ. Изменяем один байт и все
>> 4КБ сжирают дополнительную страницу.
> и фиг с ним. сто пользователей — 400 кб. да полноте, пусть
> даже четыре мегабайта. тысяча — сорок мегабайт.Думаете изменённые байты уложатся в 100 страниц? Мне кажется, это аналогичным образом требует проверки. Не удивлюсь, если и 500-1000 страниц будут отличаться (там один int изменился, там один uid_t, там один static pid_t, там один char* через отдельный malloc() и т.п.).
>> 4. Это мелочь, но всё-таки проблема не только в fork(), но и
>> в том, что будет больше разных процессов. Каждый раз будет иметь
>> свои какие-то прилинкованные библиотеки, "обёртки" (для обработки аргументов, конфигов
>> и т.п.), реализации интерфейсов для взаимодействия между процессами и др.
> всё это как раз и идёт в shared. shared libraries — они
> ещё и потому shared, что система умеет их mmap'ить. если, конечно,
> сборщик потрудился их с -fPIC собрать.1. Не всё, а только so-шки. Тот же дополнительный интерфейс между клиентом и сервером никуда не исчезнет, ибо в случае с subj-вым решением его просто нет (так как "клиент" и сервер -- это один процесс).
2. Я в курсе по поводу so-шек, но я видать криво выразился про нагрузку разными so-шками (ибо программы разные). Иначе я бы не писал, что это мелочь :)>> Да, я это предполагал такое решение в другом комментарии выше. Но тогда
>> начинается новая волна проблем:
> один из вариантов. а вообще — ну, будет куча пользователей в системе.
> ну и что? как часто надо усердно читать соответствующие файлы глазами?Всякие useradd и иже с ним работают очень медленно (проверенно на Debian/Wheezy).
> и что мешает при нужде выгрепнуть оттуда всех, у кого в
> login shell клиент прописан? да пусть будут. ну реально, обработать текстовый
> файл даже с сотней тысяч строк, учитывая, что это надо далеко
> не каждую минуту даже… пофигу. нет в этом никакой проблемы. ну,
> уйдёт на логин пол-секунды.IMHO, просто это слишком серьёзное замусоривание системы ради всего лишь чат-сервера.
>> уже почти 1200 star-ов на github-е, что очень много для столь
>> молодого проекта (проекту лишь почти месяц).
> на гитхабе обитают идиоты. три с половиной нормальных и идиоты.Ну, не думаю что возможна конструктивная беседа на эту тему :)
>[оверквотинг удален]
>>>>> эти люди покрутят пальцем у виска.
>>>> Не надо мешать в одну кучу пользователей и администраторов сервиса.
>>> и где я смешивал?
>> Тем, кому запрещают ставить другой софт -- это пользователи. А те, кто
>> делает решение -- это администраторы.
> я мягко намекаю на то, что те, кто могут сделать решение не
> через задницу, не испытывают в нём нужды. если пользователю нельзя ставить
> софт — значит, пользователь использует технику работодателя. в любой нормальной
> конторе необходимость нечто доставить для работы решается без проблем. а если
> оно для работы не надо, а надо, чтобы заниматься ИБД… тьфу.Ставить ПО нередко запрещают по чисто бюрократическим причинам (например в некоторых НИИ, где регламентирующая документация сформулирована ещё в СССР и до сих пор действует). И обойти их иногда представляется весьма маловозможным. А надо оно для возможности связаться со знакомыми для консультации по запуску каких-нибудь MCNP (чтобы не диктовать длинные строки по телефону).
>> То есть с вашей точки зрения лучше никакое "решение", чем такое. Я
>> правильно понял?
> совершенно верно. потому что сабж — не решение, а куча говна. причём
> куча говна, которая «решает» несуществующую проблему.
>>> и какая разница? шифрование везде делается библиотеками в машинном коде, а всё
>>> остальное совершенно некритично.
>> Почему некритично?
> потому что дальше всё всё равно упирается в скорость сети.Всякие там blowfish-cbc вроде как достаточно быстро работают, IIRC. А вообще в том же hpn-ssh бывает алгоритм шифрования "none".
>> Шифрование бывает легковесным. Например, есть всем известный hpn-ssh.
> э… это, кагбэ, прямая противоположность «легковесному». оно как раз предназначено
> для того, чтобы по максимуму жрать процессор, который иначе простаивает.Память подвела (возможно как раз из-за наличия шифрования "none" в hpn-ssh). Опять же, прошу извинить.
>> IIRC, я утилизировал Gbps, используя scp на i7 (на клиентской стороне)
>> и ещё много ресурсов CPU осталось свободными.
> если кто-то сможет печатать с такой скоростью, пусть даже не особо осмысленно…
> мы всё ещё о чате говорим?
>> А пока давайте поделим на 1000, чтобы дойти до уровня сравнительно
>> высоконагруженного чат-сервера. Хотите сказать, что RPi в 1000 слабее i7 (в
>> рамках данной задачи)?
> вообще-то, загрузить в максимум одно соединение и загрузить сотни — задачи совершенно
> разные. по многим причинам — начиная от замусорености кэшей процессора.Я в курсе. Но если "shared" действительно будет работать, то кеш (не включая всякие TLB и прочие тонкости) будет существенно эффективнее* . Но что ещё важнее, если представить, что всё обрабатывается одним процессом как в subj-вом решении (а не большим множеством процессов, как предлагаете вы), то тогда кеш будет намного эффективнее по нескольким причинам, наиболее важной из которых является то, что полных переключений контекста будет намного-много меньше.
* наталкивался на статью, где рассказывали про возможность timing attack через l3 cache за счёт дедупликации памяти (могу найти если нужно), то есть как минимум l3 кеш сохраняет эффективность между разными контекстами, если используется одни и те же физические страницы
Но в целом, я вашу позицию понял.
> Моя девушка не убегает от вида терминала. Но осилить идею захода из
> под guest-а для регистрации она уже может не суметь.ты или её сильно недооцениваешь, или она, пардон, по умственному развитию где-то в районе табурета.
> Но я так понял, вы настаиваете на том, чтобы заходить сначала из
> под guest-а, так что ладно, пусть данная проблема пока будет неактуальной.так удобнее всего. заодно отсекает тех, кто вилку в ухо несёт. потому что ниасилить прочитать небольшой файл, зайти гостем и так далее — это уже какой-то клинический дебилизм. зачем такие дебилы в чате?
тем более, что клиент вполне себе может иметь красивый пункт «зарегистрироваться» же после захода гостем. ну ничего сложного вообще, нужно мозга не больше, чем чтобы носок надеть.
рассуждения про память и прочее я скипанул, потому что мы тут оба гаданием на кофейной гуще занимаемся.
>>> Да, я это предполагал такое решение в другом комментарии выше. Но тогда
>>> начинается новая волна проблем:
>> один из вариантов. а вообще — ну, будет куча пользователей в системе.
>> ну и что? как часто надо усердно читать соответствующие файлы глазами?
> Всякие useradd и иже с ним работают очень медленно (проверенно на Debian/Wheezy).тю. это обычные скрипты, которые тупо добавляют записи. ничего магического там нет. ну, перепилить их на сях каких-нибудь. собственно, сервер при регистрации сам и будет строки дописывать, это разумней, чем скрипты дёргать. а с консоли — ну так ли часто надо юзера добавлять? мне если десяток раз за десяток лет понадобилось, то хорошо.
> IMHO, просто это слишком серьёзное замусоривание системы ради всего лишь чат-сервера.
да какое замусоривание-то? эти юзеры и так существуют, только без имён. ну, дали им имена — подумаешь. любой нормальный менеджер логинов достаточно умный для того, чтобы игнорировать юзеров, у которых «неправильные» login shell стоят, или они не в группе users, например. так что никто, в общем-то, и не заметит. к тому же вряд ли это будет рабочая машина — потому тем более без разницы.
я вообще не понимаю, откуда у людей эта «боязнь большого количества пользователей». не в первый раз её вижу, но никто не может пояснить, чем же оно так мешает. в системе-то всё равно UID используется, и все миллиарды UID'ов всё равно равноправны. то есть, в системе *уже* миллиард пользователей — но никого это не парит. а записи в /etc/ — парят. странно.
> Ставить ПО нередко запрещают по чисто бюрократическим причинам (например в некоторых НИИ,
> где регламентирующая документация сформулирована ещё в СССР и до сих пор
> действует). И обойти их иногда представляется весьма маловозможным.очень возможно. называется «заявление на увольнение по собственному желанию». не надо работать там, где идиотизм возведён в правило.
> Всякие там blowfish-cbc вроде как достаточно быстро работают, IIRC. А вообще в
> том же hpn-ssh бывает алгоритм шифрования "none".telnet есть даже в винде. ну, был раньше — не помню, убрали ли уже. на кой тогда заниматься сексом с ssh, если шифрование выкинуть?
> Но в целом, я вашу позицию понял.
ок.
p.s. слушай, ну надоело же уже, ну обращайся ты на «ты». зачем это идиотское «выканье» сюда тащить?
> Так вот, как сделать авторизацию ника через SSH-ключи?Посмотреть - показал ли клиент претендующий на резервированный ник ключ. Если не показал - фиг ему. Это наверное даже к IRC можно прикрутить - клиентские сертификаты SSL местами вон прикрутили.
> Откуда такая информация?Да не обращайте внимания, это arisuka немного тупит, особенно вот здесь:
>> не надо писать ещё один дырявый сервер для занятий ерундой, достаточно сменить
>> login shell на какой-нибудь убертупoй клиент для какой-нибудь болталки. собственно,предлагая форкать замену логин шелла на каждого юзвeря, что будет создавать нехилую нагрузку на RaspberryPi с его Pidоra, на котором вся эта фuгня будет крутиться.
>> Откуда такая информация?
> Да не обращайте внимания, это arisuka немного тупит, особенно вот здесь:На opennet не так много людей, которых мне читать интересно. А arisu один из таких. Так что я не против пообщаться, и я вполне уверен, что его позиция не с пустого места появилась. Если бы ещё вспылял поменьше :)
скажи, а нормальные дети у твоих родителей были? или только такие дебилы, как ты?
А что на счёт его аргумента с fork-ами?
> А что на счёт его аргумента с fork-ами?я не вижу у него ни одного *аргумента*. то, что он идиот и у него «приветмир» выдаёт семнадцать ошибок и тридцать четыре ворнинга — никакой не повод пытаться с ним беседовать.
> А что на счёт его аргумента с fork-ами?вкратце: последнее, что в описаном сценарии волнует — это форки. которые всё равно будут иметь почти всю память шареную. его чебурашка задохнётся намного раньше — её шифрование раком поставит.
> раньше — её шифрование раком поставит.Не знаю как там пи, но напрмер allinner одноядерный достаточно спокойно относится к шифрованию и шифровать поток порядка полмега в секунду его не напрягает вообще. В смысле на мониторе загрузки проца там есть какой-то мизер весьма далекий от 100%. А чтоб его раком... подозреваю что он и полные 100Мбит смолотит :)
а теперь подумай о том, что один поток и сто потоков — вещи разные. оно только кэшами заколебается щёлкать.
А может этот Андрей Петров себя решил по пиарить и у него связи с opennet?
используй слова в соответствии с их значением
Человек попытался напомнить, что SSH можно использовать не только для замены telnet'у, что можно легко переюзать качественное шифрование, как это сделано на том же гитхабе: зашёл в вебморду, вписал свой ключ и живи нормально, прозрачная авторизация во все нужные места - быстро, просто, удобно, безопасно...
Ананитики доскипались до всего, от языка на котором по быстрому был пример сделан, до "вау, если ты админ сервака, можешь сам себе туннель пробросить", но юзкейс никто не осилил, все готовы дальше долбиться в дырявый ssl с криво самоподписанными ключами (которые нифига не защитят от MITM с таким же самоподписанным говном), каждый час набирать одни и те же пароли или вообще хранить их в "почти не дырявом" браузере, а заодно и вовсе использовать один и тот же пароль везде, т.к. запомнить для всех сервисов сложно, а использовать KeePass религия не позволяет.
Вам оно не нужно? Ну и валите дальше, чё вы тут лужи газифицируете, если даже не пытались сабж понять?
у тебя айфон перегрелся.
Говори за себя, я не фанбой огрызкофонов, у меня cyanogen стоит на нормальном смарте с нормальной QWERTY-клавой
> Говори за себя, я не фанбой огрызкофоновМожет быть он намекал на мыслительные способности твоего мозга? ;)
> у меня cyanogen стоит на нормальном смарте с нормальной QWERTY-клавой
Нет, ну сейчас бывает и так что смарт умнее своего хозяина. Поэтому живет своей жизнью, работая на благо левых хренов.
>воспользовавшись уже готовыми и проверенными средствами аутентификации, шифрования и мультиплексирования соединений
>Утечка документов из АНБ свидетельствует о небезопасности SSH, PPTP, IPSec и TLS
>https://www.opennet.ru/opennews/art.shtml?num=41356
го, я создал. ssh chat.pizd.ec
