31.10.2024

Использование SSHFS в качестве удобного решения при работе с файлами через SSH

Сегодня я хотел бы рассказать об SSHFS — одном из тех инструментов, который я достаточно часто применяю в работе во многих случаях, в частности например при необходимости поработать напрямую с файлами на удаленном сервере через SSH.

Предыстория

В стародавние времена, когда я разрабатывал еще свои первые сайты, среди программистов было модно загружать исходники на хостинг через FTP, для чего в основном использовалась FileZilla. В случае, если файлов было много, то это работало ощутимо медленно из-за особенностей работы протокола FTP и поэтому иногда проект паковался в единый архив, отправлялся на сервер и затем подключаясь к серверу по SSH через PuTTY, делали распаковку на сервере. Да-да, можно вспомнить и про rsync и команду scp (и ее аналог pscp в PuTTY), но я тогда был малоопытным разработчиком и не очень был хорошо знаком с этими утилитами, а вот c загрузкой по FTP в то время были знакомы практически все веб-разработчики.

Более существенной проблемой была ситуация, когда на сервере необходимо было часто и много работать с какими-то мелкими файлами или еще что-то в этой роли. Допустим что-то скорректировать, разобрать и пр. В таком случае, надо было выкачать себе весь проект, а уже на своем компьютере, изучать его содержимое, либо выдергивать по несколько файлов и отдельно их изучать, из за чего было неудобно работать из под редакторов кода.

Сразу отмечу, что в современной разработке все эти вышеописанные подходы уже все меньше используются, особенно с учетом повсеместного использования подходов CI/CD и автоматизации всего и вся. Поэтому не стесняемся использовать современные подходы.

Так вот, вернемся к повествованию, ибо тогда я как раз во всю изучал вопрос использования Linux на десктопе и все меньше пользовался Windows. И естественно ковыряясь в различных возможностях Linux систем в качестве десктопной системы разработчика, я познакомился с технологией FUSE.

FUSE

Если вкратце, то FUSE это такой особый модуль ядра Linux, который предоставляет программный интерфейс для создания кастомных файловых систем, позволяя им работать в пространстве пользователя. Фактически с помощью этого модуля вы можете сделать представление файловой системы из чего угодно, например из архивов, поверх каких-либо сетевых протоколов и т.д., Впринципе можно сказать, что FUSE дает вам абстрактный механизм для реализации файловой системы, при этом со стороны пользователя это будет выглядеть как обычная файловая система, просто физически данные могут храниться где угодно и в любой форме.

В общем, т.к. мне по работе приходилось часто работать с внешними FTP, что меня местами раздражало, я стал пытаться как-то упростить себе работу и мне на глаза попался проект CurlFtpFS, который использует FUSE и представляет собой реализацию файловой системы поверх обычного FTP. Т.е. мне было достаточно просто примонтировать удаленную FTP-директорию к своей директории например /home/user/my_mount_point и после этого я мог работать с удаленным FTP так, как будто это обычная локальная директория на компьютере. Соответственно при этом можно было использовать всякие IDE и прочее софтварное добро.

Тем не менее, у CurlFtpFS был серьезный минус, заключающийся в его медлительности, ибо в основе этой системы лежал все тот же древний протокол FTP, со всеми его минусами, да и в общем-то эта штука достаточно устаревшая. Поэтому вскоре я обратил внимание на SSHFS.

SSHFS

SSHFS — виртуальная файловая система, работающая через FUSE и позволяющая монтировать удаленные файловые системы, доступные по SSH соединению. Работает это вполне шустро, плюс мы получаем все плюшки от работы с SSH, такие как возможность монтирования файловой системы по ключу и шифрование передачи данных. Еще один плюс от использования SSHFS состоит в том, что на сервере вам ничего не нужно дополнительно доустанавливать, т.е. все работает с использованием самого SSH.

В работе, я честно говоря, уже настолько привык использовать SSHFS, что на небольших проектах использую (если нет CI/CD) его вместо rsync (за исключением крупных проектов), просто потому что вечно не могу запомнить, какие ключи надо передавать rsync, а SSHFS достаточно прост, плюс к этому все дальнейшие действия представляют собой обычные файловые операции.

Даже в случае с VSCode и Remote Development, когда я работаю внутри Docker-контейнера на своем девелоперском сервере и мне нужно что-то поковырять на другом сервере в каких-то файлах, я просто монтирую их к какой-нибудь папке и работаю с этими файлами напрямую средствами IDE. В таком случае использование SSHFS намного удобнее, чем гонять туда-сюда файлы через rsync или scp.

SSHFS является достаточно популярной и есть практически во всех современных дистрибутивах. Монтирование файловой системы SSHFS достаточно простое:

sshfs user@example.com:/remote_path/ /local_path_to_mount_point

Если у вас SSH-соединение с удаленным сервером работает по паролю, то после вышеуказанной команды у вас будет запрошен пароль. В общем тут все как при обычном SSH соединении, поэтому по возможности лучше используйте SSH-ключи, с которыми все будет проще, особенно в случае реконнектов при обрыве соединения.

Естественно, помимо монтирования этих файловых систем, иногда надо их и размонтировать, для чего вы можете воспользоваться командой fusermount3, как на примере ниже:

fusermount3 -u /local_path_to_mount_point

Обратите внимание, что команда fusermount3 начала использоваться в Ubuntu 22.04, а в более ранних версиях требовалось использовать команды fusermount и umount.

Нюансы файловых путей, которые стоит учитывать при использовании SSHFS

Одним из коварных нюансов работы с файлами через SSHFS является формирование путей. Надо понимать, что SSHFS монтирует виртуальную файловую систему и пути файлов в ней имеют мало общего с реальными путями к файлам на сервере.

Что-бы обьяснить суть проблемы, давайте представим пример, в котором у нас есть какой-то конфиг (config.json), в котором у нас примерно такая структура:

{
  "module": [
    "/var/www/modules/module-1.tar.gz",
    "/var/www/modules/module-2.tar.gz"
  ]
}

Т.е. в конфиге у нас есть абсолютные пути к модулям. Почему тут пути именно абсолютные, а не относительные, в данном случае не важно, поскольку в проекте у нас может вместо такого конфига оказаться любой другой файл, который вполне может требовать таких путей (например какой-нибудь временный файл, кеширующий обращение к каким-нибудь ресурсам или что-нибудь другое).

Как пример, у нас будет такая структура файлов на удаленном сервере:

/var/www/config.json
/var/www/modules/module-1.tar.gz
/var/www/modules/module-2.tar.gz

В итоге, решаем примонтировать "/var/www" куда-нибудь в локальную директорию, например "/home/your-user/mounted-project/".

Итого уже в своем файловом менеджере вы будете видеть:

/home/your-user/mounted-project/config.json
/home/your-user/mounted-project/modules/module-1.tar.gz
/home/your-user/mounted-project/modules/module-2.tar.gz

Допустим в вашей IDE есть какой-нибудь умный модуль, который при нахождений новых модулей, будет автоматически их импортировать в конфиг. И в таком случае, при добавлении нового модуля "/home/your-user/mounted-project/modules/module-3.tar.gz" может случиться проблема, т.к. IDE (или плагин или еще какая-нибудь утилита) не знает, что "/home/your-user/mounted-project/modules/" является примонтированной виртуальной файловой системой (удаленно расположенной) и в конфиге может получиться такая чепуха:

{
  "module": [
    "/var/www/modules/module-1.tar.gz",
    "/var/www/modules/module-2.tar.gz",
    "/home/your-user/mounted-project/modules/module-3.tar.gz"
  ]
}

Этот пример очень абстрактный, ибо я просто постарался показать, что при монтировании таких виртуальных файловых систем, надо осторожно работать с файловыми путями и учитывать в уме реальное расположение файлов.

Заключение

В заключение хочу уточнить, что я всегда использовал SSHFS только из под Linux и не могу ничего сказать за то, как его реализации работают под другими операционными системами и вполне возможно там есть какие-то свои особенности.

В остальном, я хочу сказать, что SSHFS является очень полезным инструментом, позволяющим задействовать различные редакторы кода, графические редакторы и пр. программы, установленные на локальной машине. Да и множество других трюков можно выполнять, например локально примонтировать какую-нибудь директорию из запущенного на внешнем сервере Docker-контейнера для более удобной работы. В общем предназначений у SSHFS может быть множество, просто при этом советую вам стараться не забывать использовать его безопасно и разумно.