https://datatracker.ietf.org/doc/html/draft-ietf-secsh-scp-sftp-ssh-uri-04
В
3136e07d90bf973abaf9fda3bad7e343a58c0be6 упоминал про то, что можно
сделать анонимный Git SSH доступ. В
f514d4292f5331c23293e65bce01a67b771004d7
упоминал про создание SFTP-only учётной записи.
А кто мешает сделать SFTP-only учётку для "анонимного" пользователя? Но
чтобы read-only запись была?
Match User anonwww
PasswordAuthentication yes
PermitEmptyPasswords yes
DisableForwarding yes
PermitTTY no
ChrootDirectory /home/www/www
ForceCommand internal-sftp -R -d /home/www/www
И теперь вообще все мои web-сайты доступны для скачивания через SFTP.
Ничего скрытого в них нет, поэтому отдана вообще вся www директория.
Без всяких TLS с этим X.509 сертификатами и проблемами с CA,
аутентифицированный (TOFU) и шифрованный файловый сервер. Можно так и
tarball (
a7a8c413b750923b24592d77985372b05b65f05f) получать:
scp anonwww@msk.www.cypherpunks.su:goredo.cypherpunks.su/download/goredo-2.9.1.tar.zst
scp anonwww@spb.www.cypherpunks.su:goredo.cypherpunks.su/download/goredo-2.9.1.tar.zst
Есть черновик RFC для указания sftp:// URI, в котором даже есть
возможность указания отпечатка ключа хоста. Но там предлагают MD5
использовать. Нет, на такое не пойду. ssh-keygen -l вывод делает по
умолчанию SHA-256, но в чистом (не urlsafe) виде, что не пригодно для
вставки в URI as-is. Поэтому пока забил на отпечатки.
Удивительно много людей надрессированы желать HTTPS даже для скачивания
tarball-ов (
087600cd166642c95809f63d4de0342d705d1c6a), проверяемых
напротив заранее известных контрольных сумм. Но при этом никогда, ни
разу не встречал чтобы люди просили обезопасить rsync точки входа! Хотя,
скорее всего, это два разных непересекающихся множества людей. Впрочем
на многих страницах с описанием зеркал, очень хотят HTTPS, опционален
HTTP, но rsync дают as-is. Нигде не встречал rsync защищённый TLS-ом. Но
много людей используют rsync через SSH.
Так что же мешает сделать "анонимный" SSH-secured rsync доступ?
-- /etc/ssh/sshd_config --
[...]
Match User rsync
PasswordAuthentication yes
PermitEmptyPasswords yes
DisableForwarding yes
PermitTTY no
# grep rsync /etc/passwd
rsync:*:1011:1011::/home/rsync:/home/rsync/rsyncd
-- /home/rsync/rsyncd --
#!/bin/sh -e
[ -n "$SSH_CONNECTION" ]
exec rsync --daemon --server --config rsync.conf .
И достаточно добавить --rsh=ssh опцию с указанием пользователя в rsync
команде. Ну и не забыть read only опцию в конфиге включить.
Это всё можно считать дополнением к
befcbeb7b1d647ba15444dde02b87d97399185e5.
Но полноценной заменой SFTP обычному FTP не является. После относительно
коротких команд на чтение/запись (забыл, но что-то типа 64KiB вроде) он
ждёт подтверждение прёма, что из-за задержек будет означать низкую
скорость. HPN-SSH патчи по идее существенно должны помочь с этим, но
лично я ни разу не пробовал их, да и не считаю что через SSH надо
high-performance вещи делать.
Вообще, обычный FTP мне даже начал приглядываться, с тех пор как начал
писать на Си. Ведь действительно очень просто устроен: одно соединение
для отправки строчек с командами, а второе где только чистые байты
проталкиваются с содержимым файлов. Никакого мультиплексирования этих
двух каналов. Даже хочется сказать, что элегантное решение. Но...
геморрой от того как это подружить с firewall-ом: поднимать не хочется.
Хотя ведь можно было бы сделать ещё одно исходящее соединение от клиента
серверу, передавая в нём уникальную cookie, чтобы идентифицировать
связанную с соединением командную сессию. Но если FTP fork-ается для
обработки командного соединения, то значит от главного процесса надо
будет уметь передавать эти соединения с cookie как-то -- уже значительно
сложнее программировать. В общем, что-то в FTP есть, особенно
производительность из-за этого отдельного нехитрого TCP соединения для
данных.