Комментарии 36
sshfs через более-менее неустойчивое соединение(обычное для домовых провайдеров) это верный способ отстрелить себе ногу.

Даже ftpfs работает стабильнее.

А вообще для решения данной задачи есть же filezilla-project.org

А разве Файлзилла умеет монтировать? Мне казалось, это только GUI-клиент для FTP/SCP — разве не так?

Если необходимо что-то быстро поправить на удаленном сервере, то я пользуюсь krusader — новое сетевое подключение. И в нем настроено, что по F4 редактировать файлы в kate. При сохранении файла он сохраняется на сервере.

Под windows для этой же цели можно использовать winscp и любой редактор по вкусу. Подойдет даже VS Code.

Visual code — наверное лучший редактор на платформах win и linux. И в нем есть отличный плагин sshfs, с помощью которого можно настроить кучу коннектов и удобно работать с различными рабочими пространствами. Если хочется все и в одном окне, то в нем же есть терминал

Надо будет посмотреть, а то встроенный Remote-SSH запускает на удалённом сервере nodejs со всеми плагинами.

В emacs это тоже есть прямо из коробки. Достаточно открыть "файл" вида /ssh:user@server:path/to/file. В случае разрыва связи ничего не поломается, при попытке сохранить емакс сам восстановит соединение.

У данного плагина есть ряд особенностей. Да и вообще удалённой работы с файлами из VS. По работе много приходилось кодить на удалённых серверах. И вот без плагина на стороне сервера, это всё очень плохо работает. Особенно поиски по файлам. Открытие больших файлов (тот же vim переваривает под несколько гигов файл). Так что своеобразные впечатления.
ну, кодить прямо на удаленном сервере — плохая идея почти всегда. Но тоже приходилось править код и тут он справляется прекрасно. Большие файлы в визуал коде в целом не очень хорошо работают, но каких-то сложностей с плагином не заметил ( а может и не открывал). Если файл большой, то как правило используются другие средства для его обработки
Как альтернатива — набор инструментов:
Редактирование текстовых файлов (встроенный внешний редактор), копирование файлов: winscp
Для консоли: PuTTY
Запуск X-приложений (X-сервер): xming
Бесплатная версия Xming древняя и багованная, а за обновленную разработчик просит требует донат в размере 10 GBP (1к рублей), еще и сроком действия в один год.
Советую VcXsrv sourceforge.net/projects/vcxsrv

Авторизация по ключам же, и не нужно вот этого всего хранения паролей в открытом виде в куче скриптов. См. ssh-copy-id и ~/.ssh/authorized_keys. Еще и серверы от брутфорса пароля будут защищены.


Один раз создал ssh-ключ, раскидал публичный ключ на все нужные серверы и никаких проблем с авторизацией. Если ssh-ключ с паролем, то его достаточно разблокировать единожды, многие DE имеют keyring и ключик надо разблокировать только при первом использовании.

Плохой, негодный совет. Нет, я понимаю, бывают железки на которых либо нет авторизации по ключу, либо их поставить туда просто нельзя, по разным причинам. Но такой совет будет светить паролем в списке процессов и в
.*history
. Лучше уж либо через переменную скармливать, а ещё лучше использовать
sshpass
Файловые менеджеры в современных Линукс дистирбутивах поддерживают SFTP из коробки. Т.е. можно открывать удалённые директории по адресу sftp://user@host/path/to/directory.
Я у себя избавился от записей в fstab. Всё перенёс в экосистему sysytemd (*.mount; *.automount) что немного ускорило загрузку системы (systemd не занимается автогенерацией рантайм *.mount файлов из содержимого fstab) ну и бонусом всякие /boot и /boot/efi на автомонтировании, ибо они нужны смонтированными только в момент загрузки системы или в момент обновления ядер или grub. Ну и облака тоже на автомаунте. Достаточно обратиться к каталогу куда смонтирован какой-нить яндекс и вумная железка сделает всё остальное. А через пять минут после последнего обращения к каталогу произойдёт отмонтирование.
хмм, ускорение загрузки системы заметное? Просто сам man systemd.mount пишет:
In general, configuring mount points through /etc/fstab is the preferred approach.


поэтому я по-старинке делаю. И ещё у меня авто-отмонтирование не заработало — может быть, из-за этого?

У меня обычное монтирование, через /etc/fstab — при недоступности домашней файлопомойки загрузка по ощущениям длится на минуту-другую дольше — задержка возникает как раз при попытке монтирования недоступного.

Почитайте вот этот мой ответ. Ну и вам пример. У меня облако, у вас там наверное будет маунт с SMB или NFS.
/etc/systemd/system/yadisk.mount
[Unit]
Description=Yandex disk automounted drive
Documentation=man:systemd.mount(8)

[Mount]
Where=/home/oxyd/Clouds/yadisk
What=https://webdav.yandex.ru/
Type=davfs
Options=noauto,user

/etc/systemd/system/yadisk.automount
[Unit]
Description=Automount yandex disc when needed.

[Automount]
Where=/home/oxyd/Clouds/yadisk
## Time to automatic umount of inactivity
TimeoutIdleSec=300

[Install]
WantedBy=multi-user.target
Видимо вы что-то не так делали. Любые разделы, кроме корневого(а так-же /usr если он вынесен в отдельный раздел) прекрасно выносятся, без лишних телодвижений, в соответствующие *.mount файлы, которые надо положить в /etc/systemd/system. Для корневого и /usr(если есть) нужно не только создать *.mount но и добавить параметры ядра из man systemd-fstab-generator, что-бы система на раннем уровне загрузки смогла смонтировать /usr и /. Там-же параметр который полностью отключает автогенерацию *.mount и *.swap юнитов из fstab, что экономит ещё немного времени. Для свопа — файл(ов) или раздел(ов), нужно создать *.swap юнит(ы) по тому-же пути что и маунты. На самом деле руками созавать файлы не нужно. Автосгенерённые юниты живут по пути /run/systemd/generator их просто нужно скопировать в каталог который я указал и поправить по вкусу. Для автомаунта разделов делаем такой финт: В тот-же каталог кладём одноимённый с маунтом *.automount и вообщем-то всё. Вот пример моего автомаунта раздела с /boot:
/etc/systemd/system/boot.mount:
[Unit]
Description=Boot partition (running by automount) /dev/sda1
Documentation=man:systemd.mount(5)
After=blockdev@dev-disk-by\x2duuid-ea65285a\x2d01da\x2d451c\x2da93a\x2d4b155c46aeeb.target

[Mount]
Where=/boot
What=/dev/disk/by-uuid/ea65285a-01da-451c-a93a-4b155c46aeeb
Type=ext4
Options=rw,relatime
DirectoryMode=0755

И парный, к нему автомаунт.
/etc/systemd/system/boot.automount:
[Unit]
Description=Automount boot partition when needed.

[Automount]
Where=/boot
## Time to automatic umount of inactivity
TimeoutIdleSec=120

[Install]
WantedBy=multi-user.target
А кто-нибудь может рассказать как правильно делать в такой ситуации:
На сервер нужно скопировать файл, например в каталог /data
К серверу подключаемся под пользовательской учеткой с правами sudo, но у пользователя нет прав на запись в этот каталог.
Можно ли сразу через scp скопировать файл в конечный каталог без использования последующих команд вида
sudo mv ~/file /data/
или изменений разрешений в каталоге?
нужно сперва подключиться пользователем и выполнить sudo chmod /data
а уже потом копировать файл

Можно, если использовать rsync и ему передать параметр --rsync-path "sudo rsync". Тогда на удаленной стороне будет запущено от рута

Спасибо, прочитал про rsync и вспомнил, что год назад уже гуглил этот вопрос и находил это решение, но все забыл.

Использовал sshfs для быстрого обновления исполняемых файлов на железе по make install

А ещё можно принимать и передавать файлы без дополнительных подключений, но для этого нужно, чтобы на клиенте работал Xorg (обычно так и есть). Сначала подключаемся к серверу с помощью ssh login@address -Y, можно проверить, что проброс подключения к Xorg работает через echo $DISPLAY, должно выдать что-то типа localhost:10.0. Если не выдало, проверьте /etc/ssh/sshd_config на сервере на предмет опций X11Forwarding yes и X11DisplayOffset 10.


Далее, ставим на этот сервер, к которому подключились, и себе на клиентскую машину пакет xclip. Всё, теперь можно выполнять xclip-copyfile /path/to/file1 /path/to/file2 ..., после чего в локальном уже терминале делать xclip-pastefile, файлы передадутся. Это работает, разумеется, в обе стороны. Никаких монтирований и прочего, всё по одному и тому же подключению. Использую этот способ уже очень давно, всё устраивает.

Это все конечно хорошо, но как по мне ничего лучше mRemoteNg (к сожалению только на windows), в качестве обертки над cli утилитами доступа по различных протоколам не придумали. Очень хочу, чтобы его портировали под линукс...

В mc (midnight commander) открываешь правую или левую панель — и там выбираешь Shell-соединение. В качестве адреса — то же, что пишешь при коннекте по ssh (у меня обычно в ~/.ssh/config прописаны алиасы, чтоб одним словом переходить на любой рабочий сервер, если нужно с промежуточными джампами и авторизациями). Всё! Можно копировать туда/сюда; можно просматривать и редактировать файлы. И да, именно Shell (а не sftp). Работа последнего подразумевает, что на удалённом хосте есть служба sftp, а shell этого не нужно, достаточно просто возможности залогиниться.

локальный vim использую для открытия удаленных файлов
vim scp://root@remote.host.com//etc/ssh/sshd_config


им же, вимом можно и навигировать по удаленной файловой системе

Плюс sshfs в том, что он поднимается достаточно просто и имеет минимальнып настройки.
На этом плюсы заканчиваются.


Для обновления пары-тройки файлов или локального монтирования содержимого докера — вполне удобно.


Проблемы начинаются, когда нужно прочитать/обновить каталоги от 5к файлов или со сложной древовидной структурой или залить от сотни мелких файлов.
Или частые конкурентные чтения файлов из монтированного каталога.
Здесь fuse существенно проигрывает по скорости тому же nfs и даже самбе.

"или за NAT-маршрутизатором, то есть, не имея постоянного IP-адреса.". — тема не раскрыта. Обычно сервер на работе может иметь доступ к интернету и нет белого или даже динамического ip. Также домашний компьютер максимум может иметь динамический ip, а скорее как и рабочий сервер имеет только доступ в инет. В таком сценарии только тимвьювер или гуглремоутдесктоп

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