Linux ssh file manager

Есть ли графический менеджер для файлов при работе по SSH?

Есть ли удобный менеджер для обмена файлами между клиентом и сервером по SSH. Linux -> CenOs

Любой sftp клиент.

Sshfs и любой файловой менеджер по вкусу.

Midnight Commander → F9 → Left/Right → SFTP Link…

Спасибо. А есть что-то, что без бубна встанет на Linux Mint 18.3 Чинамун?

Крусадер не устанавливается из штатного репозитория. Говорит, что куча всего нужного для этого не будет установлена и просит поставить «apt-get -f install».

Хотя, это ничего не дает в итоге.

Найди где у твоего Nemo кнопка Connect to remote server и ходи по sftp.

Лично для меня самая здоровская штука — sshfs

Использую filezilla с ключем, все нормально. Скорее всего (уже не помню) ставил из стандартных репозиториев ubuntu.

Ну хоть filezilla по sftp. Собстенно dolphin из kde.

Поставил таки Krusader но как им подключиться к ssh?

Ох уж эти виндузятники с приросшим к мышке пальцем.

Дельфин через фиш

Согласен, мы вообще недостойны подходить к компьютеру 🙂 Но можно по-русски или ссылкой на мануал?

Проще всего сделать так: mkdir remote sshfs пользователь@хост:/папка и открыть где хочешь https://wiki.archlinux.org/index.php/SSHFS_(Русский) Вас часом не Сергей звать?

Спасибо, через фиш получилось на Крусадере.

Между mkdir remote

sshfs должен был быть перевод строки. Короче, mkdir remote; sshfs пользователь@хост:/папка remote

// да будет проклят мудератор, банящий по IP!

Они и туда его воткнули? Это хорошо. Я недавно искал инфу из нашёл только о поддержке ssh в konqueror.

Источник

Кунг-фу стиля Linux: удобная работа с файлами по SSH

Если у вас имеется больше одного Linux-компьютера, то вы, вероятно, постоянно пользуетесь ssh . Это — отличный инструмент, но мне всегда казалась в нём странной одна деталь. Несмотря на то, что ssh-соединения позволяют передавать файлы с применением scp и sftp , у нас нет возможности перемещать файлы между локальной и удалённой системой, не запуская программу на локальном хосте, или не подключаясь к локальной машине с удалённой.

Последнее — это настоящая проблема, так как к серверам часто подключаются, находясь в это время за файрволом или за NAT-маршрутизатором, то есть, не имея постоянного IP-адреса. В результате сервер, в любом случае, не сможет подключиться к локальной системе, с которой раньше к нему обращались. Если бы в ssh-сессии можно было бы просто взять локальный или удалённый файл и передать его туда, куда нужно, это было бы очень удобно.

Я, на самом деле, не вполне достиг этой цели, но подобрался к её достижению очень близко. В этом материале я расскажу вам о скрипте, который позволяет монтировать удалённые директории на локальном компьютере. На локальной машине надо будет установить sshfs , но на удалённой, на которую вы, возможно, не можете устанавливать программы, ничего менять не придётся. Если же потратить на настройку систем некоторое время, и если на клиентском компьютере имеется работающий ssh-сервер, то можно будет ещё и монтировать локальные директории на удалённых системах. При этом не придётся беспокоиться о блокировке IP-адресов или портов. Фактически, если вы способны подключиться к удалённой машине, это означает, что вам удастся и то, о чём я хочу рассказать.

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

Нет ли тут подвоха?

Возможно, вы решите, что тут кроется какой-то подвох. Ведь речь, фактически, идёт об использовании двух ssh-соединений. Одно применяется для монтирования файловой системы, а другое — для входа на компьютер. И это, на самом деле, так и есть. Но если правильно настроить ssh , то аутентификацию нужно будет выполнять лишь один раз, не тратя слишком много времени на организацию двух подключений.

Кроме того, работу значительно облегчает скрипт, о котором я расскажу. Он скрывает от пользователя детали, поэтому процедура подключения выглядит (почти) как обычно, а после этого всё работает как надо.

Пара слов о sshfs

Утилита sshfs даёт возможность работать с файловой системой в пользовательском пространстве (filesystem in userspace, FUSE). То есть, речь идёт о том, что в пользовательском пространстве имеется слой, находящийся поверх базовой файловой системы. В данном случае такой файловой системой является ssh-сервер, поддерживающий sftp . Это позволяет работать с файлами, находящимися на удалённой системе, воспринимая их так, будто они находятся в реальной файловой системе на локальном компьютере. Если вы ещё не пробовали sshfs — попробуйте. Работает эта утилита очень хорошо.

Предположим, вы вошли на компьютер myserver и выполнили с локальной машины следующую команду:

Это приведёт к тому, что директория удалённого компьютера /home/admin будет доступна в локальной системе по пути

При использовании sshfs можно пользоваться различными опциями. Например, можно сделать так, чтобы после потери соединения осуществлялось бы повторное подключение. Подробности о sshfs ищите в справке.

Так как sshfs использует удалённо смонтированную версию файла, то все изменения, внесённые в файл, сохраняются на удалённой машине. А после того, как sshfs-соединение закрывают, на локальной компьютере ничего не остаётся. Сейчас мы это исправим.

Предварительная подготовка

/remote , а в ней создаю поддиректории для каждого удалённого компьютера. Например — это могут быть директории

Скрипт называется sshmount . Он принимает те же аргументы, что и ssh . Для упрощения работы со скриптом сведения об удалённом хосте стоит хранить в файле

/.ssh/config , что позволит пользоваться простыми и короткими именами хостов. Например, сведения о компьютере lab могут выглядеть так:

На самом деле, острой необходимости в этом нет, но при таком подходе в вашем распоряжении будет приятно выглядящая директория

/remote/lab , а не сложная конструкция вида

/remote/alw@lab.wd5gnr-dyn.net:444 . Во всех этих параметрах нет ничего таинственного. Единственно, хочу обратить ваше внимание на то, что ControlMaster и ControlPath позволяют организовать более быструю работу с соединениями, что, в нашем случае, очень важно.

Кроме того, можно организовать автоматическое подключение к удалённой системе с использованием приватных ssh-ключей. Вот материал об этом.

Скрипт

Наш скрипт можно использовать двумя способами. Так, если его вызывают через ссылку к sshunmount , то он размонтирует файловую систему, связанную с указанным удалённым хостом. Если его вызывают иначе (обычно — как sshmount ), то он выполняет следующие три действия:

Он проверяет, есть ли в директории

/remote поддиректория, имя которой совпадает с именем хоста (например — lab ). Если такой директории нет — он выводит сообщение об ошибке и продолжает работу.

Если такая директория существует — скрипт просматривает список смонтированных файловых систем на тот случай, если нужная файловая система уже смонтирована. Если это так — он продолжает работу.

Если директория не смонтирована — он вызывает sshfs и продолжает работу.

Этот скрипт можно найти на GitHub. А вот его код, из которого убраны некоторые комментарии:

Этот скрипт даёт мне половину того, что мне нужно. А именно, позволяет удобно работать с удалёнными файлами на локальном компьютере, к которому я подключён. Но сделать так, чтобы с удалённого компьютера можно было бы работать с файлами, расположенными на локальной машине, немного сложнее.

Решаем обратную задачу

Если вы хотите поэкспериментировать с монтированием на сервере папок, находящихся на локальной машине, то нужно будет, чтобы на локальной машине работал бы ssh-сервер. Конечно, если ваш локальный компьютер видим и доступен серверу, то это просто: достаточно запустить на удалённом компьютере sshfs и смонтировать на нём папку с локального компьютера. Но во многих случаях у нас нет доступа к локальной системе, которая может быть расположена за файрволами или маршрутизаторами. Особенно это актуально в том случае, если роль локальной системы выполняет ноутбук, который может подключаться к сети из разных мест.

Но нашу задачу, несмотря на все эти сложности, всё же, можно решить. Её решение состоит из двух частей.

Во-первых — надо, при вызове sshmount , указать дополнительный аргумент (файл можно отредактировать в том случае, если вам нужно будет постоянно выполнять подобную команду):

Во-вторых — после подключения к хосту нужно выполнить такую команду:

Благодаря опции -R на удалённой машине создаётся сокет на порте 5555 (который, естественно, должен быть свободным) и осуществляется его связь с портом 22 локальной машины. Если исходить из предположения о том, что ssh-сервер работает на порте 22 , то это позволит серверу подключиться к локальной машине по тому же соединению. Ему не нужно знать наш IP-адрес или иметь открытый порт.

Команда sshfs , которую можно выполнять при запуске системы, связывает локальную директорию /home/me с директорией

/local удалённого сервера. Если, вдобавок, войти в систему локально, то можно будет взглянуть на переменные окружения, имена которых начинаются с SSH_ , и узнать подробности о SSH-соединении. Например, это переменные $SSH_CLIENT и $SSH_TTY .

Конечно, вам, чтобы вышеприведённые команды заработали бы у вас, нужно будет поменять имена хостов и директорий, а так же — адреса портов на те, которые используются в ваших системах. Но после того, как всё будет настроено, все нужные вам файлы будут доступны и на локальной, и на удалённой машинах. Я, кстати, не пытался организовать циклическое монтирование директорий. Если попытаться это сделать — может получиться нечто очень странное.

Итоги

Полагаю, нужно с осторожностью выполнять одновременное монтирование удалённых папок на локальной машине и локальных папок на удалённой машине. Например, утилиты, занимающиеся сканированием всей файловой системы, могут в таких конфигурациях запутаться. Кроме того, я всё ещё ищу ответ на вопрос о том, как правильно отключаться от серверной файловой системы при выходе из последней сессии.

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

Чем вы пользуетесь для работы с файлами удалённых Linux-систем?

Источник

Инструменты для монтирования файловой системы по SSH

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

В веб-разработке это требуется довольно часто. Иногда требуется просто скачивать/закачивать файлы на удаленный сервер, а иногда еще и выполнять какие-то команды.

Немного теории об SSH, FTP и SFTP

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

Это расширение называется SFTP (не путать с FTPS, это разные вещи) и работает оно поверх SSH соединения. При этом на сервере не требуется устанавливать и настраивать дополнительное ПО для организации передачи файлов, как это было в случае с FTP. Настройки по умолчанию при установке SSH сервера (пакет openssh-server ) вполне рабочие. В качестве пользователей используются пользователи ОС.

Впрочем, если требуются сложные схемы доступа, то без настроек, конечно, не обойтись, но в рамках этой статьи установку и настройку SSH мы рассматривать не будем, а сосредоточимся на клиентском ПО для SFTP соединений.

Пожалуй, нужно еще ответить на вопрос, а зачем вообще использовать SFTP, ведь есть FTP, и зачем придумывать что-то еще?

FTP до сих пор довольно распространен, однако этот протокол менее быстр, менее функционален, менее защищен и менее надежен, он не имеет никаких преимуществ перед SFTP.

SFTP же, в свою очередь, детально проработан для работы с файлами, не имеет проблем с кодировками, файлы не теряются, не бьются, установленное соединение просто так не разрывается, и может оставаться активным неделями. Одним словом, в SFTP решены многие проблемы, которые есть у FTP.

Клиентское ПО для работы с SFTP

Большинство актуальных программ для работы с FTP поддерживают и SFTP. Например, FileZilla (Windows, macOS, Linux), Cyberduck (Windows, macOS), Xftp (Windows), Transmit (macOS).

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

Для разработки более интересно ПО, которое позволяет монтировать SFTP соединения как сетевой диск или как файловую систему. Для разных ОС есть различные варианты реализации такого подхода, как с помощью стандартных средств протокола SSH, так и с применением собственных алгоритмов.

Здесь, пожалуй, лучше начать с ПО для Linux. В Ubuntu (и скорее всего и в других дистрибутивах) можно примонтировать сетевой диск по SSH в стандартном файловом менеджере без установки какого-либо дополнительного ПО (естественно, пакет openssh-client должен быть установлен). Для этого нужно зайти в раздел «Other Locations» (актуально для версии 18.04, в старых версиях, по-моему, было как-то по-другому) и воспользоваться строкой «Connect to Server». Кстати, поддерживаются и другие протоколы.

Строка подключения выглядит следующим образом:

Также в Linux доступен пакет SSHFS, который работает в связке с пакетом Fuse, и позволяет монтировать SFTP соединения с помощью командной строки, в том числе автоматически при загрузке ОС.

Команда подключения будет примерно такой:

Поддерживаются различные дополнительные опции, например аутентификация по файлу-ключу.

Для macOS также существует SSHFS, и своя реализация Fuse (FUSE for macOS), работают они так же, как и в Linux.

Однако для этой платформы существует и масса GUI программ (программ с графическим интерфейсом) для удобного управления монтированием:

• Forklift
• Mountain Duck
• CloudMounter
• ExpanDrive

Я поработал со всеми этими программами и некоторыми другими. Очень удобно, что можно сохранять настройки соединений, и в пару кликов монтировать файловые системы. Но у всех них есть важная особенность, которая в моем случае являлась существенным недостатком. Так или иначе, все эти программы безапелляционно кешировали переданные файлы. Функция, конечно, полезная, но для разработки нужна возможность и каждый раз получать «свежие» файлы, не из кеша, так как они могут часто меняться на сервере в процессе работы, например при сборке CSS из SASS. В некоторых случаях наблюдались и случаи порчи файлов, хотя, возможно, в актуальных версиях это уже могли исправить.

На Windows ситуация примерно такая же, есть несколько программ с собственными алгоритмами монтирования, например WebDrive и тот же Mountain Duck. У WebDrive даже есть функция настройки параметров кеширования, но, к сожалению, полностью оно все равно не отключается.

Существует и вполне рабочая версия порта SSHFS для этой платформы — WinSshFS. Именно на ней я остановился, когда работал на Windows.

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

GUI для SSHFS

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

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

Это был новый интересный опыт для меня, так как десктопных приложений до этого я не разрабатывал. При поиске подходящего стека технологий я руководствовался желанием сделать программу для macOS и Linux (так как интерфейс командной строки SSHFS есть только для этих платформ), но впоследствии от поддержки Linux пришлось отказаться.

В итоге, выбор пал на платформу Electron, которая позволяла создавать приложения с некоторыми нативными функциями с помощью HTML/CSS/JS. C JavaScript мне часто приходилось иметь дело, и процесс разработки занял всего порядка двух дней. Еще примерно столько же понадобилось, чтобы разобраться с самим Electron и его возможностями.

Приложение SSHFS Mounter доступно на GitHub.

Работу с программой здесь я описывать не буду, все должно быть интуитивно понятно.

Кстати, одной из причин отказа от поддержки Linux, было отсутствие в Electron встроенной возможности использовать нативные элементы интерфейса ОС. В последних версиях macOS интерфейс остается более-менее одинаковым, и я постарался воспроизвести его подобие с помощью CSS, но для различных оконных интерфейсов Linux, да еще и различных тем оформления, этого было бы непросто добиться.

Также к архитектурным минусам Electron можно отнести:

• большой размер приложения — порядка 50 Мб в сжатом виде, из которых код самого приложения занимает всего порядка 20 Кб в несжатом виде.
• ограниченная поддержка работы с командной строкой, из-за чего невозможно обрабатывать какие-либо интерактивные запросы, например ввод пароля, парольной фразы или запроса на добавление сервера в доверенный список.

Несмотря на это, я пользовался SSHFS Mounter практически ежедневно в течение нескольких месяцев.

Однако то, что практически при каждом монтировании мне было необходимо запускать еще и обычную SSH сессию (для выполнения команд на сервере), а также периодическая потребность в похожем инструменте для Linux, сподвигли меня на разработку нового инструмента управления соединениями — для командной строки (CLI).

Менеджер SSHFS соединений для CLI

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

Что ж, за работу!

Поддержка Linux на этот раз была одним из главных требований, наряду с macOS.

При проектировании приложения хотелось сделать его максимально простым в работе. В качестве формата файлов для хранения параметров соедиений был выбран YAML, как один из самых дружественных для редактирования человеком. Основная концепция программы — для выполнения основных команд от пользователя требуется набирать минимальное количество символов, как это сделано, например, в Git или Drush.

Разработка заняла порядка двух недель в относительно свободном режиме. При этом рабочий вариант был готов уже на второй день.

Приложение SSHFS Mount Tool (SMT) также доступно на GitHub.

До этого у меня уже был опыт разработки консольных приложений на PHP и node.js, но это были скрипты для личного или служебного пользования: конвертор проприетарного векторного формата в SVG, программа для сортировки и конвертации музыкального архива, различного рода инструменты для пакетной обработки изображений для интернет-магазинов. Но эти программы не были рассчитаны на других пользователей, не было практически никакой обработки ошибок, различных вариантов передачи параметров или справки.

В SMT же мне пришлось проектировать вполне себе полноценную архитектуру приложения, такой опыт был впервые, и насколько он успешен судить уже не мне.

Для SMT я предусмотрел несколько сценариев использования, основываясь на собственном рабочем процессе.

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

Если добавлено несколько соединений (а для этого программа и предназначена), то можно передать команде ID соединения в качестве аргумента, либо выполнить команду без аргумента, и программа предложит выбрать соединение из списка.

Пример команды монтирования:

Соединения можно добавлять при помощи встроенного мастера (команда smt add ), либо редактируя файл конфигурации напрямую. Можно использовать глобальный файл конфигурации в папке пользователя, либо файл smt.yml в текущей папке.

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

Использования отдельных файлов конфигурации удобно, например, для хранения настроек соединения в папке проекта. Если запускать программу из этой папки, то будет использован находящийся в ней файл конфигурации.

Если создано только одно соединение, то оно автоматически будет использовано в качестве аргумента для команд.

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

В качестве дополнения, для стандартных терминалов Ubuntu и macOS есть возможность открывать папку монтирования и запускать SSH соединение в новой вкладке терминала.

Работая над программой, было прочитано множество материалов по способам работы с аргументами, вывода результатов, организации справки (команды help ). Были попытки использования сторонних библиотек, но в итоге их использование я счел оправданным только для работы с YAML форматом и отображения вывода в табличном виде. Обработка аргументов и генерация справки написаны с нуля. Возможно, использованные методы не самые оптимальные, и тут я был бы рад услышать конструктивную критику и предложения по улучшению.

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

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

Обновление

По совету и не без помощи @yozk (Ivan Ch), я полностью переписал SMT на базе компонента Symfony/Console.

Это второй по популярности компонент Symfony и самый популярный инструмент для разработки PHP CLI програм. К слову, Composer, Drush 9 и Drupal Console так же базируется на нем.

Console предоставляет множество полезных возможностей, среди которых:

• объявление и обслуживание аргументов и опций;
• управление выводом, в том числе форматами и цветами;
• автоматическую генерацию справки.

Все эти, и некоторые другие, возможности используются в SMT версии 2.x, и вот что это дало, по сравнению с первой версией:

• дополнительные способы передачи аргументов и опций;
• единый стиль запросов на ввод данных (как в Composer);
• валидация ввода и при необходимости повторный запрос на ввод;
• более широкое использование цветов для разметки вывода;
• различные форматы вывода результатов;
• улучшенная справка и уровни подробности вывода;
• общее повышение стабильности приложения за счет обработки ошибок и применения оттестированных компонентов и функций Symfony.

В отличии от версии 1.x, где я был волен выбирать варианты реализации по своему усмотрению, в Console повсеместно применяется ООП. Это, конечно, немного усложнило процесс для меня, пришлось разобраться с документацией и примерами реализации в других приложениях, но в итоге я остался очень доволен результатами, и еще раз хочу поблагодарить Ivan Ch за помощь и советы.

Синтаксис команд, формат конфигурационного файла и варианты использования полностью сохранились. Хотя Symfony/Console более строг к порядку аргументов, в этом отношении первая версия была более добра к пользователю.

Также размер приложения увеличился примерно в 3 раза (1.5 Мб), и хоть на скорости работы это, на мой взгляд, не сказалось, первая версия может послужить более легковесной альтернативой.

Вместо итога

Если в работе вам часто приходится выполнять одни и те же рутинные операции, то разработка удобного инструмента для автоматизации их выполнения — это отличный способ на реальном примере погрузиться в разработку, изучить что-то новое и получить обратную связь от коллег по цеху. Именно этих принципов я придерживался при разработке своих программ, надеюсь они окажутся полезны и вам!

Источник