сделать ssh перенаправление порта 9999 на какой нибудь рабочий порт чтоб можно было проверить

Сделать ssh перенаправление порта 9999 на какой нибудь рабочий порт чтоб можно было проверить

Перевод: Сгибнев Михаил

Введение

Обычно SSH используется для регистрации на удаленном сервере с целью проведения технического обслуживания, чтения почты, управления сервисами и тому подобных задач администрирования. SSH также предоставляет некоторые другие сервисы, такие как копирование файлов (используя scp и sftp) и удаленное выполнение команд (используя ssh с указанием команды после имени хоста при выполнении из командной строки).

Всякий раз используя SSH для соединения одной машины с другой, мы создаем безопасный сеанс связи. Вы можете ознакомиться с другими статьями, связанными с настройкой и эксплуатированием SSH: SSH Host Key Protection, SSH User Identities и SSH and ssh-agent.

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

Предположим, что на вашей машине имеется почтовый клиент и вы получаете письма с почтового сервера по протоколу POP (Post Office Protocol), порт 110. Вы хотите защитить ваше POP соединение с целью препятствовать перехвату пароля или почты (Некоторые POP серверы поддерживают дополнительные методы авторизации, типа S/Key или обмен запросами).

В обычном случае, клиент создает сессию с портом TCP за номером 110, вводится имя пользователя и пароль и скачиваются письма. Давайте просто попробуем использовать telnet или nc: Мы можем перенаправить эту TCP-сессию внутрь SSH-сессии используя перенаправление портов. Если мы имеем доступ по SSH к машине, на которой запущен требуемый нам сервис (в нашем случае POP, порт 110), то цель близка и приятна. Также, для наших целей мы можем использовать любой SSH-сервер в сети, из которой доступен целевой почтовый сервер.

Отладка перенаправления

# для просмотра соединений. Эта последовательность работает только после символа перевода каретки, поэтому вам придется сделать так: Видим, что в системе открыта только одна SSH-сессия, используя именно ее, мы вводим текущие команды unix.

Так, а теперь попробуем выполнить команду telnet localhost 9999 и просмотрим состояние соединений: И что же мы видим? Таки туннель был создан! Мы можем воспользоваться утилитами netstat или lsof, чтобы увидеть соединение с 127.0.0.1, порт 42789 на 127.0.0.1, порт 9999.

Пример удаленного перенаправления

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

Приведем классический пример использования удаленного перенаправления.Вы весь в работе, а на выходные VPN доступ закрывается на техническое обслуживание. Однако, у вас действительно имеется очень важная работа, но вы предпочитаете делать ее дома, вместо того, что бы торчать в офисе в выходные. И по SSH к вашей рабочей машине никак не пробиться, ибо наличествует фаервол. Значит, перед уходом домой, сделаем пару движений. Ваш

Port Forwarding Cheat Sheet

Локальное перенаправление

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

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

Безопасность перенаправления портов

Перенаправление занимает порт на ssh клиенте(локальное перенаправление) или на ssh сервере (удаленное перенаправление). По умолчанию, этот порт будет доступен только на кольцевом интерфейсе 127.0.0.1, это означает, что туннель будет доступен только локальному пользователю.

Источник

Проброс портов через SSH-туннель в Windows

Чаще всего проброс портов через SSH применяется в сценариях, когда нужно подключиться к удаленному компьютеру, который защищен межсетевым экраном. Например, у вас имеется сервер c Windows, на котором открыт только SSH порт (TCP 22). Все остальные порты блокируются аппаратным межсетевым экраном или брандмауэром Windows. Ваша задача подключиться к рабочему столу этого Windows сервера с помощью клиента RDP. Казалось бы, невозможная задача, т.к. порт RDP 3389 блокируется брандмауэром. Однако вы можете воспользоваться технологией проброса портов через ssh-тунель.

Чаще всего используются следующие сценарии проброса SSH:

RDP доступ через SSH туннель (local TCP forwarding)

В этом режиме вы создаете на своем компьютере локальный TCP порт, подключения к которому перенаправляются через SSH туннель на указанный порт удаленного сервера. В этом примере мы создадим локальный порт 8888, при подключении к которому выполняется перенаправление с этого порта на RDP порт 3389 удаленного компьютера. Общая схема подключения выглядит так:

Для создания SSH туннеля с помощью встроенного SSH клиента (встроен в Windows 10 1809 и Windows Server 2019), выполните команду:

Теперь, чтобы подключится к удаленному компьютеру через SSH туннель, вам нужно подключится RDP-клиентом mstsc.exe на локальный порт 8888 своего компьютера:

Авторизуйтесь на удаленном компьютере и можете спокойно работать в RDP-сессии, при этом вы помните, что порт 3389 все еще закрыт в файерволе. С помощью TCPView вы можете убедиться, что RDP подключение установлено локально (RDP подключение инициировано запущенным локально SSH сервером).

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

В таком режиме другие компьютеры в вашей локальной сети тоже смогут подключиться к удаленному RDP серверу, даже если у них полностью заблокирован прямой доступ к удаленному серверу (как по SSH, так и по RDP). Для этого, они должны подключиться RDP клиентом к порту 8888 на вашем компьютере, на котором создан SSH туннель:

mstsc.exe /v 10.10.1.220:8888

Переброс удаленного порта на локальную машину (Remote TCP forwarding)

Есть еще один вариант применения SSH туннеля – remote TCP forwarding. Через SSH туннель вы можете открыть доступ удаленному серверу к локальному порту на вашем компьютере или порту на другом компьютере в вашей локальной сети. Например, вы хотите, чтобы внешний сервер (192.168.1.90) получил доступ к вашему Интранет сайту (не опубликованному в Интернете). Для создания обратного туннеля, используйте такую команду:

С помощью SSH туннелей вы можете строить целые цепочки для форвардинга портов. Включить или отключить SSH туннелирование можно в конфигурационном файле sshd_config директивами:

Источник

5 приемов и хитростей для работы с SSH и кое-что ещё

В этой статье мы поговорим о полезных приемах и командах при работе с SSH. А именно:

Многофакторная аутентификация

Для того, чтобы активировать ее, есть целых пять способов.

1. Обновляем OpenSSH и используем аппаратные токены. В феврале этого года в OpenSSH была добавлена поддержка токенов FIDO U2F (Universal Second Factor). Что сказать — это отлично, но есть один нюанс.

Кроме того, были добавлены два новых типа ключей — ecdsa-sk и ed25519-sk. Для них же есть и сертификаты. Для того, чтобы создать ключевые файлы, необходимо вставить токен и выполнить команду

Что она делает? Создает открытый и закрытый ключи, которые привязаны к U2F токену. Закрытый ключ на токене используется для расшифровки закрытого ключа, который хранится на диске.

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

2. Используем PIV+PKCS11 и Yubikey. В том случае, если нужно подключаться к машинам, где установлены более ранние версии SSH-сервера, есть еще одна возможность. Вот подробная инструкция U2F+SSH с PIV/PKCS11. Немного сложно, но оно стоит того.

3. Третий способ — использование yubikey-agent. Вот сам SSH-агент для Yubikeys, его создал Filipo Valsorda.

4. Touch ID и sekey. Еще один способ заключается в использовании Sekey — агента с открытым исходным кодом. Он сохраняет закрытые ключи в системе secure enclave для MacOS и дает возможность запускать функцию подписания посредством Touch ID.

5. Наконец, использование Single Sign On SSH. Вот здесь размещена инструкция по настройке. Преимущество Single Sign On SSH в том, что пользователь получает возможность использовать политику безопасности поставщика учетных записей, включая поддержку многофакторной аутентификации.

Безопасный проброс ключа (agent forwarding)

Локальный SSH-агент создает IPC-сокет, который подключается через этот канал к удаленному хосту. Это достаточно опасно, поскольку у пользователя с правами root а удаленном хосте есть доступ к локальному SSH-агенту подключившегося пользователя. Таким образом, его можно использовать для доступа к ресурсам сети от имени этого пользователя. И если работать со стандартным SSH-агентом, о проблеме не узнать. Но вот с U2F-ключом или Sekey эту проблему можно убрать.

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

Выход из подвисшей SSH-сессии

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

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

2. Разрыв сессии. ssh использует символ

в качестве управляющей последовательности по умолчанию. Команда

закрывает текущее соединение и возвращает в терминал.

Кроме того, команда

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

дважды для отправки символа.

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

Есть два варианта для сохранения сессии во время переключения между сетями.

Если нужно надежное и не закрывающееся соединение, даже во время переключения между сетями, то есть выход — нужно использовать Mosh — mobile shell. Mosh называют защищенную оболочку, которая использует SSH для инициализации сессии (handshake). После этого она переключается на собственный зашифрованный канал, который весьма стабилен. Он, например, может обрабатывать разные ситуации, включая разрывы связи, изменение IP-адреса устройства, большие лаги при передаче данных и все прочее. Все это — благодаря UDP и протоколу синхронизации, который использует Mosh.

Для работы с ним нужно, прежде всего, установить его как на сервере, так и клиенте, открыв порты с 60000 по 61000 для входящего UDP трафика на вашем удаленном хосте. После этого нужно просто набрать mosh user@server для подключения.

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

2. Использование tmux. Для того, чтобы подключаться и отключаться при необходимости, сохраняя ту же сессию на удаленном хосте, стоит использовать мультиплексор терминала, который называется tmux. В том случае, если SSH-соединение отваливается, нужно снова подключиться и набрать tmux attach. После этого пользователь возвращается в сессию tmux.

Он предлагает также несколько дополнительных функций, включая табы, панели, такие же, как в терминале macOS, плюс возможность работать с терминалом вместе с другим пользователем. Еще больше возможностей можно получить при помощи Byobu — это пакет, добавляющий большое количество удобных функций и сочетания клавиш. Он поставляется с Ubuntu, а в macOS его можно запустить при помощи Homebrew.

Расшариваем удаленный терминал

Бывают ситуации, когда необходимо расшарить SSH-сессию — например, во время решения сложных проблем с серверами. Лучший способ сделать это — tmux. Для решения задачи нужно сделать вот что:

Советы от эксперта

Перевод мы решили дополнить собственными советами — надеемся, что они тоже пригодятся. Своим полезным опытом поделился Максим Клочков, старший консультант центра сетевых решений компании «Инфосистемы Джет» и преподаватель курса «Профессия Специалист по кибербезопасности» в Skillbox.

Проброс TCP-портов

Здесь server2 — удаленный сервер, на который мы заходим по ssh, login — имя пользователя, под которым мы заходим на удаленный сервер, XXX — номер порта, который надо организовать на локальном компьютере, server1 — хост, на который надо пробросить соединение с этого порта, и наконец YYY — порт, на который надо пробросить это соединение.

Рассмотрим два примера.

Здесь server2 — удаленный сервер, на который мы заходим по ssh, login — имя пользователя, под которым мы заходим на удаленный сервер, XXX — номер порта, который надо организовать на удаленном сервере, server1 — хост, на который надо пробросить соединение с удаленного сервера, и наконец YYY — порт, на который надо пробросить это соединение.

Источник

Магия SSH

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

1) Local TCP forwarding

Начнем с простого — local TCP forwarding:

Имеем удаленный сервер «host2» с неким приложением, допустим, PostgreSQL server, которое принимает TCP-соединения на порту 5432. При этом вполне логично, что на этом сервере стоит файрвол, который прямых соединений извне на порт 5432 не разрешает, но при этом есть доступ по SSH (по-умолчанию порт 22, рекомендую его изменить). Требуется подключиться с нашего рабочего места «host1» клиентским приложением к серверу PostgreSQL на «host2».

Для этого на «host1» в консоли набираем:

Теперь на «host1» мы можем соединяться с PostgreSQL сервером через локальный порт 9999:

Мы также можем соединяться с приложением не на самом «host2», а на любой доступной ему машине:

Для этого при пробросе портов вместо «localhost» указываем имя хоста, например «host3»:

Тут важно заметить, что «host3» должен быть известен (если это имя, а не IP-адрес) и доступен для машины «host2».

Также можно через «host1» предоставить доступ любому другому узлу (назовем его «host1A») к сервису на «host3»:

Для этого нужно вставить в команду соединения ssh IP-адрес интерфейса, на котором будет поднят локальный порт 9999:

В данном примере порт 9999 будет открыт на всех доступных на «host1» IPv4 интерфейсах.

2) Remote TCP forwarding

Но что делать, если, например, «host2» не имеет белого IP-адреса, находится за NAT или вообще все входящие соединения к нему закрыты? Или, например, на «host2» стоит Windows и нет возможности поставить SSH-сервер?

Для этого случая есть Remote TCP forwarding:

Теперь нужно устанавливать ssh-соединение в обратном направлении — от «host2» к «host1». Т.е. наша административная рабочая станция будет SSH-сервером и будет доступна по SSH с «host2», а на «host2» нужно будет выполнить подключение SSH-клиентом:

Например, в PuTTy это делается так:
Идем по дереву настроек: Connection → SSH → Tunnels.
Далее в поле «Source port» вбиваем 9999, в «Destination» — localhost:5432, а ниже выбираем «Remote», и нажимаем Add.
Не забываем после этого сохранить настройки сессии, если требуется.

Также у вас возникнут дополнительные сложности с обеспечением безопасности на «host1», если вы не доверяете узлу «host2». Однако это выходит за рамки данной статьи.

И, конечно, вы каким-то образом (сами или с посторонней помощью) должны инициировать ssh-соединение со стороны «host2» вводом приведенной выше команды, а «host1» должен иметь белый IP-адрес и открытый порт SSH.

После установки ssh-соединения все работает аналогично предыдущей главе.

3) TCP forwarding chain через несколько узлов

В закрытых сетях часто бывает, что нужный нам узел напрямую недоступен. Т.е. мы можем зайти на нужный хост только по цепочке, например host1 → host2 → host3 → host4:
host1# ssh host2
host2# ssh host3
host3# ssh host4
host4# echo hello host4

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

В таком случае мы также можем делать TCP forwarding по цепочке:

Здесь порты 9991, 9992, 9993 выбраны для наглядности, на практике можно использовать один и тот же порт (например, 9999), если он свободен на всех узлах.

Итого нужно выполнить следующую цепочку команд:

После успешного выполнения перечисленных выше команд, на узлах выполняется следующее:

ВАЖНО! Все указанные на схемах стрелками соединения являются отдельными TCP-соединениями (сессиями).

4) TCP forwarding ssh-соединения

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

Таким образом, на порту 2222 на «host1» у нас теперь есть форвардинг на порт SSH (22) на «host4». Можем соединиться:

Казалось бы, зачем это нужно? Например, вот зачем:

Ну и вообще, здорово что теперь «host4» так близко 🙂

Вывод: можно делать TCP forwarding большого уровня вложенности.

Если пользуетесь одним и тем же портом (2222) для доступа к разным удаленным серверам, то будут ошибки RSA fingerprint, который остался от предыдущего сервера. Его нужно будет удалить из

5) SSH VPN Tunnel

TCP port forwarding — это отличная возможность. Но что если нам нужно больше? Доступ по UDP, доступ к множеству портов и хостов, доступ к динамическим портам? Ответ очевиден — VPN. И всемогущий SSH начиная с версии 4.3 и здесь придет нам на помощь.

Забегая вперед скажу: этот функционал SSH хорошо работает если вам нужно временное решение для каких-то административных задач. Для построения постоянных VPN этот вариант далеко не самый подходящий, т. к. он предполагает TCP-over-TCP, что плохо скажется на скорости соединения.

Настройка SSH-сервера:
PermitTunnel в настройках sshd по-умолчанию выключен, его нужно включить в /etc/ssh/sshd_config:
PermitTunnel yes
или
PermitTunnel point-to-point

ВАЖНО: для поднятия нового сетевого интерфейса туннеля и на ssh-клиенте, и на ssh-сервере необходимы права суперпользователя. Можно долго спорить о том, насколько это небезопасно, но в большинстве случаев на ssh-сервере достаточно настройки:

Таким образом вы запрещаете вход root по паролю, а разрешаете только другими средствами, например, по ключу RSA, что гораздо безопаснее.

Перезапускаем sshd:
sudo service sshd restart # centos
или
/etc/init.d/ssh restart # (debian/ubuntu)

host1# ifconfig tun5
tun5 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
POINTOPOINT NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

Назначаем интерфейсам IP-адреса и поднимаем их:

host1# sudo ifconfig tun5 192.168.150.101/24 pointopoint 192.168.150.102
host2# sudo ifconfig tun5 192.168.150.102/24 pointopoint 192.168.150.101

Если есть файрвол, не забываем разрешить соединения с интерфейса tun5:

На host1 это делать необязательно, здесь это сделано лишь для того чтобы ping работал в обе стороны.

host1# ping 192.168.150.102
host2# ping 192.168.150.101

Если рассмотреть более ранний пример с PostgreSQL, то теперь схема будет такая:

А команда для подключения к серверу PostgreSQL будет выглядеть так:

Ну а далее можно делать какой-либо из этих узлов шлюзом, если нужно обеспечить доступ не к одному узлу, а к сети. Например:

host1# # Предположим, у host2 есть доступ к сети 192.168.2.x, куда нам нужно попасть с host1
host1# # Прописываем host2 как шлюз в сеть 192.168.2.x
host1# sudo ip route add 192.168.2.0/24 via 192.168.150.2
host1# # Наслаждаемся доступом в сеть с host1
host1# ping 192.168.2.1

После окончания работы не забываем вернуть net.ipv4.ip_forward и файрвол в исходное состояние.

host1# sudo iptables-restore

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

Допустим, есть доступ по ssh с вашей рабочей машины host1 на сервер host2, с него — на host3, а уже оттуда — на нужный вам host4. Тогда делаем TCP forwarding для ssh (если с host1 вы сразу можете соединиться с host4, пропустите этот шаг):

Далее, соединяемся с host4 и поднимаем интерфейс tun5:

Смотрим таблицу маршрутизации на host4, допустим видим следующее:

ВАЖНО! Далее нам скорее всего захочется сделать маршрутом по-умолчанию интерфейс tun5 со шлюзом 192.168.150.101, через который будет доступен Интернет. Поэтому на данном этапе важно точно знать, какие маршруты нужно дописать, чтобы заменить маршрут по-умолчанию. Это важно, поскольку довольно часто маршруты на отдельные сети не прописывают отдельно, а просто задают маршрут по-умолчанию (0.0.0.0/0) со шлюзом, через который и идет весь межсетевой трафик. Более того, вполне вероятно что ваше ssh-соединение с сервером также использует исходный шлюз по-умолчанию.

Для простоты в данном примере предположим, что никаких маршрутов кроме 192.168.56.0/24 серверу для нормального функционирования не нужно и что предыдущий ssh-хост host3 имеет IP-адрес из этой же сети.

Настраиваем наш host1 для работы в качестве шлюза в Интернет для host4:

Изменяем маршрут по-умолчанию на host4 (ОСТОРОЖНО, см. предупреждение выше!):

Если весь Интернет нам не нужен, а только конкретные IP-адреса/маски, то можно маршрут по-умолчанию не менять, а дописать только нужные нам адреса через шлюз на tun5.

Проверяем, что есть Интернет:

Отлично. Осталось настроить DNS. Есть множество способов это сделать, проще всего отредактировать файл /etc/resolv.conf и добавить туда строчки:

nameserver 8.8.8.8
nameserver 8.8.4.4

После этого Интернет должен быть полностью доступен:

После окончания работы не забываем вернуть все в исходное состояние:

host1# # восстанавливаем правила файрвола на host1
host1# sudo iptables-restore

host2# # восстановите маршрут по-умолчанию на host4:
host2# sudo ip route replace default via 192.168.56.254
host2# # и уберите добавленные ранее DNS-сервера из /etc/resolv.conf

6) Коротко о беспарольном доступе

Думаю, все уже знают что авторизация по паролю это не про нас. Но на всякий случай впихну сюда краткую инструкцию по настройке аутентификации по ключу RSA:

1. На клиентских машинах генерируем пользователю свой ключ RSA:

По-умолчанию приватный ключ сохраняется в

/.ssh/id_rsa, а открытый — в

/.ssh/id_rsa.pub. Приватный ключ храните как зеницу ока и никому не давайте, никуда не копируйте.
При создании ключа можно задать пароль (passphrase), которым ключ будет зашифрован.

2. Клиентские открытые ключи нужно сохранить на ssh-сервере в файле

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

Где user — имя пользователя на сервере, sshserver — имя или IP-адрес ssh-сервера.

/.ssh/authorized_keys на ssh-сервере необходимо задать следующие права:
chmod 0700

3. Проверьте, что можете зайти на сервер по ключу, без ввода пароля (не путать с passphrase):
ssh user@sshserver
Рекомендую не закрывать хотя бы одну активную ssh-сессию с сервером до тех пор, пока окончательно не закончите настройку и не убедитесь что все работает.

4. Отключите на SSH-сервере возможность входа по паролю в файле /etc/ssh/sshd_config:

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

Я обычно также отключаю две следующие опции:

GSSAPIAuthentication no
UseDNS no

В некоторых случаях это позволяет ускорить процесс соединения (например, когда на сервере нет доступа в Интернет).

5. Перезапустите sshd:
service sshd restart
или
/etc/init.d/ssh restart

Источник