Протоколы обмена файлами, IPsec, удалённый доступ

В моём идеальном мире между компьютерами должен быть IPsec.
Аутентифицированный, всё такое. А не костыли транспортного уровня типа
TLS per-application. Мне поэтому жутко не нравится когда протоколы
делают без возможности использования TLS (ну вроде HTTP/2 хотели же) или
когда говорят что FTP это не безопасно. Если поверх аутентифицированного
доверенного IPsec, то какие проблемы?

Кроме IPsec у меня на моих машинах гоняется и SSH. Вот зачем он мне? Для
управления компьютерами вне IPsec (его же тоже нужно как-то настроить
предварительно) конечно нужен, а в общем случае нет. Могу ли
использовать старый добрый telnetd для этого? Попробовал -- могу, вроде
бы всё терминальное (tmux там) работает. А вот все утилиты типа rlogin,
rsh, rcp убраны уже в моей версии FreeBSD. Ну и нужно думать как бы
автоматизировать telnet вход.

А если чуть подольше подумать, то вообще аутентификация по ключам (для
которых локально можно требовать парольную фразу) была бы в любом случае
полезна. telnet намекает на то, что нужно Kerberos использовать. Но у
меня с ним мало что выходило и я его боюсь. То есть SSH поверх IPsec был
бы хорош всем, если бы можно было отключить шифрование трафика, ибо
IPsec это делает. Такой опции из коробки нет. И вообще SSH это про
удалённый доступ, а это значит мало трафика, ибо интерактив для
человека. Поэтому плюнул на telnet+Kerberos идею. SSH всё равно будет
для управления out-of-band IPsec и это уже рабочая инфраструктура,
пускай и с overhead-ом, но для интерактивных сессий не страшного.

А как быть с передачей файлов? NFS работает, но это кардинальное большое
решение, не во всех случаях удобное. scp/sftp не хочется, так как это
уже серьёзный overhead на шифрование, избыточное в IPsec сети. Один файл
можно передать и просто по TCP сокету через netcat. Но продолжить
прерванную передачу нельзя, если не считать руками байты и указать их
для какого-нибудь dd при повторном запуске. python -m SimpleHTTPServer
на одной стороне и fetch/wget/curl позволит продолжить докачку.

tftp сервер просто и быстро поднимается, но всё же это уже больно не
эффективный протокол. Да и, из-за ограничений размеров счётчиков, в нём
только небольшие файлы можно передать. Хотя простота подкупает.

А какие протоколы есть для передачи нескольких файлов, для получения
списка директорий/файлов? FTP -- мамонт, не рассматриваю, хотя он
подходит. Он должен уже не одно десятилетие назад вымереть. Его два TCP
соединения -- та ещё заноза для firewall-а, да и много архаичного в нём,
совершенно не актуального и избыточного для современного мира. lftp
утилита позволяет одной командой зеркалировать целые FTP
серверы/директории. SFTP -- подходит, но, как уже писал, ненужный
overhead в IPsec сети.

Я надеюсь что 9P на практике окажется очень здоровским протоколом,
который бы и NFS наверное заменил. Но в FreeBSD его поддержка будет
только в следующем релизе.

Вспомнил про WebDAV. Который даже позволял из коробки в Windows 98
монтировать удалённые директории. Работало это на Windows у родителей не
очень -- уже не помню конкретики, но вроде просто нестабильно. Но WebDAV
чисто в теории мне нравится относительной простотой, возможностью
использовать без WebDAV клиента (curl хватит или даже броузера), всякими
докачками. В принципе годное решение. Да и всякие lighttpd/apache имеют
из коробки webdav модуль.

rsync ещё могу вспомнить, который по своему собственному протоколу может
работать, без всяких SSH. В отличии от FTP, SFTP, WebDAV -- с большим
количеством файлов/директорий он очень эффективен для зеркалирования.
Никогда не пробовал, но man говорит что и докачивать файлы может
(--append). Тоже годное решение, особенно учитывая что rsync часто есть
на компьютерах и его демон настраивается куда проще чем HTTP-серверы.

FISH https://en.wikipedia.org/wiki/Files_transferred_over_shell_protocol
мог бы быть интересен, но отдельного клиента с ходу для него не увидел.
lftp поддерживает fish://, но при этом запускает его поверх SSH насильно.

UUCP мог бы отправлять/докачивать файлы в обе стороны -- в нём есть
возможность не копировать файл в spool область. NNCP может только через
копирование. Но это уже настройка знаний между компьютерами (хотя UUCP
может и анонимным быть).

Kermit решение вспомнил. http://www.columbia.edu/kermit/ckututor.html
И Zmodem вместе с ним: https://ohse.de/uwe/software/lrzsz.html
В lrzsz даже есть сразу поддержка TCP сервера-клиента и протоколов без
коррекции ошибок (IPsec же!). Списка файлов нет. Но... по IPv4 оно у
меня заработало, а по IPv6 нет -- ругается на какой-то format3, наверное
адреса. Kermit, судя по исходникам, аналогично с IPv6 не должен дружить,
но в нём хотя бы уже и списки файлов можно было бы получать. Но так
можно накопать уже тьму другую софта, особенно ориентированного для
быстрой передачи данных (из единственного TCP соединения сложно выжать
скорость).

комментарий 0:

From: kmeaw
Date: 2020-12-15 01:56:57Z

А можно ли настроить какую-нибудь существующую реализацию IPsec таким
образом, чтобы аутентифицировать не машину, а человека, который за
машиной сидит?

То есть я хочу что-то вроде IDENT, но правильно спроектированное. Чтобы
я на другом конце мог писать фаервольные правила, фильтрующие не
IP-адреса, а людей. А в совсем хорошем случае - ещё и из прикладных
программ узнавать, кто к ним по сети пришёл. Как с клиентскими
TLS-сертификатами.

> Ну и нужно думать как бы автоматизировать telnet вход.

rfc2941

> То есть SSH поверх IPsec был
> бы хорош всем, если бы можно было отключить шифрование трафика, ибо
> IPsec это делает.

https://gitweb.gentoo.org/repo/gentoo.git/tree/net-misc/openssh/files

ssh -o Ciphers=none

Жаль, что

> Такой опции из коробки нет.

> rsync

Мне как-то нужно было скачать один файл с удалённого сервера (без
докачки, всегда от начала и до конца) и запайпать его в другую
программу. Из коробки клиент rsync так не умеет. Я попытался написать
свою реализацию, и с удивлением обнаружил, что протокол оказывается
недокументирован.

> Zmodem ... Списка файлов нет.

В те времена его чаще всего передавали с помощью файла FILES.BBS.

> по IPv6 нет

lrzsz и kermit наверняка можно попытаться подружить с inetd и netcat,
чтобы им не пришлось ничего знать про IPv6.

> А какие протоколы есть для передачи нескольких файлов, для получения
> списка директорий/файлов?

Лет 10 назад я придумал один очень странный протокол, работающий поверх
TCP. Он очень зависит от системы, но у него есть масса применений.
У меня есть его реализация для Linux/amd64. Описать его можно буквально
парой фраз: в момент подключения сервер посылает клиенту слово, которое
позволяет клиенту идентифицировать платформу и версию протокола; затем
клиент посылает семь машинных слов (номер syscall и его аргументы), а
сервер их выполняет и отвечает одним словом (return value). Вызовы read
и write всегда выполняются до конца (сервер докручивает partial
reads/writes до успеха или до первой ошибки).

С его помощью можно и файлы передавать, и директории просматривать, и
вообще почти что угодно делать, не внося изменений в реализацию сервера,
которая занимает меньше килобайта памяти.

комментарий 1:

From: Sergey Matveev
Date: 2020-12-15 07:34:07Z

*** kmeaw [2020-12-15 04:51]:
>А можно ли настроить какую-нибудь существующую реализацию IPsec таким
>образом, чтобы аутентифицировать не машину, а человека, который за
>машиной сидит?

Существующую -- думаю что нет. Ведь даже better-than-nothing-security
IPsec, когда одна из сторон может быть "анонимной" (использовать голый
ключ, без идентификаторов), я не встречал реализованного. А вообще
PF_KEYv2 позволяет задавать (опять же, в FreeBSD этого нет, в OpenBSD и
GNU/Linux вроде бы что-то заложено) per-socket желаемые идентификаторы
аутентифицируемого соединения и ими же могут быть X.509 сертификаты с
"конкретным" человеком, а не доменом. Per-socket PF_KEYv2 правила не
привязаны к IPv6 адресам или доменам. Но это всё в теории и в каких-то,
возможно не работающих, реализациях только. На уровне IKEv2/SP точно
можно было бы фильтровать людей, ну а получить identity в прикладном ПО
тем более. На сию минуту конечно же нет. Что и печально, ведь не сложно
и сами по себе ESP/IKE готовы для всего этого.

>> Ну и нужно думать как бы автоматизировать telnet вход.
>rfc2941

Да я не сомневаюсь что оно есть, даже в man к этому отсылки видел.
Просто сам не дошёл до этой настройки.

>ssh -o Ciphers=none

Да это то я видел. Но из коробки (у меня) такого нет.

>Мне как-то нужно было скачать один файл с удалённого сервера (без
>докачки, всегда от начала и до конца) и запайпать его в другую
>программу. Из коробки клиент rsync так не умеет.

Это да. Ну для pipe-а уж совсем простые решения (netcat) есть.

>Я попытался написать
>свою реализацию, и с удивлением обнаружил, что протокол оказывается
>недокументирован.

Я когда писал "протокол синхронизации" для NNCP, то тоже об этом узнал.
Хотел реализовать rsync внутри NNCP, хотя бы подмножество.

>В те времена его чаще всего передавали с помощью файла FILES.BBS.

Я сейчас даже для NNCP делаю аналогично и у меня по cron-у генерируется
большой сжатый список файлов хранилища. http://www.nncpgo.org/FreqIndex.html

>lrzsz и kermit наверняка можно попытаться подружить с inetd и netcat,
>чтобы им не пришлось ничего знать про IPv6.

Безусловно! Тем более что, в общем случае, они же и рассчитаны на работу
с stdin/out чтобы их прозрачно подключать к терминальным программам.
Просто каждое такое действие уже означает что нельзя так просто взять и
сделать pkg install whatever и быстренько начать работать с этим.
Впрочем, конечно, как и с rsync (демон настроить), webdav и всем
остальным.

>клиент посылает семь машинных слов (номер syscall и его аргументы), а
>сервер их выполняет и отвечает одним словом (return value).

Звучит круто и красиво по хакерски!