Как расшарить файлы в Linux. SSHFS. Часть 2

Не удержался, чтобы продолжить статью о sshfs, очень удобный способ расшаривания файлов на сервере. Будет рассмотрено автоматическое монтирование по запросу (on demand), т.е. монтирование удаленной директории автоматически происходит при открытии назначенной папки в файловом менеджере (про работу в терминале умолчу). Автомонтирование очень хорошо описано в арчевики, да и вообще хороших хауту существует огромное количество. Моя цель просто напомнить, что такая возможность существует, потому как до статьи на этом сайте, я на sshfs тоже не обращал внимания, а оказалась очень удобной вещью. Поэтому обзор очень короткий.

В настоящее время существует два способа использовать автоматическое монтирование: старый, с помощью autofs и новый, с использованием возможностей всепоглощающей systemd, а именно ее опции x-systemd.automount. С древней autofs встречался, думаю, почти каждый, кто поработал с линухом какое-то время. Для меня была интересна только systemd, т.к. теперь она используется практически во всех более-менее новых дистрибутивах. Логично предположить, что интеграция этой команды с системой более гармонична и потом делать практически ничего не надо.

Важно

Объединяют оба способа использование сертификатов ssh, как их сделать c помощью ssh-keygen уже рассматривалось автором сайта в этой статье. Это самая важная часть во всей истории, потому как во первых, весь смысл удобства автомонтирования и состоит в том, чтобы монтировать без запроса пароля. Во вторых, сообщения об ошибке, связанные с отсутствием сертификатов очень туманны. Например "удаленная точка монтирования не найдена(?)". Итак, в итоге нехитрых манипуляций, мы получаем приватный и публичный ключ, который копируем на сервер. Если уже существует приватный ключ у какого-либо пользователя, его можно передать в fstab специальной опцией (пример ниже)


identityFile=/home/jtad/.ssh/id_rsa


Однако этого недостаточно, нам нужен еще файл known_hosts, который содержит fingerprint удаленного сервера. Есть опции ssh, позволяющие обойти идентификацию сервера, что сделает нас беззащитными в случае MitM атаки. Чтобы получить fingerprint, надо хоть раз зайти на сервер тем пользователем, от имени которого производится монтирование, а именно - root. Если этого не сделать, монтирование из файлового менеджера производиться не будет. А в терминале, при первом монтировании, после команды "sudo mount -a" будет запрошен пароль и файл будет сгенерирован. Но можно подсунуть уже готовый known_hosts того пользователя, с которым вы уже заходили на сервер по ssh. Просто копируем его, а заодно и приватный ключ из домашней директории, примерно так:


$ sudo cp ~/.ssh/id_rsa ~/.ssh/known_hosts /root/.ssh/


Почувствуйте себя мини-хакером :)

Установка

устанавливаем sshfs, а на убунте еще fuse


# apt-get install sshfs fuse


на редхатовских понадобиться только sshfs


# dnf install sshfs


Для добавления точки монтирования поимеем файл fstab. Опции монтирования очень хорошо описаны в арчвики, неудобно просто тупо копипастить. Просто скажу, что нижние 3 опции монтирования и выполняют само монтирование on demand, allow_other разрешает обычным пользователям чтение/запись:


пользователь_на_сервере@IP_сервера:/расшариваемая/директория /локальная/директория noauto,x-systemd.automount,_netdev,allow_other 0 0


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


server1@192.168.3.3:/mnt/down /mnt/down fuse.sshfs noauto,x-systemd.automount,_netdev,user,idmap=user,IdentityFile=/home/jtad/.ssh/id_rsa,allow_other,default_permissions,uid=1000,gid=1000,Cipher=arcfour,compression=no,cache=yes,kernel_cache 0 0


Размонтирвать


$ sudo fusermount -u LOCAL_MOUNT_POINT


Минусы

во многих случаях очень тяжело найти причину неудачного монтирования. Помогает journalctl -f, чтобы посмотреть в режиме реального времени, какие есть проблемы и то не всегда. Так же, при уже смонтированной директории, мне не удалось просто смонтировать другую после добавления в fstab и командой mount -a, всегда нужен ребут. При работе с autofs можно было просто сделать рестарт remote-fs.target. Есть и другие проблемы, к счастью решение многих описаны на той же арчевики. Ради справедливости скажу, что я столкнулся только с моими ошибками в fstab, больше никаких проблем, ни на федоре, ни на убунте

SSHFS и Windows

Да, да и я туда же. Просто было интересно посмотреть, что же предлагает винда для работы c sshfs. Если у вас windows, а сервер на линуксе, надо обеспечить себе удобный доступ к файлам. Поднимать samba ради этого - на любителя. Для nfs я в свое время откопал у google неплохой клиент, однако опять же возня с ним. Для sshfs ничего достойного не нашел, кроме win-sshfs, которая больше не разрабатывается, последний релиз 2012 года. Интересно, что она использует для работы библиотеки докан - аля fuse для линукса - вот он как раз разрабатывается довольно активно. Итак, скачиваем win-sshfs и dokan . Сначала установим dokan, версия 1.0 на момент статьи. Если запустить инсталятор win-sshfs на 8 или 10, он скажет, что поддерживается только Windows 7 и 2008. Но мы легких путей не ищем, запустим в режиме совместимости с 7 (виндузятники в курсе). Инсталятор скажет, что нехватает dokan 0.6.0, игнорируем, так как скачать эту версию он все равно не сможет. После установки запускаем Sshfs Manager

Заполняем название создаваемого диска, ip cервера, после чего я просто подсунул ему мой сертификат, никаких жалоб, что нехватает known_hosts(!), хотя пароля у меня никто не спросил. Нажимаем save, надо обязательно сохранить, иначе попытка монтирования кончится ошибкой "hostname not valid". Через несколько секунд я имел полноценный доступ к директории на сервере.

Вот собственно и все, работа с sshfs не перестает радовать удобством, скорость передачи данных как ожидалось ниже чем у той же nfs, однако и безопасность не сравнить. Как говорится, за все надо платить