From bf0ceec48f161368404d4ce40a278195777e8149 Mon Sep 17 00:00:00 2001 From: Sergey Matveev Date: Tue, 17 Mar 2026 13:11:21 +0300 Subject: [PATCH] =?utf8?q?=D0=90=D0=BD=D0=BE=D0=BD=D0=B8=D0=BC=D0=BD=D1=8B?= =?utf8?q?=D0=B5=20rsync=20=D0=B8=20SFTP?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit 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 соединения для данных. -- 2.52.0