Windows подключить сетевой диск по ssh

Для подключения файловой системы удаленного сервера в качестве сетевого диска в Windows можно использовать защищенный протокол SSH (вместо стандартного SMB/samba). Это удобно, когда нужно сделать файлы на удаленном SSH сервере доступными для локальной работы без использования дополнительных FTP/SFTP подключений. Для монтирования удаленных файловых систем в Windows можно использовать клиент SSHFS-Win. Этот клиент позволяет прозрачно подключать каталоги с удаленных компьютеров по протоколу SSHFS (основан на протоколе передачи SFTP, SSH File Transfer Protocol).

Можно скачать MSI установщик SSHFS-Win вручную или установить его через встроенный пакетный менеджер WinGet:

winget install SSHFS-Win.SSHFS-Win

Картинка с сайта: winitpro.ru

Теперь можно смонтировать удаленную папку в виде сетевого диска прямо из проводника File Windows. Щелкните правой мышкой по значку Этот компьютер и выберите Подключить сетевой диск. Здесь нужно выбрать букву диска, которую нужно назначить и указать UNC путь к удаленной директории в формате:

\\prefix\\user@host[!PORT][\\PATH]

User
– учетная запись для аутентификации на удаленном SSH хосте

Host
– имя/IP адрес хоста

В качестве префикса нужно указать один из следующих значений:

• sshfs
  – подключиться в домашний каталог пользователя (в случае Windows это каталог профиля пользователя). Дополнительно указать относительный путь к людому каталогу в профиле пользователя.
• sshfs.r
  – подключиться к корневой папке системы (в случае Windows это будет корень системного диска)
• sshfs.k
  – подключиться в домашний каталог пользователя. Для аутентификации использовать SSH ключ в %USERPROFILE%/.ssh/id_rsa
• sshfs.kr
  – подключиться к корневой директории с SSH ключом

Например, для монтирования каталога
C:\PS
с удаленного Windows хоста (на котором настроен SSH сервер), введите такой UNC путь:

\\sshfs.r\[email protected]\ps

При подключении появится запрос пароля удаленного пользователя для аутентификации (пароль можно сохранить в диспетчере учетных записей Windows).

Картинка с сайта: winitpro.ru

После этого в проводнике Windows появится отдельной сетевой диск, подключенный по SSHFS.

Картинка с сайта: winitpro.ru

Также можно подключить сетевой диск из командной строки с помощью стандартной команды
net use
.

Следующая команда смонтирует каталог
/var/www
на Linux сервере в качестве сетевого диска Windows:

net use W: \\sshfs.r\[email protected]\var\www /user:sysops

При подключении нужно будет ввести пароль пользователя.

Картинка с сайта: winitpro.ru

Подключенный таким образом сетевой диск будет существовать только до следующей перезагрузки компьютера. Чтобы автоматически переподключать диск при входе пользователя, в команду нужно добавить опцию
/persistent:yes

Одновременно через провайдера WinFsp.Np может быть подключено несколько сетевых папок. Вывести список подключенных дисков:

net use

Картинка с сайта: winitpro.ru

Удалить один из дисков:

net use M: /delete

В команде net use можно указывать пароль и в открытом виде, но безопаснее будет настроить монтирование удаленной папки с помощью аутентификации по SSH ключу.

Сгенерируйте SSH ключи в Windows с помощью утилиты
ssh-keygen
согласно мануалу по ссылке (не указывайте пароль для защиты закрытого ключа). Добавьте открытый ключ из файла .pub в файл
authorized_keys
(или
administrators_authorized_keys
) на удаленном SSH сервере.

Для автоматического подключения сетевого диска по SSH с аутентификацией по ключу при входе в Windows, можно создать задание планировщика которое будет запускать такой PowerShell скрипт:

$rUser = "administator"
$rHost = "m-fs01.winitpro.ru"
$remoteDir = "\Install"
$Drive = "M:"
$privSSHKey = "C:\secret\m-fs01-id_rsa"
cd  'C:\Program Files\SSHFS-Win\bin\'
$mountcmd = ".\sshfs-win.exe svc \sshfs.k\$rUser@$rHost$remoteDir $Drive -IdentityFile=$privSSHKey"
Invoke-Expression $mountcmd

Можно использовать графический клиент для создания подключений сетевых дисков по SSH. Самым простым и удобным является SSHFS-Win-Manager. Клиент
SSHFS-Win-Manager
позволяет создать несколько SSHFS подключений к удаленным файловым системам. Поддерживает аутентификацию, как по паролю так и ключу.

Картинка с сайта: winitpro.ru

Добрый день, друзья! Хочу поделиться небольшой заметкой. Имея удаленный сервер с доступом по SSH, одним из удобных способов работы с его файловой системой, из Windows, может быть — подключение(монтирование) ее отдельным сетевом диском с назначением собственной буквы. Для этого в Windows потребуется установить WinFSP и SSHFS-Win, а также создать .bat файл для автоматического монтирования сетевого диска после перезагрузки. Об этом данная заметка.

Для того, чтобы монтировать в Windows сетевой диск по протоколу SSH, необходимо:

1. Установить WinFSP

2. Установить SSHFS-Win

3. Перейти в Мой компьютер, выбрать пункт Подключить сетевой диск

4. В открывшемся диалоговом окне указать путь подключения:

\\sshfs\USERNAME@HOST[\PATH]

USERNAME — Имя SSH пользователя (например root)
HOST — IP адрес сервера (например 192.0.0.10)
PATH — Путь к подключаемой директории, относительный домашней папки пользователя(по умолчанию /root)

5. Делаем подключение сетевого диска автоматическим. Для этого создадим .bat файл, с содержимым по маске:

net use X: \\sshfs\[USERNAME]@[HOST]\[PATH] /user:[USERNAME] [PASSWORD] /persistent:yes

PASSWORD — Пароль для авторизации
persistent:yes — Позволяет сохранить настройки подключения к сетевому ресурсу на постоянной основе

Пример команды с подставленными в нее данными авторизации:

net use X: \\sshfs\root@192.168.0.10\..\home /user:root 123456 /persistent:yes

6. Для автозагрузки помещаем данный файл в каталог автозагрузок Windows. Жмем Win + R, вводим: shell:startup, в открывшуюся папку копируем батник.

Время на прочтение6 мин

Количество просмотров18K

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

Однажды потребовалось мне организовать доступ к серверу по протоколу SMB и в поиске решения я наткнулся на следующую статью: Mounting your Nikhef home directory using SSH for Windows 8. Это было простое и удобное решение, которое использовало Putty. Чуть позже мне пришлось настраивать это решение на другом компьютере и я понял, что Putty тут лишний с тех пор как в Windows 10 появился встроенный ssh-клиент на основе OpenSSH.

Под катом — идентичная схема, только с использованием OpenSSH под Windows 10.

У меня схема организована следующим образом:

1. На сервере запущена Samba, от имени пользователя www-data расшарена корневая папка с сайтами. Доступ к серверу только через ssh с авторизацией по ключу. Сервер за NATом, порт проброшен только для ssh.
2. В процессе входа в аккаунт на домашней машине на Windows 10 через встроенный в систему OpenSSH устанавливается соединение с сервером с авторизацией по ключу.
3. Туннелируется порт 445 удаленной машины на локальный порт 44445 сетевого loopback-адаптера доступного по адресу 10.255.255.1
4. На loopback-адаптере 10.255.255.1 порт 44445 проксируется на локальный 445. Таким образом при подключении к \\10.255.255.1\ открывается удаленная шара с файлами (которая, при необходимости монтируется как сетевой диск).

Всё это автоматом – лень торжествует. Безопасно, быстро и нативно выглядит. Любым редактором могу открывать и править файлы на удаленном сервере как у себя на локальном — без проблем с загрузкой правленых файлов и установкой им необходимых разрешений. При этом нет проблем с безопасностью Samba.

Итак – сперва по шагам:

На стороне WINDOWS

Должен быть установлены OpenSSH. В Windows 10 и Windows Server 2019 появился встроенный SSH клиент на основе OpenSSH. Им мы и воспользуемся. Сначала убедимся что он установлен – наберем в командной строке

ssh

Картинка с сайта: habr.com

Если видим исполнение команды — все «Ок», клиент присутствует в системе.

Шаг 1. Настройка сетевого адаптера

Устанавливаем loopback-адаптер в системе. Мы будем обращаться по адресу к локальному адаптеру.

hdwwiz.exe

Картинка с сайта: habr.com

Запустится «Мастер установки оборудования» (Здесь я пользуюсь русской Windows 10 Pro).

«Далее» -> «Установка оборудования, выбранного из списка вручную» -> «Сетевые адаптеры» -> «Microsoft –> Адаптер замыкания на себя Microsoft KM-Test» -> «Далее»

Уверен, что эти шаги можно сделать из командной строки, но не нашел способ установки драйвера без devcon.exe, потому и не стал заморачиваться с автоматизацией этого шага.

Далее уже в CMD (от имени Администратора).

netsh interface show interface

Картинка с сайта: habr.com

Видим появился второй адаптер. У меня он называется Ethernet 2.

Теперь настроим адрес для этого адаптера

Картинка с сайта: habr.com

Или из командной строки:

netsh interface ip set address name="Ethernet 2" source=static address=10.255.255.1 mask=255.255.255.0

В результате у нас появился адаптер локально доступный по адресу 10.255.255.1

Теперь проблема в том, что нам необходимо получить доступ к общей папке через TCP-порт 445, но при загрузке Windows этот порт захватывается системным драйвером lanmanserver для всех интерфейсов. Отложив запуск драйвера lanmanserver и установив правило portproxy, мы можем обойти это.

Далее в командной строке от имени администратора меняем режим запуска сетевых служб (пробел после «start=» обязателен!!!):

sc config lanmanserver start= demand
sc config iphlpsvc start= auto

и настраиваем для адаптера с адресом 10.255.255.1 проксирование порта 44445 на локальный порт 445

netsh interface portproxy add v4tov4 listenaddress=10.255.255.1 listenport=445 connectaddress=10.255.255.1 connectport=44445

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

Проверяем что прослушивание порта осуществляется нашим loopback-адаптером, просмотрев открытые в системе порты

netstat -an | find ":445 "

Если мы видим

TCP    10.255.255.1:445    0.0.0.0:0       LISTENING

значит все в порядке и порт прослушивается на нужном адресе. Если же мы видим «0.0.0.0:445» — значит в нашей схеме что-то не сработало правильно. Проверить правила переадресации портов можно командой

netsh interface portproxy show v4tov4

Шаг 2. Ключ и рабочий скрипт

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

mkdir %APPDATA%\CIFSoverSSH
cd %APPDATA%\CIFSoverSSH

Генерируем ключ для ssh-авторизации (назовем его, например: cifsoversshkey)

ssh-keygen -t rsa -N "" -f cifsoversshkey 

В результате будет сгенерирована пара открытого и закрытого ключа. Для того, чтобы OpenSSH не выдавал сообщение UNPROTECTED PRIVATE KEY FILE! нужно изменить права на файл ключа. Задачу мы будем запускать для одного пользователя, от имени которого мы собираемся работать в Windows. Можно через GUI, но мне показалось что картинок уже достаточно. В Windows это сделаем следующей командой:

icacls cifsoversshkey /RESET
icacls cifsoversshkey /grant Имя_Пользователя:F /inheritance:r

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

icacls cifsoversshkey 

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

Создадим в текущей папке пакетный файл cifsoverssh.cmd следующего содержания:

call cmd /c start "" /B C:\Windows\System32\OpenSSH\ssh.exe user@111.111.111.111 -p remoteport -i %APPDATA%\CIFSoverSSH\cifsoversshkey -L 10.255.255.1:44445:localhost:445 -N -o "StrictHostKeyChecking=no"

Где:
user@111.111.111.111 – пользователь на стороне linux сервера @ адрес удаленного сервера

Шаг 3. Ярлык или задача в планировщике

Создаем ярлык для следующей команды: powershell -nologo -noninteractive -windowStyle hidden -command «%APPDATA%\CIFSoverSSH\cifsoversshkey.cmd»
Это позволит запускать наш пакетный файл через powershell без открытия окна. Если запускать его через CMD будет открываться черное окно терминала и будет висеть все время, пока соединение будет установлено, а это неудобно и некрасиво.

Для автоматизации запуска при входе в систему можно создать задачу в планировщике:

schtasks /CREATE /RU %username% /TN "CIFS over SSH" /TR "powershell.exe -nologo -noninteractive -windowStyle hidden -command %APPDATA%\CIFSoverSSH\cifsoversshkey.cmd" /SC ONLOGON /DELAY 0000:10 /IT /RL highest

На стороне клиентского компьютера Windows все приготовления были закончены.

Настройка Linux сервера

Предполагается, что ssh-сервер был предварительно настроен и включена авторизация по ключу.

Подключаемся по ssh из командной строки на windows-машине

C:\Windows\System32\OpenSSH\ssh.exe user@111.111.111.111 -p remoteport

В домашней папке пользователя, от имени которого мы будем авторизовываться при создании туннеля ищем файл ~/.ssh/authorized_keys (если файл отсутствует – создадим его).

mkdir ~/.ssh && touch ~/.ssh/authorized_keys

Теперь необходимо в этот файл вставить содержимое нашего файла публичного ключа, созданного на нашей windows-машине (файл %APPDATA%\CIFSoverSSH\cifsoversshkey.pub). Откроем его в любом редакторе и вставим цепочку ключа с новой строки. Если есть другие ключи, просто вставим его с новой строки.

Устанавливаем Samba (на примере Debian)

apt update && apt install samba

Переименовываем старый файл настроек и создаем новый файл

mv /etc/samba/smb.conf /etc/samba/smb.conf.old
touch /etc/samba/smb.conf

Открываем пустой файл настроек и приводим его к следующему виду:

[global]
realm = webserver
server string = Web server
workgroup = WORKGROUP
# Setup charsets
dos charset = cp1251
unix charset = utf8
# Disable printers
load printers = No
show add printer wizard = no
printcap name = /dev/null
disable spoolss = yes
# Setup logging
log file = /var/log/smbd.log
max log size = 50
max xmit = 65536
debug level = 1
# Setup daemon settings
domain master = No
preferred master = Yes
socket options = IPTOS_LOWDELAY TCP_NODELAY SO_SNDBUF=65536 SO_RCVBUF=65536 SO_KEEPALIVE
os level = 65
use sendfile = Yes
dns proxy = No
dont descend = /proc,/dev,/etc
deadtime = 15
# Enable symlinks
unix extensions = No
wide links = yes
follow symlinks = yes

# Securtity settings
security = user
map to guest = Bad Password
guest account = nobody
create mask = 0664
directory mask = 0775
hide dot files = yes
client min protocol = SMB2
client max protocol = SMB3
[ShareName]
comment = Sites folder
path = /home/web
force user = www-data
force group = www-data
read only = No
guest ok = Yes
writable = yes
create mask = 0664
directory mask = 2775

В последней секции мы настраиваем непосредственно шару. В названии секции указываем имя шары ShareName. Path = путь к файлам, которые мы хотим расшарить. В параметрах force user и force group указываем linux-пользователя, от имени которого будут сохраняться файлы при изменении и создании в шаре. Так как у меня там лежат файлы для веб-сервера – у меня пользователь www-data

Перезапускаем Samba

systemctl restart smbd

Отключаемся и выходим в командную строку Windows

exit

Всё готово. Теперь остается только запустить наш ярлык или выйти из профиля пользователя windows и снова войти (если вы создали задачу в планировщике).

После этого ваша удаленная шара будет доступна по адресу \\10.255.255.1\ShareName — Можно даже монтировать её как сетевой диск.

Картинка с сайта: azzrael.ru

Сегодня расскажу как смонтировать папку (например, с сайтами) из Debian в Windows 10 по SSH (SFTP) с удобным включением/выключением. Под нужным пользователем (www-data) с нужными правами.

Ниже длинное вступление о том как и зачем мне это нужно. Его можно промотать.

Те кто читал мои посты в блоге и видел видосики на канале знают что в основном я занимаюсь разработкой своих сайтов на WordPress, Yii, Laravel. Основной инструмент — PhpStorm. Боевые проекты хостятся на разных вдсках в основном это FastVPS и RuWEB. Везде Debian + Nginx и везде более менее стандартный конфиг (с поправкой на версии и нагрузку кажого из проектов). Всего порядка десяка вдсок.

Разработка и бэкапы на локальной машине под Windows 10, где крутится усредненный аналог боевой конфиги в VirtualBox. Т.е. дев сервер сейчас это Debian 10 + Nginx 1.15.

Разработка и деплой на rsync

Со всех вдсок sh скрипт с помощью

ssh + rsync + mysqldump  собирает текущие версии проектов и в итоге на дев инстансте всегда актуальные данные любого из проектов. На деве ведется разработка, тестирование, минификация, обфускация и т.д.После чего тем же скриптом изменения деплоятся на прод, на конкретную вдску. Git используется только на деве.

Я знаю про Docker

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

Проблема на самом деле в PhpStorm

Картинка с сайта: azzrael.ru

В PhpStorm когда вы создаете проект из ранее созданных файлов ( Create New Project from Existing Files ) у вас есть по сути два выбора — файлы проекта расположены локально или удаленно. Если создать проект из удаленных файлов, то PhpStorm будет скачивать их все на локальный диск для индексации. А при изменении закачивать их обратно на удаленный сервер (например по SFTP). Это не проблема, когда разработка идет на одном компьютере.

Разработка на разных компах, в разных сетях

Однако я работаю сразу на 3х — стационарный десктоп под Windows 10, два ноутбука. Один ноут используется дома (нравится мне менять места и позы во время работы), второй используется реже — вне дома. И в этом случае возникает сложность синхронизации локальных проектов одного и того же удаленного проекта. Особенно если это проекты с множеством мелких файлов. Например Laravel c Laravel Mix. Короче жуткая головная боль.

Монтирование папки из Debian все бы решило

Куда проще если бы можно было подмонтировать удаленную папку сайта и создавать проект в PhpStorm как с локальными файлами. В Ubuntu это делается элементарно, а вот под виндой все на порядок сложнее.

Вариант с Samba

В принципе дома у меня работала схема с Samba сервером на дев виртуалке под юзером www-data. Но если работать с дев сервером с улицы (через проброс портов через роутер) и если домашний ip динамический, то возникает несколько сложностей — нужно каждый раз менять ip, пробрасывать порт в роутере ещё и на самбу (лишняя уязвимость), перемонтировать диски. Короче хотелось так чтобы как в Ubuntu. И выход нашелся.

Монтирование папки из Linux (Debian) в Windows по SFTP

Для монтирования папки из Linux в Window 10 по SFTP я использую связку billziss-gh/winfsp  + billziss-gh/sshfs-win . WinFSP — это порт https://github.com/libfuse/sshfs под винду. А sshfs — это как раз та сетевая файловая система что используется в Ubuntu для монтирования по SFTP. Как я и хотел.

Итак ставим сначала WinFSP, затем SSHFS-Win. Сразу после перезагрузки диски папки можно будет легко монтировать прямо из проводника Windows 10. См. картинку.

Картинка с сайта: azzrael.ru

Монтирование папки через проводник в SSHFS-Win

Однако в моем случае это не решило проблему.

Нестандартные порты SSH при монтировании

При монтировании папки через проводник вы можете указать путь до папки на сервере, но не можете указать порт SSH, если ssh висит не на 22. Это можно сделать в командной строке

Но тогда:

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

Есть ощущение что это все можно решить если глубоко погрязнуть в скрипты настройки SSHFS-Win, однако здесь есть и два GUI это SiriKali и SSHFS-Win-Manager  .

SiriKali мне жутко не понравился, а вот SSHFS-Win-Manager прижился. Собственно его использование решает почти все проблемы для монтирования дисков из Linux в Windows 10 по SFTP. Я напишу о его настройке чуть ниже. Однако в моем случае просто монтирования было не достаточно.

SSHFS-Win проблемы с юзером и правами на новые папки и файлы

Я ведь все эту чехарду устроил ради разработки и мне нужно чтобы работа на подмонтированном диске была из под юзера

www—data  юзер www-data по умолчанию не имеет доступа к консоли и под ним нельзя примонтировать диск. Также SSHFS-Win создает НОВЫЕ папки и файлы с правами 0700 (для уже созданных не меняет), а мне надо чтобы было 0755 на папки и 0644 на файлы.

Разрешаю монтирование под www-data

Это самое сомнительное решение. Во всей этой схеме. Однако для виртуалки за роутером я решил что сойдет.

И в файле

/etc/passwd правлю строку:

Обрати внимание что я сменил и папку юзера на ту, которую буду монтировать. Перезагружаю виртуалку и все — под www-data можно логиниться и монтировать диски.

Права на вновь создаваемые папки и файлы под SSHFS-Win

Для задания нужных прав у WinFSP есть опции

create_file_umask  и

create_dir_umask . Их можно использовать в командной строке, однако проще в SSHFS-Win-Manager . Смотри картинки ниже.

Настройки SSHFS-Win-Manager

Картинка с сайта: azzrael.ru

Здесь я создал два диска с одной буквой. Все эти маунты ведут на одну и туже виртуалку VirtualBox. Но один на внутренний IP, а второй через внешний динамический IP (через роутер с проброшенными портами на 80, 443 и ssh). Т.е. дома я монтирую верхний вариант и проброс в роутере могу вообще закрыть. А если работаю вне дома, то монтирую нижний. При этом для PhpStorm это всегда один и тотже локальный диск V. Невероятно удобно.

Картинка с сайта: azzrael.ru

Картинка с сайта: azzrael.ru

На этой картинки расширенные настройки, которые позволяют выставить нужные мне права (0755 / 0644). Если тебе нужны другие права гугли “permission umask ”.

На данный момент схема хорошо работает. На 4G Laravel проект под PhpStorm индексируется на 20-30 секунд, что более чем приемлемо.  Если есть что дополнить или вопросы — пиши комменты (могут отлетать в премодерацию — это норма, я одобрю и отвечу). Также я есть в Телеграм.