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

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

Key Master

В настоящее время существует два способа использовать автоматическое монтирование: старый, с помощью 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
winssh winssh2
Заполняем название создаваемого диска, ip cервера, после чего я просто подсунул ему мой сертификат, никаких жалоб, что нехватает known_hosts(!), хотя пароля у меня никто не спросил. Нажимаем save, надо обязательно сохранить, иначе попытка монтирования кончится ошибкой "hostname not valid". Через несколько секунд я имел полноценный доступ к директории на сервере.
mounted drive

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

5
Ваша оценка: Нет Средняя оценка: 5 (7 votes)

ойвей. Ребята, не делайте так.

Итак, в итоге нехитрых манипуляций, мы получаем приватный и публичный ключ, который копируем на сервер.

НЕЛЬЗЯ. Нельзя копировать приватный ключ для целей иных, чем бекап. На сервере надо сгенерировать его собственный, серверный ключ. В противном случае компрометация одной из машин автоматически компрометирует другую.

Во вторых, сообщения об ошибке, связанные с отсутствием сертификатов очень туманны.

Зато в логах пишут чисто конкретно. /var/log — твой друг. Избавляет от туманности.

тем пользователем, от имени которого производится монтирование, а именно — root

Еще один желающий сидеть под рутом. Как так вышло, что на сервер зайти под рутом можно? По ssh?

Просто копируем его, а заодно и приватный ключ из домашней директории, примерно так: $ sudo cp ~/.ssh/id_rsa ~/.ssh/known_hosts /root/.ssh/ Почувствуйте себя мини-хакером :)

Угу. И ключ скопировали. Причем приватный, но не публичный. Скоро мини-хакер может быть зайдет и на твой сервер, но это будешь не ты.

с целью ускорения передачи информации ...

фанфары...

compression=no

Угу.

Так же, при уже смонтированной директории, мне не удалось просто смонтировать другую после добавления в fstab

А потому что нехрен добавлять в fstab FUSE-штуки, ОСОБЕННО (!) пользовательские, которые с allow_other.

Ваша оценка: Нет
Отправить комментарий
КАПЧА
Вы человек? Подсказка: зарегистрируйтесь, чтобы этот вопрос больше никогда не возникал. Кстати, анонимные ссылки запрещены.
CAPTCHA на основе изображений
Enter the characters shown in the image.