SSHFS это виртуальная файловая система, которая позволяет представить любой ssh-ресурс в качестве папки в Linux или сетевого диска в Windows.
Для организации такого диска лучше использовать специальную утилиту, позволяющую удобно настроить и в один клик подключать сетевые диски по протоколу ssh.
Чтобы скачать эту утилиту, нужно перейти по ссылке https://github.com/evsar3/sshfs-win-manager
Установка.
Чтобы пользоваться, на удаленной машине необходимо использовать openssh-server, он существует, как для Linux так и для Windows.
На клиентскую машину необходимо установить три компонента:
WinFsp — реализация прослойки FUSE, как в Linux, которая не зависит от фактической файловой системы.
SSHFS-Win — программа для подключения ssh ресурсов как сетевых дисков.
SSHFS-Win-Manager — утилита для пользователя.
Первые две распространяются по лицензии GPL, последняя имеет спекулятивную лицензию MIT.
Для упрощения задачи установки я собрал эти программы в архив и написал пакетный файл для автоматизации установки.
Получить их можно здесь (просто архив 7z, где взять 7z?, обычно он уже встроен в Windows10, но если нет, то качаем с официалов или с меня).
После распаковки нужно перейти в папку, куда было распаковано содержимое архива и запустить файл sshfsi.bat и следуем подсказкам установщиков. Вполне возможно, что может понадобиться запуск от имени администратора.
Вид настроенной и установленной утилиты показан на картинке ниже:
После установки достаточно настроить ресурсы, которые потом будут подключаться и выглядеть, как локальные диски.
Если удаленная машина работает на Linux, то нужно указать путь к ресурсу на удаленной машине в формате unix-way, например /mnt/Z, или /home/user, если вы хотите подключить свой домашний каталог на удаленной машине и обращаться к нему из проводника как к локальному диску (например это будет диск Z:).
Если удаленная машина работает на windows, то пути к ресурсам будут выглядеть как C:\, D:\, или C:\папка, D:\папка.
Откроется окно настройки подключения:
Здесь в поле NAME необходимо указать имя ресурса, так он будет отображаться в системе Windows, в качестве метки тома.
В поле IP/HOST требуется указать ip-адрес машины, либо доменное имя удаленного ПК. Если подключение выполняется по локальной сети и настроен локальный DNS, то сетевое имя будет host.local или host.yourdomain.local, в зависимости от настройки, в любом случае host это либо имя машины, либо его IP адрес.
В поле PORT необходимо указать «порт» на котором «слушает» удаленный ssh, стандартный порт 22, но он может быть и другим. Если удаленный компьютер находится за NAT (роутер, шлюз), то на роутере необходимо выполнить «проброс» портов. В локальной же домашней сети ничего делать не нужно.
В поле USER необходимо ввести имя пользователя, это реальный пользователь на удаленной машине, поэтому если удаленная машина работает на windows, то для безопасности необходимо установить строгие права доступа к папкам, либо дискам, если удаленная машина на linux и не требуется удаленного администрирования, то лучше настроить chroot для пользователей, которые будут подключаться к машине и в этот chroot прокидывать разделы, к которым должен быть доступ извне.
Поле AUTHENTICATION METHOD предлагает один из трёх способов авторизации на удаленной машине. Пароль сохраняемый в программе и пароль, спрашиваемый при каждом подключении, или же по открытому ключу. Какой способ авторизации использовать, выбирать читателю, это выходит за рамки данной статьи.
В поле PATH должен быть указан полный путь к папке на удаленном ресурсе. У каждого пользователя он будет свой, если удаленная машина разрешает, то можно подключиться и к корневому каталогу «/»
Поле DRIVE LETTER снабжено выпадающем списком и предлагает назначить любую не занятую букву как локальному диску.
После ввода данных требуется сохранить параметры.
Данное окно закроется и останется главное окно программы:
…в котором необходимо нажать на кнопку «подключить» (смотри картинку выше).
Если всё нормально, то ресурс будет подключен, а в проводнике отобразится новый диск, как локальный:
В Linux ничего устанавливать обычно не требуется, любой ресурс SSH подключается из файлового менеджера методом «подключиться к серверу», система всё сделает самостоятельно.
Но всё же можно сделать это красивее.
Например, в Linux реализовано это либо через gvfs, тогда удаленный ресурс будет виден в адресной панели, как подключенный ресурс, а не как раздел, либо можно использовать непосредственно sshfs:
Для этого сначала нужно создать пустую папку в домашнем каталоге пользователя с помощью любимого файлового менеджера например создадим папку c названием Y, а затем выполним команду для подключения удаленного ресурса к локальной машине с использованием sshfs:
$ sshfs user@192.168.0.244:/media/user Y/
этой командой мы подключаем удаленный каталог к папке Y на локальной машине.
Плюсы такого способа:
- Отсутствуют системные ограничения на размер файла. Это значит, что вы можете делать бэкапы по зашифрованному каналу без ограничений на размер файла.
- Подключенный ресурс работает как локальный диск и его можно использовать напрямую.
- Нет прослоек в виде веб-серверов типа Apache2 или IIS.
- Не требуется SSL сертификат, соединение зашифровано.
- Одинаково хорошо работает как в Windows, так и в Linux.
Минусы:
- Возможные ограничения на работу протокола SSH провайдером, если вы работаете с удаленным ресурсом через Интернет. В этом случае требуются меры для маскировки трафика под https.
- Возможно снижение скорости обмена данными на узких каналах из-за шифрования.
- SSH хоть и хорошая вещь, но не панацея, существуют известные уязвимости серверной части, поэтому при работе через Интернет необходимы индивидуальные средства защиты от вторжений.
- Для работы требуется назначение жестких прав доступа к файлам.
А почему не WebDav?
Есть несколько причин, по которым я вижу Webdav плохим решением для организации облачного или сетевого хранилища.
Оставим в стороне факт, что webdav разработан корпорацией Microsoft и его реализация за пределами Windows и коммерческих решений выглядит не лучшим образом. Но причины выглядят следующим образом:
- Сложность настройки сервера. Для того, чтобы настроить сервер на работу с WebDav требуется использовать IIS на Windows и любой web-сервер на Linux-системах. Требуется доменное имя и SSL-сертификат. На 2025 год у нас практически не осталось клиентов, которые бы не требовали TLS-шифрования http — трафика. И подключиться к webdav-ресурсу без шифрования в 2025 году будет проблемой.
- Встроенные ограничения на размер файла в операционных системах. В Linux на трафик по протоколу WebDav действует ограничение в 2 Гб на один файл. Причем я не смог выяснить можно ли снять это ограничение. Но раз keenetic — производитель сетевого оборудования смогли снять это ограничение, значит способы есть и они закрыты коммерческими лицензиями, и именно поэтому нет вразумительных ответов на запросы, связанные с ограничением. А такие решения, как Nextcloud вносят больше проблем при работе по WebDav, чем пользы.
В Windows ограничения изменяются разными методами. Полностью не снимаются, но их можно отодвинуть.
Что я такого большого перекачиваю в одном файле? Не ваше дело. - Сложность с доступом к ресурсу по WebDav с разных устройств. Я на себе испытал эту проблему. Проводник Windows, любые файловые менеджеры Linux и Андроид по-разному ведут себя с одним и тем же webdav ресурсом. И нет единого способа подключиться к одному ресурсу. Поэтому на данный момент webdav мной практически не используется.
Положительные стороны использования webdav:
- Заранее определенный каталог для работы, изолированный от остальной системы.
- Возможность работы с виртуальными пользователями.
- Простая организация скачивания ресурсов.
Самый главный плюс это отсутствие необходимости создания реальных пользователей системы. Все пользователи виртуальные, но имеют свои собственные права доступа к файлам. Никто не может выйти за пределы разрешенного каталога и не может использовать ресурсы системы во зло.
Вместо вывода.
Существующие протоколы доступа к файлам через сеть имеют и недостатки, и достоинства. В одном случае необходимо минимум настроек и времени на организацию, но зато протокол имеет единый стандарт и работает с удаленной системой на уровне этой самой систем. В другом случае мы имеем костыль в виде надстройки над надстройкой, чтобы организовать какой-то способ хранения данных. По мне он выглядит малонадежным и слишком сложным для организации хранилища, отвечающего единому стандарту хранения и обмена данными. Однако, благодаря TLS шифрованию он может применяться как способ организации виртуальных хранилищ данных, таких как известные облачные сервисы.
Что применять, выбирать Вам.