Магия ssh / хабр

Шаг 4. Автоматически восстанавливаем SSH-туннель.

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

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

На серверной части, а именно на Ubuntu-VPS, редактируем конфигурационный файл SSH-сервера ‘/etc/ssh/sshd_config’. В него добавляем (или раскомментируем) следующие параметры:

TCPKeepAlive yes
ClientAliveInterval 30
ClientAliveCountMax 3

И перезагружаем SSH-сервер командой ‘sudo service sshd restart’. Параметр ‘TCPKeepAlive yes’ включает мониторинг работоспособности ssh-подключения. Параметр ‘ClientAliveInterval 30’ проверяет живость клиентского подключения каждые 30 секунд, впрочем, параметр можно установить на усмотрение администратора. Параметр ‘ClientAliveCountMax 3’ означает количество попыток, которые будут произведены с интервалом указанном в ClientAliveInterval до того, как соединение будет закрыто со стороны сервера. В нашем примере, если что-то произойдет с клиентом, например, компьютер просто отключится от сети, то через 90 секунд Ubuntu-VPS закроет туннельное соединение.

При создании туннельного подключения со стороны клиента есть возможность указать аналогичные параметры при подключении. Устанавливаются они через параметр ‘-o’. В нашем случае строка подключения примет следующую форму: ‘ssh -N -o «ServerAliveInterval 30» -o «ServerAliveCountMax 3» -R 8080:localhost:80 [email protected]’

Обратите внимание, что параметры на клиенте слегка отличаются от тех, что на сервере

Важно их не перепутать

Далее, любым автоматизированным средством, например, через периодические задачи cron, мы отслеживаем наличие процесса с ssh-туннелем в списке задач и в случае его отсутствия запускаем процесс еще раз. Но есть вариант удобнее и практичнее. Саксаулы рекомендуют использовать AutoSSH, как вершину ленивости программистской мысли.

AutoSSH уже входит в репозитории Ubuntu, поэтому устанавливаем ее через ‘sudo apt install autossh’ на сервер-клиент Ubuntu.

После установки AutoSSH наша строка для подключения на Ubuntu примет следующую форму ‘autossh -M 0 -N -o «ServerAliveInterval 30» -o «ServerAliveCountMax 3» -R 8080:localhost:80 [email protected]’. В команде мало что поменялось, ssh заменился на autossh, добавился параметр ‘-M 0’. Изначально предполагалось, что AutoSSH будет мониторить порт (и даже два, один для отправки пакета KeepAlive, второй для его приема), указанный в параметре ‘-M’ на наличие отклика. Этот порт должен быть свободным, да и на той стороне что-то должно отвечать, что, мол, сервис жив, все работает. Но, при наличии KeepAlive в самом SSH, необходимость тратить порты и городить ответную часть — отпала. Поэтому просто выключаем эту функцию через приведенный параметр.

При некоторых пертурбациях на сервере, проброска порта может не состояться, даже если был поднят туннель. То есть, со стороны SSH-сервера и SSH-клиента, все будет выглядеть нормально, туннель будет существовать и работать, но вот порт не будет проброшен от одного сервера к другому. Для автоматической перезагрузки туннеля в таком случае стоит применить дополнительный параметр ‘-o «ExitOnForwardFailure=yes»‘. В таком случае, если возникает проблема с проброской портов, то SSH-туннель будет отключаться. И повторно подключаться через AutoSSH. Результирующая строчка подключения трансформируется в следующее: ‘autossh -M 0 -N -o «ServerAliveInterval 30» -o «ServerAliveCountMax 3» -o «ExitOnForwardFailure=yes» -R 8080:localhost:80 [email protected]’.

Answer

Users of SSH X11 Forwarding who su — to become root

OBJECTIVE:

Provide an explanation of errors and work around

PROCEDURES:

PROBLEM RE-CREATION STEPS:1)

% cp /etc/ssh/sshd_config /etc/ssh/sshd_config.save% vi /etc/ssh/sshd_config

#X11Forwarding no to X11Forwarding yes

% stopsrc -s sshd% startsrc -s sshd

2) (This can be through PUTTY, or various Xemulators which connect through ssh)

% ssh -X NON_ROOT_USER@hostname

NOTE: NON_ROOT_USER is the non-root-userid

% echo $DISPLAYlocalhost:10

NOTE: The default DISPLAY number is 10 (See/etc/ssh/sshd_config #X11DisplayOffset 10) but this number may be different if multiple connections are established.3)

% sudo su -

% echo $DISPLAY(null)

NOTE: This is expected. This is not the same userid which connected to, and established credentials for localhost:10.5)

% export DISPLAY=localhost:10

% xhost

NOTE: This is expected. The xauth credentials for this DISPLAY were established for $NON_ROOT_USER and must be shared with root.PROBLEM RESOLUTION STEPS:IMPORTANT: IBM does not recommend this method: The following work around is only provided as a solution to certain customers’ unique situations. Since root login is disallowed by default (PermitRootLogin No»), administrators should examine their security policies to ensure this is an appropriate solution. 7)

% xauth add $(xauth -f ~NON_ROOT_USER/.Xauthority list | tail -1)

NOTE: Replace the "NON_ROOT_USER" string with the correct userid

% xhost

NOTE: This message will vary based on the Xserver access controls9)

% xauth remove localhost:10

REFERENCES:

Developer Works «Remote X11 Windows to AIX»

CATEGORY:

WWMISC

SUPPORT:

If additional assistance is required after completing all of the instructions provided in this document, please follow the step-by-step instructions below to contact IBM to open a service request (PMR) for software under warranty or with an active and valid support contract. The technical support specialist assigned to your support call will confirm that you have completed these steps.

a. Document and/or take screen shots of all symptoms, errors, and/or messages that might have occurred

b. Capture any logs or data relevant to the situation

c. Contact IBM to open a support call (PMR):

For electronic support, please visit the web page:

https://www-947.ibm.com/support/servicerequest/newServiceRequest.action
For telephone support, please visit the web page:
http://www.ibm.com/planetwide
Please visit the IBM Support Portal web page for additional resources:
https://www-947.ibm.com/support/entry/myportal/support

e. Upload all of the details and data to your support call (PMR):

Please visit this web page for instructions: https://www.secure.ecurep.ibm.com/app/upload

FEEDBACK:

The repository does not have a Release file.

При попытке выполнить

sudo apt update

password for andrei:
Ign:1 cdrom://[Debian GNU/Linux 10.4.0 _Buster_ — Official amd64 DVD Binary-1 20200509-10:26] buster InRelease
Err:2 cdrom://[Debian GNU/Linux 10.4.0 _Buster_ — Official amd64 DVD Binary-1 20200509-10:26] buster Release
Please use apt-cdrom to make this CD-ROM recognized by APT. apt-get update cannot be used to add new CD-ROMs
Err:3 http://deb.debian.org/debian buster InRelease
Cannot initiate the connection to prod.debian.map.fastly.net:80 (2a04:4e42:14::204). — connect (101: Network is unreachable)
Could not connect to prod.debian.map.fastly.net:80 (151.101.84.204), connection timed out
Cannot initiate the connection to deb.debian.org:80 (2a04:4e42:14::645). — connect (101: Network is unreachable)
Could not connect to deb.debian.org:80 (151.101.86.133), connection timed out
Err:4 http://deb.debian.org/debian buster-updates InRelease
Cannot initiate the connection to deb.debian.org:80 (2a04:4e42:14::645). — connect (101: Network is unreachable)
Err:5 http://security.debian.org/debian-security buster/updates InRelease
Cannot initiate the connection to prod.debian.map.fastly.net:80 (2a04:4e42:14::204). — connect (101: Network is unreachable)
Could not connect to prod.debian.map.fastly.net:80 (151.101.84.204), connection timed out
Cannot initiate the connection to security.debian.org:80 (2a04:4e42:c00::204). — connect (101: Network is unreachable)
Cannot initiate the connection to security.debian.org:80 (2a04:4e42:200::204). — connect (101: Network is unreachable)
Cannot initiate the connection to security.debian.org:80 (2a04:4e42:400::204). — connect (101: Network is unreachable)
Cannot initiate the connection to security.debian.org:80 (2a04:4e42:a00::204). — connect (101: Network is unreachable)
Cannot initiate the connection to security.debian.org:80 (2a04:4e42::204). — connect (101: Network is unreachable)
Cannot initiate the connection to security.debian.org:80 (2a04:4e42:800::204). — connect (101: Network is unreachable)
Cannot initiate the connection to security.debian.org:80 (2a04:4e42:600::204). — connect (101: Network is unreachable)
Cannot initiate the connection to security.debian.org:80 (2a04:4e42:e00::204). — connect (101: Network is unreachable)
Could not connect to security.debian.org:80 (151.101.0.204), connection timed out
Could not connect to security.debian.org:80 (151.101.128.204), connection timed out
Could not connect to security.debian.org:80 (151.101.192.204), connection timed out
Could not connect to security.debian.org:80 (151.101.64.204), connection timed out
Reading package lists… Done
E: The repository ‘cdrom://[Debian GNU/Linux 10.4.0 _Buster_ — Official amd64 DVD Binary-1 20200509-10:26] buster Release’ does not have a Release file.
N: Updating from such a repository can’t be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

Проверяю

souces.list

sudo vi /etc/apt/sources.list

deb cdrom:[Debian GNU/Linux 10.4.0 _Buster_ — Official amd64 DVD Binary-1 20200509-10:26]/ buster contrib main

deb http://deb.debian.org/linux/debian/ buster main
deb-src http://deb.debian.org/linux/debian/ buster main

deb http://security.debian.org/debian-security buster/updates main contrib
deb-src http://security.debian.org/debian-security buster/updates main contrib

# buster-updates, previously known as ‘volatile’
deb http://deb.debian.org/linux/debian/ buster-updates main contrib
deb-src http://deb.debian.org/linux/debian/ buster-updates main contrib

Шаг 3. Подключаемся без ввода пароля.

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

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

Операцию необходимо проводить на том компьютере, который устанавливает туннель, в нашем случае это сервер Ubuntu. Наличие подключенного туннеля необязательно. Для начала генерируем ключи аутентификации при помощи команды ‘ssh-keygen’.

Генерация сертификатов

При генерации сертификатов нет необходимости вводить кодовую фразу (passphrase), ее желательно оставить пустой. Это уменьшает безопасность в целом, но, в противном случае, кодовую фразу придется вводить каждый раз при подключении к удаленному серверу, либо выдумывать очередные грабли по обходу. Следующим шагом необходимо передать наш сертификат на удаленный сервер, т.е. на Ubuntu-VPS. Операция осуществляется всего одной командой ‘ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected]’. Где, ключ ‘-i ~/.ssh/id_rsa.pub’ указывает на публичный ключ сгенерированный ранее

Обратите внимание, что публичный и секретный ключи были сгенерированы в домашней директории пользователя, под которым и производилась генерация, в папке ‘.ssh’. Второй параметр ‘[email protected]’ определяет пользователя, под которым произойдет подключение к удаленному SSH-серверу для установки сертификата публичного ключа

При подключении придется ввести пароль этого пользователя. Соответственно сам пользователь у нас ‘vlad’ и адрес 192.168.1.16 принадлежат нашему серверу Ubuntu-VPS.

После установки сертификата можно провести проверку, работает ли сертификат. Для этого подключаемся по SSH к Ubuntu-VPS командой ‘ssh [email protected]’. Если все настроено верно, то SSH-сессия откроется без запроса пароля, и мы увидим консоль удаленной машины. Все работает, выходим из сессии SSH через ‘exit’.

Далее, необходимо добавить сгенерированный секретный ключ в агента сертификации ssh-agent. На этом этапе могут возникать различные по своей природе трудности, истинная причина которых может быть ясна далеко не всегда и с ходу. На всех моих серверах при попытке добавления сертификата секретного ключа в агента выпадает ошибка «Could not open a connection to your authentication agent».

Как правило, проблема заключается в том, что на сервере не запущен SSH-Agent и не установлена переменная среды окружения ‘SSH_AUTH_SOCK’. Без этой переменной SSH, при подключении, не знает, куда именно подключаться для получения сертификата секретного ключа. Опять же речь тут идет про сервер-инициатор создания туннеля.

Добавление сертификата в ssh-agent

Но запустить просто так агента не выйдет. В сети есть несколько вариантов того, как можно побороться с ошибкой. Мне гарантировано помогает следующий способ: запускаем сертификационного агента через команду ‘eval «$(ssh-agent)»‘. Агент запускается и устанавливает требуемую переменную окружения. После чего можно запускать и ‘ssh-add’, который добавит сертификат куда следует.

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

Вообще, после поверхностного изучения функций SSH-Agent создается впечатление, что все работает и без него, если сертификаты созданы без использования passphrase. А агент требуется как раз для того, чтобы запускать соединение SSH с сертификатом который был зашифрован при помощи кодовой фразы, но без ее ввода. При этом сам агент должен быть запущен на сервере, чтоб данный механизм сработал

PS. Вообще, после поверхностного изучения функций SSH-Agent создается впечатление, что все работает и без него, если сертификаты созданы без использования passphrase. А агент требуется как раз для того, чтобы запускать соединение SSH с сертификатом который был зашифрован при помощи кодовой фразы, но без ее ввода. При этом сам агент должен быть запущен на сервере, чтоб данный механизм сработал.

Ошибка взаимодействия с хостом

Для работы протокола SSH на этапе его инициализации генерируется общий закрытый ключ. Он создаётся на основе шифрования, которое согласуется при создании подключения между сервером и клиентом. Иногда на этом этапе возникают несоответствия и на стороне клиента это приводит к следующей ошибке:

Unable to negotiate with 123.123.123.123: no matching key exchange method found.
Their offer: diffie-hellman-group1-sha1

Эта ошибка говорит о том, что сервер и клиент друг друга «не понимают». Это может быть вызвано следующими причинами:

список шифрования сервера был изменён или сервер его не поддерживает;
различные реализации (версии) протокола SSH на сервере и у клиента.

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

$ openssh -o KexAlgorithms=+diffie-hellman-group1-sha1 root@your_server_ip

Эта проблема не такая распространённая, поскольку возникает, когда версия реализации SSH-клиента более новая, чем используемая на сервере.

Установка ПО для настройки X11 forwarding используя ssh в Unix/Linux

Для X11 forwarding-а на удаленном сервере не требуется полная система X11. Однако, серверу необходимо установить xauth. xauth — это утилита, которая поддерживает конфигурации Xauthority, используемые сервером и клиентом для аутентификации сеансов X11. Чтобы установить xauth, выполните следующие действия на удаленном сервере.

И так, выполняем команду:

# apt-get install xauth -y

Переходим к настройке.

Установка xauth в CentOS/RedHat

И так, выполняем команду:

# yum install -y xorg-x11-xauth xorg-x11-utils xorg-x11-fonts-* xorg-x11-apps xorg-x11-server-Xorg

И так, выполняем команду:

# dnf install xorg-x11-xauth

Шаг 1. Создаем SSH-туннель между серверами.

Ну, что же. Приступим. У нас есть два сервера: Ubuntu-VPS и Ubuntu. На обоих уже установлена операционная система Ubuntu Server, а заодно и OpenSSH. На сервере Ubuntu-VPS желательно создать отдельного пользователя, который по своей настройке прав будет использоваться только и исключительно как пользователь для создания туннеля SSH. Каналы SSH хоть и надежны, но в случае компрометации сервера за NAT, злоумышленник сможет получить доступ и к VPS-серверу, если устанавливать туннель под каким-либо привилегированным пользователем.

При создании тоннеля необходимо помнить, что инициируется туннелирование всегда с того сервера, что располагается за NAT. Соответственно в нашем случае мы должны создавать туннель с сервера Ubuntu. Поэтому логинимся на сервер Ubuntu и проверяем способность его подключиться к серверу Ubuntu-VPS при помощи команды ‘ssh 192.168.1.16’. Где 192.168.1.16 есть адрес сервера Ubuntu-VPS.

Подключение по SSH от сервера за NAT к удаленному серверу

Если все хорошо и подключение установлено, то выходим из него через ‘exit’ и приступаем к созданию туннеля при помощи команды ‘ssh -N -R 8080:localhost:80 [email protected]’. Где, параметр ‘-N’ означает, что после создания туннеля никакая команда на той стороне не будет выполняться. Параметр ‘-R 8080:localhost:80’ означает, что создается так называемый обратный (reverse) туннель. 8080 означает, что входной точкой туннеля на удаленном сервере (в нашем случае это 192.168.1.16 или же Ubuntu-VPS) будет выступать порт 8080. Параметр ‘localhost’ означает адрес того сервера, чей порт будет пробрасываться. В нашем случае, когда используется ресурс с самого сервера можно использовать не только ‘localhost’, но и 127.0.0.1, либо же вообще прописать доменное имя или сетевой адрес нашего сервера Ubuntu. И последний параметр ‘[email protected]’ передает имя пользователя, под которым на удаленном (Ubuntu-VPS) сервере будет создан туннель, а так же и сам адрес (или доменное имя) удаленного сервера. Напомню, что пока мы находимся на сервере Ubuntu.

Устанавливаем SSH-туннель между сервером за NAT и внешним сервером

При подключении удаленный SSH-сервер запросит ввести пароль пользователя указанного для создания туннеля (в нашем случае это vlad). А после… После ничего происходить не будет, кроме как отображение мигающего стимула командной строки. Собственно тоннель уже создан и он работоспособен. Осталось только его проверить. Для этого подключаемся к серверу Ubuntu-VPS (на сервере Ubuntu установлен Apache2 со штатным конфигом) и запускаем команду ‘wget localhost:8080’

Проверка при помощи wget доступность ресурса сервера за NAT

Если все работает, то утилита wget скачает html-страничку доступную на 8080-порту сервера Ubuntu-VPS. Это значит, что SSH-туннель уже есть и он работает! И им уже почти можно пользоваться. Если попробовать подключиться к серверу Ubuntu-VPS на порт 8080 с основной машины или же из локальной сети, то скорее всего браузер вернет ошибку подключения. Как от нее избавиться будет пояснено в шаге 2. Но если в вашей установке браузер сразу же отобразит стандартную html-страничку Apache, то можно смело переходить к шагу 3.

Небольшое замечание по поводу номера порта. Почему я выбрал на Ubuntu-VPS порт 8080, а не 80? Ответ тут прост. Конечно же, можно было бы сформировать параметр и как ’80:localhost:80′, тогда страничка открывалась бы на стандартном порту, но использование портов с номерами ниже 1024 требует администраторских прав. Но ведь мы же не хотим создавать туннель с административным пользователем? Не хотим же? В крайнем случае, можно воспользоваться переназначением портов уже на Ubuntu-VPS, например, через IPTables.

Кстати, туннель можно запускать, не занимая терминальную сессию. Для этого можно применить ключ ‘-f’. В таком случае, после подключения и ввода пароля, ssh на машине-инициаторе туннель уйдет в фон и в этой же терминальной сессии можно будет продолжать работать как и прежде. Но, данный ключик доступен не во всех версиях SSH, поэтому попробуйте обновиться, если вдруг SSH будет ругаться на неверный ключ.

Шаг 7. Прокидываем несколько портов через SSH-туннель.

При желании можно создать сразу несколько туннелей. Для этого можно просто клонировать сервисы для systemd, размножать задачи в CRON или же запускать туннели в ручном режиме с установкой флага ‘-f’.

Вместо заключения

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

Знатоки Linux автоматически посоветуют начать копать как в сторону ключа ‘-w’, так и в сторону директивы sshconfig. Но, оставлю данное упражнение для любителей залезть поглубже в тему.

Upd1.: Если запуск из-под cron не выходит, ssh-сессия завершается с ошибкой, например как-то так «ssh exited prematurely with status 255; autossh exiting», то стоит попробовать сделать три вещи:

Прописать в строку запуска autossh в cron ‘-i /home/vlad/.ssh/id_rsa’, тем самым указав программе точно, где лежит ключ (сертификат).
Дополнительно стоит попробовать указать ключ ‘-f’ сразу после autossh. При помощи этого ключа мы указываем, что сессия ssh должна запуститься в фоновом режиме.
Прописать пути ко всем зависимым директориям в crontab включая и директорию где располагаются ключи (сертификаты). В моем случае путь выглядит примерно так PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/home/vlad/.ssh

Во всех случаях выше необходимо заменить vlad на пути в ваших системах.

Полезные ссылки

Боремся с ошибкой shh-add Could not open a connection to your authentication agent. Часть 1.
Боремся с ошибкой shh-add Could not open a connection to your authentication agent. Часть 2.
Боремся с ошибкой shh-add Could not open a connection to your authentication agent. Часть 3.
Автоматическое подключение туннеля SSH при помощи AutoSSH и использование сервиса для запуска туннеля при автозагрузке.
Различия в network*.target в systemd.
Mosh – еще одна альтернатива SSH для нестабильных соединений.
О ssh-agent и ssh-add.

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

Ввод пароля для подключения через SSH — раздражающая процедура. У меня почти никогда не получалось ввести его правильно с первого раза. Поэтому я начал искать информацию о том, как подключиться к серверу через SSH без пароля. Простое и безопасное решение — использование ключа. Почему это безопаснее? Потому что пароль можно подобрать. Чтобы исключить такую вероятность, многие пользователи выбирают авторизацию с помощью ключа.

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

Генерирование ключа и подключение на Windows

Для удобства используем программу PuTTy. Вместе с ней устанавливается утилита PuTTYgen — в ней можно сгенерировать публичный и приватный ключи.

Запустите программу PuTTYgen.
Нажмите на кнопку Gengerate.
Водите курсором мышки по рабочему столу, чтобы сгенерировать случайные значения ключей.
Нажмите на кнопку Save private key, чтобы сохранить на жестком диске приватный ключ. Место хранения может быть любым — его нужно указать в параметрах PuTTY. Сделаем это позже.
Скопируйте публичный ключ в буфер обмена (Ctrl + C) и закройте генератор ключей.

Теперь нужно перенести публичный ключ на сервер. Запустите программу PuTTY и подключитесь к серверу с помощью пароля. Затем последовательно введите следующие команды:

mkdir ~/.ssh

chmod 0700 ~/.ssh

touch ~/.ssh/authorized_keys

chmod 0644 ~/.ssh/authorized_keys

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

Следующий шаг — вставка публичного ключа из буфера обмена в файл authorized_keys. Для этого используется команда cat > .ssh/authorized_keys. После ввода команды щелкните по окну терминала правой кнопкой, чтобы вставить скопированный ранее публичный ключ. Для завершения ввода нажмите на сочетание клавиш Ctrl+D.

Вернитесь в настройки PuTTY. Перейдите в раздел Connection — SSH — Auth. Нажмите на кнопку Browse и укажите путь к приватному ключу, который вы ранее сохранили на жестком диске.

Теперь для подключения к серверу через SSH пароль не нужен — достаточно указать логин и IP-адрес сервера.

Генерирование ключа и подключение на Linux и macOS

Теперь посмотрим, как подключиться через SSH ключи на Linux и macOS.

Запустите терминал на локальном компьютере.
Выполните команду ssh-keygen, чтобы сгенерировать ключи.
Нажмите на Enter, чтобы сохранить ключи.

Генератор предложит также задать кодовую фразу для ключа. Это дополнительная мера безопасности: если кто-то получит доступ к вашей локальной машине, то все равно не сможет подключиться к серверу через SSH. Минус один — вам тоже придется постоянно вводить ключевую фразу. Можно отказаться от этой меры защиты, просто нажав на клавишу Enter.

На этом процедура создания ключей завершена. Файлы d_rsa (приватный ключ) и id_rsa.pub (публичный ключ) хранятся в папке ~/.ssh/. Осталось скопировать открытую часть ключа на сервер.

Вернитесь в терминал.
Выполните команду ssh-copy-id [email protected], где root — логин для подключения к серверу по SSH, а 185.104.114.90 — IP-адрес или хост сервера.

После выполнения этой команды публичный ключ будет скопирован на сервер. Теперь вы можете подключаться к удаленной машине с помощью логина и IP-адреса — например, ssh [email protected]. Ключи будут сопоставляться автоматически.

Отключение запроса пароля

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

Подключитесь к удаленному серверу.
Выполните команду sudo nano /etc/ssh/sshd_config. Файл sshd_config откроется во встроенном текстовом редакторе.
Найдите строку PasswordAuthentication yes и измените ее на PasswordAuthentication no.
Сохраните изменения и перезапустите службу SSH командой sudo service ssh restart.

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

Использование X11 forwarding через ssh в Unix/Linux

На локальном хосте должна быть установлена система с X11, чтобы отображать удаленные программы. Для того чтобы выполнить форвардинг, выполните:

$ ssh -X remote_ssh_user@remote_server

Например:

$ ssh -X -v [email protected]

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

Можно еще опции, передавать через коммандную строку:

$ ssh -o ForwardX11=yes user_name@your_remote_server

Безопастность при использовании X11 forwarding через ssh

Обычно, не рекомендуется всегда работать с «ForwardX11 yes». Поэтому, если вы хотите использовать свои SSH-соединения с пвыщенной безопасностью, лучше всего сделать следующее:

Не прописывать «ForwardX11 yes» в ваш «$HOME/.ssh/confi»g файл.
Используйте «ForwardingX11» только когда вам это необходимо, используя «ssh -X your_user@your_server».
Если вы можете, полностью отключите «X11Forwarding» на вашем сервере.

Вот и все, статья «Настройка X11 forwarding используя ssh в Unix/Linux» завершена.

Шаг 2. Делаем доступным порт 8080 для доступа извне.

Если при установленном и работающем туннеле получить страничку Apache можно только с сервера Ubuntu-VPS, то значит в настройках сервера SSH необходимо включить доступ к пробрасываемым через тоннель портам.

Редактируем любым редактором конфигурационный файл SSH, расположенный по пути ‘/etc/ssh/sshd_config’ на Ubuntu-VPS и записываем там строчку (или убираем символ комментария #) ‘GatewayPorts yes’. Сохраняем и перезапускаем SSH-сервер командой ‘sudo service sshd restart’.

Дефолтная страничка от Apache получена с сервера посредника

После перезагрузки сервера SSH, устанавливаем туннель и пробуем зайти на Ubuntu-VPS через браузер на основном компьютере. Все работает. И на этом можно было и закончить, если бы не потребность в большей автономности и автоматизации туннеля. Поэтому двигаемся далее.