SSH - Записная книжка сисадмина. Подключение к VPS с компьютера с ОС семейства Windows. Удаленное выполнение команды

) — комментарии отдельным постом.

Удаленное подключение к рабочему столу Linux из Windows с помощью Xming и SSH

пт, 21/03/2008 — 15:46 - admin

Иногда приходится пользоваться тем, что дали. Мой компьютер, на котором стоит Debian Linux, был занят моей женой (не учите своих жен пользоваться линуксом). Зато был свободен компьютер сестры с установленным на нем Windows. И вот появилось желание подключиться к своему компьютеры с рабочей станции под управлением враждебной OS. Первым, что пришло в голову — это удаленный рабочий стол. Однако, нашлось более элегантное решение. И, несмотря на заголовок статьи, речь пойдет о немного другой технологии. Взгляните на этот снимок:

Вы видите приложения Linux прямо на рабочем столе Windows! Как же они туда попали?

Немного о теории. В отличие от Windows, в Linux графическая оболочка не является частью ядра системы. Стандартная оконная система для Linux — это X Window System, или, попросту говоря, иксы. Она берет на себя отрисовку графических элементов и взаимодействие с устройствами ввода-вывода. А самое вкусное заключается в том, что эта система имеет прозрачную клиент-серверную архитектуру. Оконная система выполняет роль сервера, а графические приложения — роль клиентов. Как и положено клиентам, они подключаются к серверу и взаимодействуют с ним для отрисовки и для получения событий мыши и клавиатуры.

Но это еще не все! Дело в том, что оконная система может находиться на другом компьютере, а графическое приложение связываться с ней через сеть. Так вы можете запустить приложение на удаленном компьютере, заставив его рисоваться на том компьютере, за которым сейчас работаете. Или наоборот. Или запустить программу на одном удаленном компьютере с отрисовкой интерфейса на другом удаленном компьютере. Заманчивая возможность, неправда ли? 🙂

Думаю, достаточно теории, давайте приступим к практике.

Для начала подготовим удаленный компьютер Debian Linux. Все, что нам здесь нужно — это SSH-сервер. Через него мы будем подключаться удаленно и запускать нужные нам программы. Выполняем всего одну команду в консоли:

$ sudo apt-get install openssh-server

Все, с этим компьютером мы закончили, и касаться его клавиатуры в ходе этой статьи больше не будем. Теперь можем переходить к подготовке компьютера Windows. Здесь нужно установить две программы:

1. SSH-клиент. Я установил PuTTY.
2. X Server для Windows. Я выбрал Xming .

Обе программы можно загрузить с сайта (пакеты Xming и Xming-portable-PuTTY). Также по желанию можно загрузить стандартный набор шрифтов (пакет Xming-fonts). Все, что загрузили — устанавливаем (с полной установкой всех компонент Xming), и переходим к настройке. Теперь главное не запутаться, что к чему будем подключать 🙂

Для начала установим соединение по SSH с удаленным компьютером. Для этого запускаем PuTTY. Вводим IP-адрес компьютера Linux.

Теперь переходим в раздел Connection / SSH / X11 и включаем перенаправление графического интерфейса. В качестве расположения X-сервера водим IP-адрес компьютера Windows, за которым сейчас сидим.

Кроме того, чтобы вместо русских букв не всплыли крокозябли, желательно в разделе Window / Translation установит правильную кодировку (у меня — UTF8 — стандартная кодировка на Debian и Ubuntu). Возвращаемся в раздел Session, сохраняем настройки и подключаемся к компьютеру Linux. В случае успешного подключения мы вводим логин и пароль и видим текстовую консоль. С ее помощью мы можем удаленно запустить консольные программы, но графические программы не могут рисоваться в консоли. Поэтому оставим на время наше подключение по SSH.

Теперь настроим Xming. Для этого запускаем программу XLaunch — это мастер настроек. На первом шаге указываем способ интеграции в графическое окружение Windows. Мне более всего по душе первый, когда каждое приложение Linux находится в своем окне.

На втором шаге нам предлагается автоматически запускать какое-нибудь приложение вместе с иксами. Я предпочел сделать это позже по мере необходимости посредством уже запущенного нами PuTTY.

На третьем шаге указываем параметры запуска Xming. Опция Clipboard позволяет интегрировать буфер обмена. Также для полноценной работы я ввел следующие параметры:
«-dpi 96» — чтобы поправить размер шрифтов. Значение можно подбирать по вкусу.
«-xkblayout us,ru» — для работы с двумя раскладками клавиатуры.
«-xkbvariant basic,winkeys» — уточнение раскладок.
«-xkboptions grp:caps_toggle» — переключение раскладки клавишей CAPS LOCK.

И, наконец, на следующем шаге сохраняем настройки кнопкой «Save configuration» и запускаем X-сервер кнопкой «Готово».

В системном лотке появится иконка Xming

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

Итак, X-сервер запущен. Возвращаемся в нашу консоль, предоставленную соединением SSH. Здесь мы можем удаленно запустить консольное приложение, и в этой же консоли увидим вывод этого приложения. А что теперь будет, если мы попытаемся запустить в этой консоли графическое приложение? Обычно, если вы подключились по SSH и пытаетесь запустить оконное приложение, вы получите ошибку, потому что вы подключились к удаленному компьютеру в консольном режиме, и рисовать окна просто нечем. Однако, в этот раз мы включили перенаправление графики на наш компьютер Windows, на котором уже запущен свой X-сервер. Поэтому, если вы попытаетесь запустить оконное приложение в удаленном консольном терминале, его окно нарисуется на компьютере Windows. Попробуйте, например, набрать следующую команду:

$ kwrite &
или
$ gedit &

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

Ну, надеюсь, у вас все получилось, и на вашем рабочем столе Windows красуются оконные приложения Linux.

Кстати говоря, благодаря этой клиент-серверной архитектуре злоумышленник может отправить на ваш экран окно с просьбой ввести ваш пароль или еще с какой-нибудь гадостью. Чтобы такого не происходило, не подключайтесь к общественным сетям без фаирвола. И помните: большие возможности — это большая ответственность.

Эта страница нуждается в сопроводителе

Статья не гарантирует актуальность информации. Помогите русскоязычному сообществу поддержкой подобных страниц. См. Команда переводчиков ArchWiki

Secure Shell (SSH) - это сетевой протокол, который позволяет двум компьютерам обмениваться данными по безопасному каналу. Шифрование обеспечивает конфиденциальность и неприкосновенность информации. SSH использует шифрование с открытым ключом для проверки подлинности удаленного компьютера и предоставляет ему аутентификацию пользователя, если это необходимо.

Обычно SSH используется для подключения (входа) к удаленной машине и выполнения команд, но он также поддерживает туннелирование (tunneling), проброс TCP-портов и передачу сеанса X11; передача файлов может быть осуществлена с использованием протоколов SFTP или SCP.

По умолчанию сервер SSH "прослушивает" стандартный порт TCP номер 22. Программа-клиент SSH обычно используется для установления связи с демоном sshd , который принимает удаленные подключения. И сервер, и клиент, как правило, присутствуют в современных операционных системах, в том числе в Mac OS X, GNU/Linux, Solaris и OpenVMS. Существуют проприетарные, freeware и open source (с открытым исходным кодом) версии различных уровней сложности и завершенности.

OpenSSH

OpenSSH (OpenBSD Secure Shell) - это набор компьютерных программ, дающих возможность установления шифрованных сессий через компьютерную сеть с использованием протокола ssh. Он был создан как свободная (open source) альтернатива проприетарному программному обеспечению, предлагаемому SSH Communications Security. OpenSSH разрабатывается как часть проекта OpenBSD, возглавляемого Тео де Раадтом (Theo de Raadt).

OpenSSH иногда путают с похожим по звучанию OpenSSL, однако, у этих проектов разные цели, и они разрабатываются разными командами. Похожесть названий связана с использованием слова "Open", которое означает приверженность одним и тем же идеям.

Установка OpenSSH

Настройка SSH

Клиент

Файл конфигурации клиента SSH - /etc/ssh/ssh_config или ~/.ssh/config .

Демон

Файл конфигурации демона SSH можно найти и отредактировать в /etc/ssh/sshd _config .

Чтобы предоставить доступ только некоторым пользователям, добавьте эту строку:

AllowUsers пользователь1 пользователь2

Чтобы предоставить доступ только некоторым группам пользователей:

AllowGroups группа1 группа2

Чтобы отключить вход через SSH под суперпользователем (root), измените строку PermitRootLogin:

PermitRootLogin no

Чтобы добавить приятное приветственное сообщение, отредактируйте файл /etc/issue и измените строку Banner:

Banner /etc/issue

Управление демоном sshd

Демон SSH имеет различные файлы юнитов systemd.

Вы можете запустить демон для немедленного использования и/или включить его в автозагрузку при старте системы, как описано в разделе Systemd (Русский)#Использование юнитов :

# systemctl start sshd.service # systemctl enable sshd.service

В качестве альтернативы демон SSH поддерживает активацию сокета. Это означает, что systemd будет прослушивать сокет SSH и запускать его только тогда, когда будет получено первое входящее подключение:

# systemctl start sshd.socket # systemctl enable sshd.socket

Если вы используете отличный от порта по умолчанию (22) порт для сокета, необходимо задать "ListenStream" в файле юнита. Скопируйте /lib/systemd/system/sshd.socket в /etc/systemd/system/sshd.socket , чтобы избежать его перезаписи во время обновлений. В файле /etc/systemd/system/sshd.socket измените значение строки "ListenStream" на необходимый порт.

Важно: Использование sshd.socket фактически сводит на нет настройку ListenAddress , так что умолчальный sshd.socket будет принимать подключения с любого адреса. Чтобы получить эффект от настройки ListenAddress , необходимо создать файл юнита и отредактировать строку ListenStream (например, ListenStream=192.168.1.100:22 равнозначен ListenAddress 192.168.1.100). Также необходимо добавить FreeBind=true в секцию , иначе настройка IP-адреса будет иметь тот же эффект, что и настройка ListenAddress: сокет не запустится, если сеть не поднимется вовремя

Совет: При использовании активации через сокет ни sshd.socket , ни обычный sshd.service не позволяют отслеживать подключение в логе, а при вызове # journalctl /usr/bin/sshd такая возможность есть

Подключение к серверу

Для подключения к серверу выполните:

$ ssh -p порт пользователь@адрес_сервера

Защита SSH

Предоставление удаленного входа в систему через SSH хорошо подходит для административных задач, но может угрожать безопасности вашего сервера. Часто являясь целью атак полного перебора (brute force), SSH-доступ нуждается в правильном ограничении для защиты от третьих лиц.

Используйте нестандартные имена аккаунтов и пароли
Допускайте входящие SSH-подключения только от проверенных машин
Используйте fail2ban или sshguard для контроля подобных атак и запрещайте доступ с IP-адресов, которые их проводят

Защита от атак полного перебора (brute force)

"Brute forcing" - довольно простое понятие: кто-либо постоянно пытается авторизоваться на веб-странице или в командной строке сервера путем перебора большого количества комбинаций из имен пользователей и паролей. Вы можете защититься от подобных атак, используя автоматический скрипт, блокирующий их. Например, fail2ban или sshguard .

Также можно сделать подобные атаки невозможными отключив вход по паролю. Для этого добавьте следующую настройку в файл sshd_config:

PasswordAuthentication no

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

Ограничение входа от имени суперпользователя

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

Отключение

Sudo выборочно предоставляет права суперпользователя для действий, которым они необходимы, без соответствующего входа в учетную запись root. Благодаря этому можно заблокировать аккаунт root, чтобы отключить возможность входа в него через SSH. Это потенциально является средством защиты от брут-форс (brute force) атак, поскольку в этом случае атакующему придется подбирать еще и имя учетной записи в дополнение к паролю.

Чтобы отключить вход от имени суперпользователя через SSH, получите его права и отредактируйте секцию "Authentication" файла /etc/ssh/sshd_config . Просто измените значение #PermitRootLogin yes на no и раскомментируйте строку:

/etc/ssh/sshd_config PermitRootLogin no ...

Перезапустите демон SSH:

# systemctl restart sshd

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

Ограничение

Некоторые автоматические задачи, такие как удаленное создание резервной копии системы, требуют полного root-доступа. Чтобы получить безопасную возможность его использования, вместо отключения можно указать конкретные команды. Для этого отредактируйте файл ~root/.ssh/authorized_keys , создав префиксы для соответствующих ключей, например:

Command="/usr/lib/rsync/rrsync -ro /" ssh-rsa …

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

При этом остается возможность входа в систему с использованием имени суперпользователя. Это можно исправить, добавив следующую строку в файл sshd_config:

PermitRootLogin forced-commands-only

Эта настройка не только ограничит список команд, которые могут выполняться от имени суперпользователя через SSH, но и отключит использование паролей, оставляя возможность входа в аккаунт root лишь с использованием аутентификации по открытому ключу.

Есть альтернатива, вводящая меньше ограничений, которая позволит выполнять любые команды от имени суперпользователя, но сделает невозможным использование брут-форс (brute-force) атак благодаря отключению входа по паролю. Для этого пропишите:

PermitRootLogin without-password

Другие клиенты и серверы SSH

Помимо OpenSSH, существует большое количество клиентов и серверов SSH.

Dropbear

Клиент для командной строки называется dbclient.

Альтернатива SSH: Mobile Shell

Remote terminal application that allows roaming, supports intermittent connectivity, and provides intelligent local echo and line editing of user keystrokes. Mosh is a replacement for SSH. It"s more robust and responsive, especially over Wi-Fi, cellular, and long-distance links.

Шифрованный туннель SOCKS

Эта опция крайне полезна для пользователей портативных компьютеров (ноутбуков), подключающихся к различным небезопасным беспроводным сетям. Единственное, что вам необходимо, это сервер SSH, запущенный в каком-либо безопасном месте, например, дома или на работе. Может оказаться полезным использование сервиса динамического DNS, такого как DynDNS , чтобы не было необходимости знать ваш IP-адрес.

Шаг 1: установка соединения

Для запуска соединения необходимо выполнить лишь эту простую команду:

$ ssh -TND 4711 пользователь @хост

где пользователь - ваше имя пользователя на сервере SSH, запущенном на машине хост . Вас попросят ввести пароль, после чего соединение будет установлено! Флаг N отключает интерактивное приглашение командной строки, а флаг D указывает локальный порт для прослушивания (вы можете выбрать любой номер порта, если хотите). Флаг T отключает псевдо-tty распределение (pseudo-tty allocation).

Также хорошей идеей является использование флага verbose (-v).

Шаг 2: настройка браузера (или других программ)

Эта опция совершенно бесполезна, если вы не настроите ваш веб-браузер (или другие программы) на использование вновь созданного туннеля socks. Текущая версия SSH поддерживает как SOCKS4, так и SOCKS5, и вы можете использовать любой из них.

Для Firefox: Правка > Параметры > Дополнительно > Сеть > Соединение > Настройка :
Выберите пункт Ручная настройка прокси и введите localhost в поле SOCKS host , после чего введите ваш номер порта в следующее текстовое поле (в приведенном выше примере это 4711)

Firefox не посылает автоматического запроса DNS через туннель socks. Эта потенциальная проблема безопасности может быть "смягчена" при помощи следующих действий:

Перейдите по адресу about:config, введя его в адресную строку Firefox
Найдите параметр network.proxy.socks_remote_dns
Установите его значение в true
Перезапустите браузер

Для Chromium: вы можете установить настройки SOCKS через переменные окружения или опции командной строки. Я рекомендую добавить одну из следующих функций в ваш.bashrc:

function secure_chromium { port=4711 export SOCKS_SERVER=localhost:$port export SOCKS_VERSION=5 chromium & exit }

Function secure_chromium { port=4711 chromium --proxy-server="socks://localhost:$port" & exit }

Теперь откройте терминал и просто выполните:

$ secure_chromium

Наслаждайтесь вашим защищенным туннелем!

Проброс X11

Проброс Х11 - это механизм, который позволяет графическим интерфейсам программ, работающих на удаленной машине-сервере, отображаться на локальной машине-клиенте. При этом нет необходимости устанавливать на удаленном узле всю систему Х11, но надо установить хотя бы xauth . xauth - это утилита, которая поддерживает конфигурации Xauthority , используемые сервером и клиентом для аутентификации сессии X11 ().

Настройка

На удаленной системе:

На клиенте включите опцию ForwardX11 либо добавив флаг -X в командной строке для необходимых подключений, либо присвоив в опции ForwardX11 значение yes .

Совет: Если GUI отображается плохо или вы получаете ошибки, можно включить опцию ForwardX11Trusted (в командной строке это флаг -Y). Это предотвратит управление пробросом Х11 со стороны расширения безопасности X11 . Если вы будете использовать эту опцию, обязательно прочитайте в начале этого раздела

Использование

Будьте осторожны с некоторыми приложениями, так как они могут проверять локальную машину на предмет уже работающего приложения. Один из примеров - Firefox : либо закройте работающий Firefox, либо используйте следующий параметр запуска:

$ firefox -no-remote

Если вы получите ошибку "X11 forwarding request failed on channel 0" при подключении (и лог-файл сервера /var/log/errors.log будет содержать строку "Failed to allocate internet-domain X11 display socket"), удостоверьтесь, что пакет xorg-xauth установлен. Если его установка не поможет, попробуйте сделать одно из двух:

Включить опцию AddressFamily any в sshd _config на сервере
Присвоить опции AddressFamily в sshd _config на сервере значение inet

Присвоение значения inet может исправить проблемы с клиентами Ubuntu при использовании IPv4.

Для запуска приложений X от имени других пользователей на сервере SSH вам необходимо добавить (xauth add) строку аутентификации, взятую из xauth list пользователя, вошедшего в систему.

Проброс других портов

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

Локальный проброс открывает на локальной машине порт, подключения к которому будут перенаправлены на удаленный хост, а оттуда - по заданному направлению. Очень часто этим направлением будет сам удаленный хост, предоставляющий secure shell и, например, безопасное соединение VNC для этой же машины. Локальный проброс осуществляется при помощи ключа -L и задания спецификации проброса в следующей форме: <порт туннеля>:<адрес назначения>:<порт назначения> .

Например:

$ ssh -L 1000:mail.google.com:25 192.168.0.100

будет использовать SSH для входа в систему и открытия шелла на 192.168.0.100, а также создаст туннель от порта 1000 локальной машины на порт 25 mail.google.com. В результате подключения к localhost:1000 будут перенаправлены на порт Gmail SMTP. To Google, it will appear that any such connection (though not necessarily the data conveyed over the connection) originated from 192.168.0.100, and such data will be secure as between the local machine and 192.168.0.100, but not between 192.168.0.100, unless other measures are taken.

$ ssh -L 2000:192.168.0.100:6001 192.168.0.100

будет принимать подключения к localhost:2000, которые будут перенаправлены на порт 6001 удаленного хоста. Этот пример хорош для установления подключений VNC с использованием vncserver utility.

Удаленный проброс позволяет удаленному хосту подключаться к произвольному хосту через туннель SSH и локальную машину, предоставляя функционал, обратный локальному пробросу. Это полезно в ситуациях, когда, например, удаленный хост ограничен фаерволлом. Он включается ключом -R и заданием спецификаций проброса в следующей форме: <порт туннеля>:<адрес назначения>:<порт назначения> .

Например:

$ ssh -R 3000:irc.freenode.net:6667 192.168.0.200

поднимет шелл на 192.168.0.200, и соединения из 192.168.0.200 к своему же порту 3000 (иначе говоря, localhost:3000) будут посланы через туннель на локальную машину, а затем на irc.freenode.net, порт 6667, что в данном примере позволит использовать программы IRC на удаленном хосте, даже если обычно порт 6667 будет для них заблокирован.

Оба вида проброса могут быть использованы для предоставления безопасного "шлюза", позволяющего другим компьютерам получить преимущества туннеля SSH без непосредственно работающего SSH или демона SSH, при использовании bind-адреса в начале туннеля как части спецификации проброса, например, <адрес туннеля>:<порт туннеля>:<адрес назначения>:<порт назначения> . <адрес туннеля> может быть любым адресом на машине, localhost , * (или blank), который, соответственно, пропускает соединения через заданный адрес, интерфейс loopback или любой интерфейс. По умолчанию проброс ограничен соединениями от машины в начале туннеля, <адрес туннеля> установлен в localhost . Локальный проброс не требует дополнительной настройки, в то время как удаленный проброс ограничен конфигурацией демона SSH удаленного сервера. Смотрите опцию GatewayPorts на справочной странице sshd_config(5) для получения дополнительной информации.

Увеличение скорости SSH

Вы можете сделать так, чтобы все сессии использовали одно соединение, что значительно увеличит скорость последующих логинов. Для этого добавьте следующие строки под необходимым хостом в /etc/ssh/ssh_config:

Host examplehost.com ControlMaster auto ControlPersist yes ControlPath ~/.ssh/socket-%r@%h:%p

Смотрите справочную страницу ssh_config(5) для получения полного описания этих опций.

Другая возможность увеличения скорости - включение сжатия при помощи флага -C . Еще лучше добавить следующую строку под необходимым хостом в /etc/ssh/ssh_config:

Compression yes

Важно: В ssh(1) утверждается, что "сжатие помогает в случае использования модемных линий и других медленных соединений, а в сетях с большой скоростью лишь замедляет работу ". В зависимости от конфигурации вашей сети этот совет может быть контрпродуктивен

Время, необходимое на вход в систему, может быть уменьшено при помощи флага -4 , который отключает поиск через IPv6. Это может быть также достигнуто добавлением следующей строки под необходимым хостом в /etc/ssh/ssh_config:

AddressFamily inet

Изменение шифров, используемых SSH, на менее требовательные к процессору, также может увеличить скорость. С этой точки зрения наилучшим выбором станут arcfour и blowfish-cbc.

Важно: Пожалуйста, не делайте этого, если вы не знаете, к чему это приведет; у arcfour имеются слабые стороны

Для использования альтернативных шифров запустите SSH с флагом -c:

$ ssh -c arcfour,blowfish-cbc пользователь@адрес-пользователя

Чтобы использовать их постоянно, добавьте следующую строку под необходимым хостом в /etc/ssh/ssh_config:

Ciphers arcfour,blowfish-cbc

Монтирование удаленных файловых систем при помощи SSHFS

Примеры использования:

$ autossh -M 0 -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" имя_пользователя@example.com $ sshfs -o reconnect,compression=yes,transform_symlinks,ServerAliveInterval=45,ServerAliveCountMax=2,ssh_command="autossh -M 0" имя_пользователя@example.com: /mnt/example

Подключение через SOCKS-прокси, сконфигурированный при помощи настроек proxy :

$ autossh -M 0 -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" -NCD 8080 имя_пользователя@example.com

При помощи опции -f autossh может быть запущен в качестве фонового процесса. Однако, в этом случае вы не сможете вводить пароль в интерактивном режиме.

Сессия будет завершена, как только вы введете команду exit , иначе процесс autossh получит сигнал SIGTERM, SIGINT of SIGKILL.

Автозапуск Autossh при загрузке системы при помощи systemd

Если вы хотите, чтобы autossh запускался автоматически, вы можете использовать systemd. Например, вы можете создать файл юнита, подобный этому:

Description=AutoSSH service for port 2222 After=network.target Environment="AUTOSSH_GATETIME=0" ExecStart=/usr/bin/autossh -M 0 -NL 2222:localhost:2222 -o TCPKeepAlive=yes [email protected] WantedBy=multi-user.target

Здесь AUTOSSH_GATETIME=0 - это переменная окружения, указывающая, как долго ssh должен быть поднят, прежде чем autossh утвердит успешное подключение. Установка значения 0 укажет autossh игнорировать неудачное подключение ssh. Это может быть полезно при добавлении autossh в автозагрузку. Другие переменные окружения доступны на справочной странице. Конечно, вы можете сделать этот юнит более комплексным, если вам это необходимо (для получения дополнительных подробностей смотрите документацию systemd); очевидно, вы можете использовать ваши собственные опции для autossh, но учтите, что флаг -f , подразумевающий AUTOSSH_GATETIME=0 , не работает с systemd.

Затем поместите все это, например,в /etc/systemd/system/autossh.service. Теперь вы можете включить туннели autossh при помощи подобной команды:

$ systemctl start autossh

Если после этого autossh запустится, вы можете включить его в автозагрузку, выполнив

$ systemctl enable autossh

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

Легко поддерживать несколько процессов autossh для разных туннелей. Просто создайте несколько файлов.service с разными именами.

Изменение номера порта SSH для активации через сокет (sshd.socket)

Создайте файл /etc/systemd/system/sshd.socket.d/port.conf со следующим содержанием:

# Disable default port ListenStream= # Set new port ListenStream=12345

systemd будет автоматически прослушивать новый порт после перезапуска:

Systemctl daemon-reload

Решение проблем

Проверка

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

1. Каталоги ~/.ssh на клиенте и сервере, а также их содержимое, должны иметь соответствующие права доступа:

$ chmod 700 /home/ПОЛЬЗОВАТЕЛЬ/.ssh $ chmod 600 /home/ПОЛЬЗОВАТЕЛЬ/.ssh/*

2. Удостоверьтесь, что всеми файлами в каталогах ~/.ssh на клиенте и сервере владеют правильные пользователи:

$ chown -R ПОЛЬЗОВАТЕЛЬ: ~/.ssh

3. Убедитесь, что строка открытого ключа клиента (например, id_rsa.pub) есть в файле authorized_keys на сервере

4. Проверьте, не ограничивали ли вы доступ через SSH в строке AllowUsers файла /etc/ssh/sshd_config (разделяя имена пользователей пробелами)

Удаление устаревших ключей (необязательно)

5. Удалите строки, содержащие старые/неправильные ключи, из файла ~/.ssh/authorized_keys на сервере

6. Удалите старые/неправильные закрытые и открытые ключи из каталога ~/.ssh на клиенте

7. В файле сервера ~/.ssh/authorized_keys храните настолько мало ключей, насколько это возможно

Зависание подключения SSH после выключения/перезагрузки

Подключение SSH зависает после выключения или перезагрузки в том случае, когда systemd останавливает сеть раньше, чем sshd. Чтобы этого не происходило, закомментируйте и измените строку After:

/usr/lib/systemd/system/systemd-user-sessions.service #After=remote-fs.target After=network.target

Подключение отклонено или проблема тайм-аута

Ваш роутер настроен на проброс портов?

ПРОПУСТИТЕ ЭТОТ ШАГ, ЕСЛИ ВАША МАШИНА НЕ НАХОДИТСЯ ЗА МОДЕМОМ/РОУТЕРОМ NAT. Большинство домов и небольших предприятий имеют модем/роутер NAT.

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

Узнайте ваш адрес внутри сети:

Найдите ваш интерфейс (который используется для подключения к сети), а в нем - поле inet. Зайдите в веб-интерфейс настройки роутера, используя его IP. Задайте перенаправление на ваш inet IP. Перейдите по ссылке для получения дополнительной информации о том, как это сделать для некоторых роутеров.

SSH запущен и прослушивает?

$ ss -tnlp

Если эта команда не показывает открытый порт SSH, SSH НЕ запущен. Смотрите /var/log/messages на наличие ошибок.

Имеются ли правила фаерволла, блокирующие соединения?

Трафик доходит до вашего компьютера?

Запустите дамп трафика на компьютере, с которым возникли проблемы:

# tcpdump -lnn -i any port ssh and tcp-syn

Будет показана некоторая базовая информация. Подождите совпадения. После этого попробуйте подключиться вновь. Если вы не видите никакого вывода команды, когда вы пытаетесь подключиться, это значит, что что-то вне вашего компьютера блокирует трафик (это может быть аппаратный фаерволл, роутер NAT и т.д.).

Ваш провайдер или кто-то еще блокирует нужный порт?

В некоторых случаях ваш провайдер может блокировать порт по умолчанию (SSH порт 22). Чтобы это проверить, создайте сервер на всех интерфейсах (0.0.0.0) и подключитесь удаленно.

Если вы получите сообщение об ошибке вроде этого:

Ssh: connect to host www.inet.hr port 22: Connection refused

Однако, если вы получите сообщение об ошибке вроде этого:

Ssh: connect to host 111.222.333.444 port 22: Operation timed out

это означает, что что-то отклоняет ваш трафик TCP, предназначенный для порта 22. Как правило, этот порт скрыт либо вашим фаерволлом, либо третьей стороной (например, провайдером, блокирующим и/или отклоняющим входящий трафик на порт 22). Если вы знаете, что фаерволл на вашем компьютере не запущен и Гремлины не размножаются на ваших роутерах и свитчах, это означает, что провайдер блокирует трафик.

Чтобы убедиться в этом, вы можете запустить Wireshark на сервере и "прослушать" трафик, предназначенный для порта 22. Поскольку Wireshark является утилитой анализа трафика на уровне 2 , а TCP/UDP используют уровень 3 и выше (смотрите статью TCP/IP), если вы ничего не получаете при создании удаленного подключения, вероятнее всего, что третья сторона блокирует трафик для этого порта на вашем сервере.

Диагностика при помощи Wireshark

Затем запустите его:

Tshark -f "tcp port 22" -i NET_IF

где NET_IF - сетевой интерфейс для соединения WAN (для проверки смотрите ip a). Если вы не получаете никаких пакетов при попытке удаленного подключения, можете быть уверены, что ваш провайдер блокирует входящий на порт 22 трафик.

Возможное решение

Вы можете просто использовать другой порт, который провайдером не блокируется. Откройте /etc/ssh/sshd_config и укажите другой порт. Например, добавьте:

Port 22 Port 1234

Также удостоверьтесь, что другие строки "Port" закомментированы. Если просто закомментировать строку "Port 22" и прописать "Port 1234", проблема не будет решена, поскольку sshd будет прослушивать лишь порт 1234. Используйте обе строки для запуска сервера SSH на обоих портах.

Перезапустите сервер systemctl restart sshd.service . Готово! Теперь вам необходимо настроить ваш(и) клиент(ы) на использование другого порта.

Read from socket failed: connection reset by peer

Последние версии openssh иногда выдают подобное сообщение об ошибке из-за бага. В этом случае добавьте следующую строку в файл ~/.ssh/config:

HostKeyAlgorithms [email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss

С openssh 5.9 это исправление не поможет. В этом случае добавьте в ~/.ssh/config следующее:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc MACs hmac-md5,hmac-sha1,hmac-ripemd160

Смотрите также обсуждение на форуме openssh.

"[ваша командная оболочка]: No such file or directory" / ssh_exchange_identification problem

Одна из возможных причин - необходимость найти абсолютный путь (который возвращает команда whereis -b [ваша командная оболочка] , например) в $SHELL , даже если бинарный пакет вашего интерпретатора находится в одной из записей $PATH .

Сообщение об ошибке "Terminal unknown" или "Error opening terminal "

В ssh возможно получение ошибок, вроде "Terminal unknown", во время входа в систему. Запуск приложений ncurses (например, nano) не удается, появляется ошибка "Error opening terminal". Есть два способа исправления этой проблемы: по-быстрому - используя переменную $TERM, и основательно с использованием файла terminfo.

Обходной путь с использованием переменной $TERM

После подключения к удаленному серверу задайте переменной $TERM значение "xterm" следующей командой:

Этот метод является обходным путем и должен использоваться на серверах ssh, к которым вы редко подключаетесь, поскольку он имеет нежелательные побочные эффекты. К тому же вам придется повторять ввод этой команды после каждого подключения, либо прописывать это значение в ~.bashrc.

Решение с использованием файла terminfo

Лучшее решение - передача файла terminfo с вашего клиента на сервер. В этом примере мы покажем, как настроить файл terminfo на терминал "rxvt-unicode-256color". Создайте каталог, содержащий файлы terminfo, на сервере ssh, когда вы подключены к нему:

mkdir -p ~/.terminfo/r/

Теперь скопируйте файл terminfo вашего терминала в новый каталог. Замените rxvt-unicode-256color на свое значение (клиентской машины) в следующей команде, а ssh-server - подходящими именем пользователя и адресом сервера.

$ scp /usr/share/terminfo/r/rxvt-unicode-256color ssh-server:~/.terminfo/r/

После входа и выхода из сервера ssh проблема должна быть решена.

Управление ключами OpenSSH, Часть 1 и Часть 2 на сайте IBM developerWorks

Feb 11 th , 2015 10:34 pm

Secure Shell или SSH - это сетевой протокол, который позволяет обмениваться данными c использованием защищенного канала между двумя сетевыми устройствами. Две основные версии протокола, называются SSH1 (или SSH-1) и SSH2 (или SSH-2). Используется в основном на Linux и UNIX системах и основан на доступе к командной строке аккаунта]. Говоря простым языком, вы получаете командную строку] на удаленном компьютере и можете делать все то же, что у на своем компьютере в терминале. SSH был разработан в качестве замены Telnet и других небезопасных удаленных оболочек, которые посылают информацию (в частности пароли) в открытом виде, что делает их восприимчивыми к взлому. Шифрование по SSH предназначено для обеспечения конфиденциальности и целостности данных при передаче по незащищенной сети, таких как Internet .

SSH использует открытый ключ шифрования для аутентификации удаленного компьютера и позволяют ему провести проверку подлинности пользователя. SSH обычно используется для входа на удаленную машину и выполнения команд, но он также поддерживает туннелирование , TCP и X11 соединения. Он так же может передавать файлы с помощью SFTP или SCP . Для SSH-сервера стандартно был назначен порт 22. SSH-клиенты обычно используется для установления соединения с SSH-сервером. Оба они присутствует на большинстве современных операционных систем, включая Mac OS X, Linux , FreeBSD , Solaris и OpenVMS .

Сменить пароль на ключ

Удаленное выполнение команды

ssh user@server hostname

Создаём Socks-proxy при наличии удалённого сервера для более безопасного веб-сёрфинга

Открываем порт для socks-proxy следующей командой

ssh -D 8080 user@server

Теперь в браузере, указав localhost:8080 в качестве socks-proxy, можно ходить по безопасно сайтам (трафик зашифрован через ssh)

Как разорвать ssh-сессию

Смотрим кто в системе:

Находим сессию пользователя и её псевдотерминал (например, pts/0) и останавливаем это:

как разрешить соединение для root только по ключам

разрешаем root заходить (в конфиге):

перегружаем SSHD:

/etc/init.d/sshd restart

генерим сертификаты у root

отсылаем сертификаты:

разрешаем теперь только ключём:

PasswordAuthentication yes

PermitRootLogin without-password

перегружаем SSHD:

/etc/init.d/sshd restart

Создаём config для работы по SSH для собственного удобства

Действие простое. В файл ~/.ssh/config добавляем

Host serv2 HostName 127.0.0.1 Port 22 User root

rsync, например, будет выглядеть так:

rsync -av --progress --partial /home/test/ serv2:/home/test

Перенаправление на машинку, которая находится в локальной сети и недоступна снаружи

Есть: внешний сервер serv и внутреняя машинка ws. Нужно иметь возможность подключаться к машинке ws извне.

Решение: на внутренней машинке ws создаём тоннель к внешней:

Если какой-либо из этих параметров есть, измените yes на no

Сессии отваливаются в Putty через некоторое время ввиду короткого таймаута.

Такое бывает, если некоторое время соединение не активно. Пусть Putty периодически отправляет пустые пакеты для поддержания связи. Это можно сделать в

Connection - Seconds between keepalives

Поставьте отправку 1 пакетика раз в 60 секунд, этого будет более чем предостаточно.

Закрываем заход пользователя root

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

В /ets/ssh/sshd_config выставляем значение

Перезапускаем sshd (не выходя из консоли, чтобы проверить заход нового пользователя. Ведь если будет что-то не так, то зайди обратно под root будет проблематично)

Заходим под новым пользователем в отдельной консоли, с помощью - логинимся под рутом. Если всё ок, то консольку с root можно закрыть.

Как выйти из SSH

просто! Жмём

до победного конца или набираем

для той же цели.

Как примонтировать с помощью SSHFS

Итак, есть у нас в наличии два компьютера с операционной системой Linux . И, как это часто бывает, нужно по сети скинуть с одного компьютера ряд файлов на другой. Можно конечно поднять SAMBA , но вот как-то это не совсем удобно и небезопасно плодить лишние открытые порты. Я предлагаю для этих дел воспользоваться SSH. Безопасно и есть почти на всех линукс-машинах.

Например, у нас есть 2 пациента. Первый - основной компьютер. Второй - ноутбук. Представим, что на каждом есть пользователь user и надо перекинуть файл file.avi из домашней директории пользователя user на компьютере в такую же директорию на ноутбук. Думаю, условия понятны. Конечно, для того, чтобы задействовать SSH, мы можем воспользоваться , mc (midnight commander) или в nautilus в меню “Файл” выбрать “Подключиться к серверу…”, но это темы уже других статей.

Итак, нам нужно в первую очередь узнать IP адреса компьютеров. Если знаете - шаг пропускаем. Если нет - в командной строке (в терминале) набираем ifconfig и смотрим адрес у eth0 (если по локальной сети копируете) или wlan0 (если по wi-fi). Допустим, у основного компьютера адрес оказался 192.168.0.1, у ноутбука - 192.168.0.2

Отлично. Теперь определимся - мы будем с ноута подсоединятся к рабочему компьютеру или с рабочего к ноуту? Разница лишь в указании IP, поэтому просто выбираем первый вариант.

Будем подключатся с ноута к десктопу, чтобы “коммуниздить” там заветный файлик. А теперь определимся, а есть ли на компьютере сервер ssh, к которому мы и хотим подключится. Итак, на рабочем компьютере задаем команду:

sudo netstat -antpu | grep ssh

И, если видим строчку

tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 2032/sshd

все ок, мы сможем продолжить. Если нет - надо поставить ssh-server, который вы можете благополучно найти в том же synaptic или другом менеджере пакетов. Поставили, проверили, заветная строчка должна появится. Если есть строчки еще - не важно, главное, чтобы хотя бы одна эта была.

Итак, на основном компьютере стоит сервер, ожидающих наше подключение. Теперь идем к ноутбуку. Для начала, посмотрите, есть ли у вас команда sshfs. Просто наберите её в терминале. Если нет - нужно поставить.

Теперь торжественный момент - монтируем удаленный компьютер. Набираем команду:

sshfs user@сайт:/ /home/user/computer

где * user - пользователь на компьютере

сайт - адрес основного компьютера, как мы это ранее выяснили

/home/user/computer - папка, которую мы ранее создали специально для того дела

Если вы сделали все правильно, то в /home/user/computer вы должны увидеть файловую систему удаленного, то есть основного, компьютера. Теперь вы можете открыть любой файловый менеджер (Наутилус или mc) и скопировать нужный вам файл. В нашем случае это можно сделать командой:

cp -v /home/user/computer/home/user/file.avi /home/user/

Опции монтирования

Их все можно увидеть, набрав sshfs -h. Укажем наиболее часто нужные. Если они вам необходимы, просто поставьте их в конце строки:

P PORT -здесь вы указываете свой порт, если он не 22

C -использовать ли сжатие

O reconnect -пересоединится при разрыве

O sshfs_sync -синхронная запись

O cache=YESNO -использовать или не использовать кеш

O follow_symlinks -follow symlinks on the server

Posted by Алексей Убоженко Feb 11 th , 2015 10:34 pm soft

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

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

Например, параметр AllowG roups позволит ограничить круг пользователей, обладающих правом входа в систему через SSH, указанными группами, которые определены в файле /etc/group (глава 7). Если этот параметр определен, а пользователь не принадлежит ни к одной из допустимых групп, он не сможет войти в систему. Группы в списке должны отделяться пробелами:

AllowGroups wheel webmaster dnsadmln

Если вы не хотите предоставлять доступ через SSH целой группе пользователей, можно с помощью параметра Allowllsers определить список допустимых пользователей. При использовании параметра Allowllsers автоматически запрещается доступ всем остальным пользователям, отсутствующим в списке.

Параметр DenyGroups противоположен параметру AllowGroups. Пользователи из перечисленных здесь системных групп не смогут войти в систему. Указанные группы должны быть их главными группами, то есть должны быть представлены в /etc/master.passwd, а не просто в /etc/ group. Это ограничение делает параметр DenyGroups менее полезным, чем может показаться на первый взгляд; для достижения желаемого эффекта будет недостаточно определить универсальную группу nossh и просто добавить в нее пользователей, эта группа должна быть главной для них. Явное перечисление допустимых групп обеспечивает более полезную политику безопасности.

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

Как эти параметры влияют на права доступа пользователя, входящего в несколько групп? Например, пользователь входит в группу, присутствующую в списке AllowGroups, и в группу из списка DenyGroups. Что произойдет в этом случае? Демон SSH проверяет значения этих параметров в следующем порядке: Denyllsers, Allowllsers, DenyGroups и Allow- Groups. Учитывается первое совпадение. Предположим, что я член группы wheel, и в файле sshd_config присутствует следующий фрагмент:

DenyUsers: mwlucas AllowGroups: wheel

Я не смогу войти в эту систему через SSH, потому что значение параметра DenyUsers проверяется до значения параметра AllowGroups.

Клиенты SSH

Безусловно, клиент SSH уже присутствует в FreeBSD, как и в большинстве других UNIX-подобных операционных систем. По возможности старайтесь пользоваться встроенным клиентом SSH, поскольку он входит в состав пакета OpenSSH, разработанного командой OpenBSD, и является не только самой популярной, но и лучшей реализацией. Если вы вынуждены использовать операционную систему Microsoft Windows, рекомендую программу PuTTY, которая может бесплатно использоваться как в коммерческих, так и в некоммерческих целях и является прекрасным эмулятором терминала.

Эта книга посвящена FreeBSD, поэтому все внимание будет уделено клиенту OpenSSH в этой операционной системе. Вы можете настроить клиента самыми разными способами, но в большинстве случаев настройки сводятся к запрету использования функций, предлагаемых сервером. Если вам действительно интересна тема настройки поведения клиента, прочитайте страницу руководства ssh_config(5).

Чтобы подключиться к другому хосту через SSH, следует ввести команду ssh имя_хоста. В ответ вы должны увидеть примерно следующее:

# ssh sardines.blackhelicopters.org

The authenticity of host ‘sardines.blackhelicopters.org (192.168.1.1)’ can’t be established.

DSA key fingerprint is a4:df:7c:7e:Oe:27:e5:21:b4:f4:Oe:2b:c9:10:5f:ea.

Are you sure you want to continue connecting (yes/no) 9 yes

(Перевод: Подлинность хоста ‘sardines.blackhelicopters.org (192.168.1.1)’

не может быть установлена.

Отпечаток ключа DSA a4:df:7c:7e:0e:27:e5:21:b4:f4:0e:2b:c9:10:5f:ea. Вы действительно желаете продолжить соединение (yes/no) 9)

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

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

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

Примите ключ хоста, и вам будет позволено выполнить вход в систему. Хотя использование закрытого ключа и секретной фразы предпочтительнее использования простого пароля, все же в SSH пароль защищен намного лучше, чем в telnet.

Копирование файлов через SSH

Клиент SSH хорош для организации доступа к командной строке, а как быть с перемещением файлов из одной системы в другую? SSH включает два инструмента перемещения файлов по сети – scp(l) и sftp(l).

Инструмент scp(l) (secure copy – безопасное копирование) идеально подходит для перемещения отдельных файлов. Команда scp принимает два аргумента: первый – текущее местоположение файла, и второй – место, где файл будет сохранен. Место, куда следует скопировать файл, определяется строкой в формате <имя_полъзователя>@<имя_хос- та>:<имя_файла>. Допустим, требуется скопировать файл bookback- up.tgz из локальной системы на удаленный сервер bewilderbeast.blackhe- licopters.org под другим именем. Для этого вводим команду:

# scp bookbackup.tgz [email protected]:bookbackup- january.tgz

Если файла копируется с тем же именем, то имя файла во втором аргументе можно опустить:

# scp bookbackup.tgz [email protected]:

Кроме того, scp(l) позволяет копировать файлы из удаленной системы в локальную:

# scp [email protected]:bookbackup-january.tgz bookbackup.tgz

Если копия файла в локальной системе должна иметь то же самое имя, имя копии в команде можно заменить символом точки:

# scp [email protected]:bookbackup.tgz .

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

# scp bookbackup.tgz bewilderbeast.blackhelicopters.org:

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

Если вы предпочитаете интерактивные системы или когда заранее неизвестно точное имя файла, который требуется скопировать из удаленной системы, на помощь придет sftp(l). Команда sftp(l) принимает единственный аргумент, состоящий из имени пользователя и имени сервера, в формате, который используется командой scp для обозначения удаленного сервера:

# sftp mwlucas@bewilderbeast,blackhelicopters.org

Connecting to bewilderbeast… Password: sftp> Is

Интерфейс sftp(l) очень напоминает стандартный клиент FTP; он поддерживает типичные команды FTP, такие как Is (list – список), cd (change directory – изменить каталог), get (download a file – загрузить файл) и put (upload a file – выгрузить файл на сервер). Одно из существенных отличий состоит в том, что sftp(l) не требует выбирать тип передаваемых файлов – ASCII или двоичный; файлы просто передаются в том виде, в каком они есть.

OpenSSH защищает все

Многие сетевые программы включают поддержку SSH для обеспечения взаимодействий. Кроме того, OpenSSH может создавать туннели между портами TCP разных машин. Благодаря OpenSSH можно обеспечить передачу любых данных по сети только в зашифрованном виде.

С помощью команд scp и sftp вы сможете полностью устранить из своей сети пароли в открытом текстовом виде.

В этом руководстве будет рассмотрен процесс подключения к VPS под управлением операционной системы семейства Linux при помощи SSH-key.

Что это такое

Использование SSH-ключей позволяет осуществить подсоединение без использования пароля. При этом такой тип авторизации гораздо безопаснее, чем вход по паролю. Пароль может быть взломан, а ключи практически не поддаются расшифровке. Secure SHell-ключ состоит из открытого и закрытого ключей, которые представляют из себя длинные последовательности символов. Вы можете поместить открытый key на компьютер, а затем разблокировать его, подключившись к нему с клиентом, у которого есть закрытый key. Когда они совпадают, вы соединитесь с виртуальным сервером (no password). Также можно еще повысить уровень безопасности, если использовать кодовое выражение для защиты закрытого ключа.

Примечание:
- порт Secure SHell по умолчанию - 22;
- по протоколу SSH можно удаленно управлять файлами благодаря SSHFS (Secure SHell FileSystem).

Создание сервера

Если при создании машины вы выбрали подключение с помощью Secure SHell-ключа, то вам необходимо его сгенерировать или добавить существующий. При создании VPS ключ будет автоматически на него добавлен.

Подключение к серверу с компьютера с ОС семейства Линукс

Вы можете соединиться с VPS командой ssh без ввода пароля. Если вы задавали кодовую фразу, вас попросят ее ввести: ssh user@

Примечание: существуют специальные программы который избавляют пользователей от неудобства каждый раз вводить ключевое выражение, например можно воспользоваться ssh-agent или ssh-add. Подробнее об этом можно почитать .

Подключение к VPS с компьютера с ОС семейства Windows

Примечание: Putty - программа для подключения к удаленным машинам по протоколам SSH, TCP, Rlogin, Telnet. В командной строке Windows PowerShell можно использовать утилиту plink.exe входящую в набор.

Для подсоединения необходимо настроить Putty. Открываем приложение, выбираем Default Settings и нажимаем Load .

В меню слева переходим Connection -> SSH -> Auth , и в поле прописываем путь до сгенерированного приватного ключа.

После соединения введите логин и кодовую фразу, если требуется.