Ssh порт какой: Как SSH появился на 22 порту / Хабр

Содержание

Как SSH появился на 22 порту / Хабр

SSH по умолчанию работает на порту 22. Это не совпадение. Вот история, как ему достался этот порт.

Когда я (Тату Илонен) впервые опубликовал эту историю в апреле 2017 года, она стала вирусной: её прочитали около 120 000 читателей за три дня.

Я написал первую версию SSH (Secure Shell) весной 1995 года. В то время широко использовались Telnet и FTP.

Но я всё равно разработал SSH для замены и telnet (порт 23) и ftp (порт 21). Порт 22 был свободен и удобно располагался между портами для telnet и ftp. Я подумал, что такой номер порта может стать одной из тех маленьких деталей, которые придадут некоторую ауру доверия SSH. Но как его получить? Я никогда не распределял порты, но я знал тех, кто этим занимается.

В то время процесс выделения портов был довольно простым. Интернет был меньше, и мы находились на самых ранних стадиях интернет-бума. Номера портов выделяла организация IANA (Internet Assigned Numbers Authority). В то время это означало уважаемых первопроходцев интернета Джона Постела и Джойс К. Рейнольдс. Среди всего прочего, Джон являлся редактором таких незначительных протоколов, как IP (RFC 791), ICMP (RFC 792) и TCP (RFC 793). Возможно, кто-то из вас слышал о них.

Меня откровенно пугал Джон как автор всех основных RFC для Интернета!

Так или иначе, но перед анонсом ssh-1.0 в июле 1995 года я отправил в IANA такое электронное письмо:

From ylo Mon Jul 10 11:45:48 +0300 1995

From: Tatu Ylonen <[email protected]>

To: Internet Assigned Numbers Authority <[email protected]>

Subject: request for port number

Organization: Helsinki University of Technology, Finland
Уважаемый сэр,
Я написал программу для безопасного входа с одной машины на другую по небезопасной сети. Это значительное улучшение безопасности по сравнению с существующими протоколами telnet и rlogin и их реализациями. В частности, она предотвращает спуфинг IP, DNS и маршрутизации. Мой план состоит в том, чтобы свободно распространять программу в интернете и обеспечить как можно более широкое её использование.
Я хотел бы получить зарегистрированный привилегированный номер порта для программы. Желательно в диапазоне 1-255, чтобы его можно было использовать в поле WKS на нейм-серверах.
Ниже прикладываю проект RFC для протокола. Программное обеспечение локально используется несколько месяцев и готово для публикации, за исключением номера порта. Если можно оперативно присвоить номер порта, я хотел бы выложить программу уже на этой неделе. В настоящее время в бета-тестировании я использую порт 22. Было бы отлично использовать этот номер (в настоящее время в списках он обозначен как «неприсвоенный»).
Название сервиса для программного обеспечения — «ssh» (Secure Shell).
С уважением,
Тату Илонен <[email protected]>
… затем следуют спецификации протокола ssh-1.0

На следующий день в почтовом ящике лежало письмо от Джойс:

Date: Mon, 10 Jul 1995 15:35:33 -0700

From: [email protected]

To: [email protected]

Subject: Re: request for port number

Cc: [email protected]
Тату,
Мы присвоили порт 22 для SSH, указав вас контактным лицом.
Джойс

У нас получилось! Теперь у SSH порт 22!!!

12 июля 1995 года в 2:32 утра я анонсировал окончательную бета-версию для своих бета-тестеров в Хельсинкском технологическом университете. В 17:23 выслал тестерам пакеты ssh-1.0.0, а в 17:51 отправил объявление о SSH (Secure Shell) в список рассылки [email protected]. Я также продублировал анонс в несколько новостных групп, списков рассылки и непосредственно отдельным людям, которые обсуждали смежные темы в интернете.

По умолчанию сервер SSH по-прежнему работает на порту 22. Однако бывает иначе. Одна из причин — тестирование. Другая — запуск нескольких конфигураций на одном хосте. Редко бывает, что сервер работает без рутовых привилегий, в этом случае он должен размещаться на непривилегированном порту (т. е. с номером 1024 или больше).

Номер порта можно настроить, изменив директиву Port 22 в /etc/ssh/sshd_config. Он также указывается параметром -p <port> в sshd. Клиент SSH и программы sftp тоже поддерживают параметр -p <port>.

Параметр -p <port> можно использовать для указания номера порта при подключении с помощью команды ssh в Linux. В SFTP и scp используется параметр -P <port> (примечание: заглавная P). Указание из командной строки переопределяет любое значение в файлах конфигурации.
SSH является одним из немногих протоколов, которому часто разрешено работать через файрволы на исходящий доступ, особенно в небольших и технических компаниях. Входящий SSH обычно разрешён к одному или нескольким серверам.

Исходящий SSH

Настройка исходящего SSH в файрволе очень проста. Если есть ограничения на исходящий трафик вообще, просто создайте правило, разрешающее исходящие соединения по порту TCP 22. Вот и всё. Если требуется ограничить адреса назначения, можно создать соответствующее правило, разрешив доступ только к серверам вашей организации в облаке или к jump-серверу, который защищает доступ к облаку.

Обратное туннелирование — это риск

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

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

Но обычно туннелирование нарушает политику безопасности и отнимает контроль у администраторов файрвола и команды ИБ. Например, оно может нарушать правила PCI, HIPAA или NIST SP 800-53. Его могут использовать хакеры и спецслужбы, чтобы оставить бэкдоры в локальной сети.

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

Входящий SSH

Для входящего доступа есть несколько вариантов:

Настройте файрвол для пересылки всех подключений к порту 22 на определённый IP-адрес во внутренней сети или DMZ. Запустите по этому IP-адресу CryptoAuditor или jump-сервер, чтобы контролировать и проверять дальнейший доступ в организацию.

Используйте разные порты на файрволе для доступа к разным серверам.

Разрешайте доступ по SSH только после входа в систему с помощью VPN, обычно по протоколу IPsec.

Iptables — это файрвол хоста, встроенный в ядро Linux. Обычно он настроен для защиты сервера, предотвращая доступ ко всем портам, которые не были явно открыты.

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

iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Если хотите сохранить правила навсегда, то в некоторых системах это можно сделать командой:

service iptables save

22 порт SSH переносить или нет / Хабр

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

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

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

Кроме ключей рекомендована, достаточно длинная кодовая фраза для Ваших ключей из случайных символов в разном регистре и цифр, как минимум.

Brute force attacks — давайте кратко посмотрим, что происходят, если Ваш хост атакуется целенаправленно.

1 этап — сбор информации о хосте, в том числе и открытых портах

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

2 этап — попытки получить доступ к системе через взлом SSH

Для взлома используются ботнеты с тысячами адресов и сканирование в простом случае идет, чтобы обходить установки по умолчанию Fail2ban с сотен и тысяч адресов, при серьезном сканировании с учетом настроек системы защиты жертвы. Fail2Ban здесь также бесполезен, особенно если SSH находится на 22 порту и настройки Fail2Ban оставлены по дефолту.

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

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

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

Что касается смены стандартного порта, есть свежий обзор BestPractic по обеспечению безопасности SSH, там смена стандартного порта стоит 8 пунктом, авторизация по ключам стоит первым пунктом и установка Fail2ban или аналогов 10 пункт. Top 20 OpenSSH Server Best Security Practices.

Перевод порта SSH на нестандартный позволяет использовать стандартные порты как ловушку для отслеживания попыток сканирования, и блокировать полученные IP адреса на длительное время и по всем портам, это 11 пункт, в статье BestPractic. Естественно необходимо указывать белые адреса чтобы не получить случайную блокировку это 7 и 8 пункты в статье BestPractic.

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

Смена порта SSH-сервера как мера защиты от брутфорса

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

В этой статье мы опишем, как сконфигурировать SSH-сервер на альтернативном порту.

Особо отметим, что не стоит воспринимать описанный здесь метод, как панацею. Китайская мудрость гласит — «Security by Obscurity is no Security at all». Не забывайте и про другие методы защиты SSH, такие как правильная настройка межсетевого экрана, разрешение доступа только ограниченному набору IP-адресов, отказ от парольной аутентификации и использование ключей RSA/DSA, и т.п.

Конфиг SSH-сервера обычно располагается в /etc/ssh/sshd_config. Для редактирования этого файла вам потребуются привилегии суперпользователя root, или возможность выполнить sudo для получения таких привилегий текстовым редактором.

Выполните команду, например:

nano /etc/ssh/sshd_config

В открывшемся файле найдите следующую строку:

Port 22

Закомментируйте её и добавьте новую строку со случайным номером порта, например 58291. Номер порта не должен превышать 65535. Также удостоверьтесь, что выбранное вами значение не конфликтует с другими сервисами в системе, например mysqld использует порт 3306, httpd — 80, ftpd — 21. Рекомендуем выбрать пятизначное значение.

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

netstat -tupln | grep LISTEN

После модификации, участок файла конфигурации SSH должен выглядеть примерно так:

#Port 22
Port 58291

Что-бы SSH-сервер начал слушать новый порт вместо прежнего, его нужно перезапустить:

/etc/init.d/ssh restart

или

/etc/init.d/sshd restart

Соединение с SSH-сервером на альтернативном порту

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

ssh putty.org.ru
ssh: connect to host putty.org.ru port 22: Connection refused

Вместо этого вы должны передать SSH-клиенту номер порта значением параметра -p, примерно так:

ssh -p 58291 putty.org.ru

Теперь соединение пройдёт успешно.

Если вы используете свободный SSH-клиент PuTTY, то укажите порт в настройках сессии, как показано на картинке:

Команда SSH | ИТ Блог. Администрирование серверов на основе Linux (Ubuntu, Debian, CentOS, openSUSE)

Secure Shell (SSH) – это криптографический сетевой протокол, используемый для шифрованного соединения между клиентом и сервером. Клиент ssh создает защищенное соединение с сервером SSH на удаленной машине. Зашифрованное соединение может использоваться для выполнения команд на сервере, туннелирования X11, переадресации портов и многого другого.

Есть ряд SSH-клиентов, доступных как бесплатных, так и коммерческих, при этом OpenSSH является наиболее широко используемым клиентом. Он доступен на всех основных платформах, включая Linux, OpenBSD, Windows, macOS и другие.

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

Клиентская программа OpenSSH вызывается ssh и может быть вызвана из терминала. Клиентский пакет OpenSSH также предоставляет другие утилиты SSH, такие как scp и sftp, которые устанавливаются вместе с командой ssh.

Клиент OpenSSH по умолчанию предустановлен в большинстве дистрибутивов Linux. Если в вашей системе не установлен клиент ssh, вы можете установить его с помощью менеджера пакетов вашего дистрибутива.

sudo apt update
sudo apt install openssh-client

sudo dnf install openssh-clients

Большинство пользователей Windows используют Putty для подключения к удаленному компьютеру через SSH. Однако последние версии Windows 10 включают в себя клиент и сервер OpenSSH. Оба пакета могут быть установлены через графический интерфейс или PowerShell.

Чтобы найти точное имя пакета OpenSSH, введите следующую команду:

Get-WindowsCapability -Online | ? Name -like 'OpenSSH*'

Команда должна вернуть что-то вроде этого:

Name  : OpenSSH.Client~~~~0.0.1.0
State : NotPresent
Name  : OpenSSH.Server~~~~0.0.1.0
State : NotPresent

Как только вы узнаете имя пакета, установите его, выполнив:

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

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

Path          :
Online        : True
RestartNeeded : False

MacOS поставляется с клиентом OpenSSH, установленным по умолчанию.

Следующие требования должны быть выполнены, чтобы иметь возможность войти в удаленный компьютер через SSH:

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

Основной синтаксис команды ssh следующий:

ssh [OPTIONS] [USER@]:HOST

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

ssh ssh.andreyex.ru

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

The authenticity of host 'ssh.andreyex.ru (192.168.121.111)' can't be established.
ECDSA key fingerprint is SHA256:Vybt22mVXuNuB5unE++yowF7lgA/9/2bLSiO3qmYWBY.
Are you sure you want to continue connecting (yes/no)?

Каждый хост имеет уникальный отпечаток, который хранится в файле ~/.ssh/known_hosts.

Введите yes для хранения удаленного отпечатка, и вам будет предложено ввести пароль.

Warning: Permanently added 'ssh.andreyex.ru' (ECDSA) to the list of known hosts.

[email protected]'s password:

После того, как вы введете пароль, вы войдете на удаленный компьютер.

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

ssh username@hostname

Имя пользователя также можно указать с помощью опции -l:

ssh -l username hostname

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

Чтобы подключиться к порту не по умолчанию, используйте опцию -p для указания порта:

ssh -p 5522 username@hostname

Если вы испытываете проблемы с аутентификацией или соединением, используйте опцию -v, чтобы сказать ssh для печати отладочных сообщений:

ssh -v username@hostname

Чтобы увеличить уровень детализации, используйте -vv или -vvv.

Команда ssh принимает несколько вариантов.

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

Клиент OpenSSH считывает параметры, установленные в файле конфигурации для каждого пользователя ( ~/.ssh/config). В этом файле вы можете хранить различные параметры SSH для каждого удаленного компьютера, к которому вы подключаетесь.

Пример конфигурации SSH показан ниже:

Host dev
    HostName dev.andreyex.ru
    User mike
    Port 4422

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

ssh -p 4422 [email protected]

Для получения дополнительной информации проверьте статью о файле конфигурации SSH.

Аутентификация с открытым ключом

Протокол SSH поддерживает различные механизмы аутентификации.

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

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

Если у вас уже нет пары ключей SSH на вашем локальном компьютере, вы можете сгенерировать ее, набрав:

ssh-keygen -t rsa -b 4096 -C "[email protected]"

Вам будет предложено ввести безопасную фразу-пароль. Хотите ли вы использовать фразу-пароль, решать только вам.

Получив пару ключей, скопируйте открытый ключ на удаленный сервер:

ssh-copy-id username@hostname

Введите пароль удаленного пользователя, и открытый ключ будет добавлен в файл authorized_keys удаленного пользователя.

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

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

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

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

Существует три типа переадресации портов SSH:

Переадресация локального порта позволяет переадресовать соединение с клиентского хоста на хост сервера SSH, а затем на порт хоста назначения.

Чтобы создать локальную переадресацию портов, передайте опцию -L клиенту ssh:

ssh -L [LOCAL_IP:]LOCAL_PORT:DESTINATION_HOST:DESTINATION_PORT -N -f username@hostname

Опция -f указывает команде ssh запускаться в фоновом режиме, а -N – не выполнять удаленную команду.

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

Опция -L указывает ssh создать перенаправление на удаленный порт:

ssh -R [REMOTE:]REMOTE_PORT:DESTINATION:DESTINATION_PORT -N -f username@hostname

Динамическая переадресация портов создает прокси-сервер SOCKS, который обеспечивает связь через ряд портов.

Чтобы создать динамическую переадресацию портов (SOCKS), передайте опцию -D клиенту ssh:

ssh -R [LOCAL_IP:]LOCAL_PORT  -N -f username@hostname

Для подключения к удаленному серверу через SSH используйте команду ssh, за которой следуют имя удаленного пользователя и имя хоста (ssh username@hostname).

Знание того, как использовать команду ssh, необходимо для управления удаленным сервером.

Если у вас есть какие-либо вопросы, пожалуйста, оставьте комментарий ниже.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Магия SSH / Хабр

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

Оглавление:

1) Local TCP forwarding

2) Remote TCP forwarding

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

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

5) SSH VPN Tunnel

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

7) Спасибо (ссылки)

1) Local TCP forwarding

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

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

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

host1# ssh -L 9999:localhost:5432 host2

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

host1# psql -h localhost -p 9999 -U postgres

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

Как это работает

После успешного подключения к SSH-серверу на «host2», на «host1» SSH-клиент начинает слушать порт 9999. При подключении к порту 9999 на «host1», SSH-сервер на «host2» устанавливает соединение с localhost (коим и является для себя самого «host2») на порт 5432 и передает по этому соединению данные, принятые ssh-клиентом на «host1» на порт 9999.

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

Настройка SSH-сервера

Port forwarding, как правило, уже включен в настройках sshd по-умолчанию.

/etc/ssh/sshd_config:
AllowTcpForwarding yes

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

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

host1# ssh -L 9999:host3:5432 host2

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

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

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

ssh -L 0.0.0.0:9999:host3:5432 host2

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

2) Remote TCP forwarding

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

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

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

ssh -R 9999:localhost:5432 host1

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

Как это работает

После успешного подключения, на «host1» SSH-сервер начинает слушать порт 9999. При подключении к порту 9999 на «host1», SSH-клиент на «host2» устанавливает соединение с localhost (коим и является для себя самого «host2») на порт 5432 и передает по этому соединению данные, принятые ssh-сервером на «host1» на порт 9999.

Также у вас возникнут дополнительные сложности с обеспечением безопасности на «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), если он свободен на всех узлах.

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

host1# ssh -L 9991:localhost:9992 host2 host2# ssh -L 9992:localhost:9993 host3 host3# ssh -L 9993:localhost:5432 host4

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

на «host1»: открывается порт 9991, при подключении к которому данные перенаправляются по ssh-соединению на порт 9992 на «host2»;

на «host2»: открывается порт 9992, при подключении к которому данные перенаправляются по ssh-соединению на порт 9993 на «host3»;

на «host3»: открывается порт 9993, при подключении к которому данные перенаправляются по ssh-соединению на порт 5432 на «host4»;

Таким образом, при соединении на порт 9991 на «host1», данные перенаправляются по цепочке на «host4» на порт 5432.

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

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

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

host1# ssh -L 2222:localhost:2222 host2 host2# ssh -L 2222:host4:22 host3

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

host1# ssh -p 2222 localhost host4# echo hello host4

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

# копируем файл на host4 host1# scp -P 2222 /local/path/to/some/file localhost:/path/on/host4 # копируем файл с host4 host1# scp -P 2222 localhost:/path/on/host4 /local/path/to/some/file # делаем еще один замечательный TCP forwarding на host4 host1# ssh -p 2222 -L 9999:localhost:5432 localhost host1# psql -h localhost -p 9999 -U postgres # обратите внимание, что порт для команды ssh задается ключем -p в нижнем регистре, # а для команды scp -P в верхнем регистре

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

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

Замечания про RSA fingerprintВ некоторых случаях scp не отработает, пока не зайдете сначала через ssh -p 2222 localhost и не примете RSA fingerprint удаленного сервера.

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

5) SSH VPN Tunnel

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

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

Еще про TCP forwardingА вот TCP port forwarding с помощью SSH, если его достаточно, во многих случаях выиграет по производительности у VPN, т. к. при TCP port forwarding передаются только данные приложения, а не исходные пакеты целиком вместе с заголовками, см. ссылку: http://blog.backslasher.net/ssh-openvpn-tunneling.html

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

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

PermitRootLogin without-password

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

Перезапускаем sshd:
sudo service sshd restart # centos

или
/etc/init.d/ssh restart # (debian/ubuntu)

Туннель поднимается при использовании магического ключа -w:

host1# sudo ssh -w 5:5 root@host2

Где 5:5 — номер интерфейса на локальной машине и на удаленной соответственно. Здесь вас может смутить, что ifconfig не выдаст в списке интерфейса «tun5». Это потому что он в состоянии «down», а вот если вызвать «ifconfig -a» или «ifconfig tun5», то интерфейс будет виден:

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# # сохраняем исходные правила файрвола host1# sudo iptables-save > /tmp/iptables.rules.orig host1# sudo iptables -I INPUT 1 -i tun5 -j ACCEPT host2# # сохраняем исходные правила файрвола host2# sudo iptables-save > /tmp/iptables.rules.orig host2# sudo iptables -I INPUT 1 -i tun5 -j ACCEPT

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

Наслаждаемся пингом:

host1# ping 192.168.150.102 host2# ping 192.168.150.101

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

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

host1# psql -h 192.168.150.102 -U postgres

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

host2# # разрешаем IP forwarding host2# sudo sysctl -w net.ipv4.ip_forward=1 host2# # разрешаем IP forwarding с host1 host2# sudo iptables -I FORWARD 1 -s 192.168.150.101 -j ACCEPT host2# # разрешаем IP forwarding на host1 host2# sudo iptables -I FORWARD 1 -d 192.168.150.101 -j ACCEPT host2# # маскируем IP адрес host1 host2# sudo iptables -t nat -A POSTROUTING -s 192.168.150.101 -j MASQUERADE

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 < /tmp/iptables.rules.orig host2# sudo iptables-restore < /tmp/iptables.rules.orig

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

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

host1# ssh -L 2222:localhost:2222 host2 host2# ssh -L 2222:host4:22 host3

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

host1# sudo ssh -p 2222 -w 5:5 root@localhost host1# # или если host4 доступен сразу: sudo ssh -w 5:5 root@host4 host1# sudo ifconfig tun5 192.168.150.101/24 pointopoint 192.168.150.102 host4# sudo ifconfig tun5 192.168.150.102/24 pointopoint 192.168.150.101

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

host4# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.150.0 0.0.0.0 255.255.255.0 U 0 0 0 tun5 192.168.56.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0 0.0.0.0 192.168.56.254 0.0.0.0 UG 0 0 0 eth0

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

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

Запоминаем и записываем куда-нибудь исходную маршрутную таблицу со шлюзом по-умолчанию:
host4# route -n > routes.orig

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

host1# # разрешаем IP forwarding host1# sudo sysctl -w net.ipv4.ip_forward=1 host1# # сохраняем исходные правила файрвола host1# sudo iptables-save > /tmp/iptables.rules.orig host1# # разрешаем IP forwarding с host4 host1# sudo iptables -I FORWARD 1 -s 192.168.150.102 -j ACCEPT host1# # разрешаем IP forwarding на host4 host1# sudo iptables -I FORWARD 1 -d 192.168.150.102 -j ACCEPT host1# # маскируем IP адрес host4 host1# sudo iptables -t nat -A POSTROUTING -s 192.168.150.102 -j MASQUERADE

На всякий случай можно прописать серые сети на шлюз из текущего маршрута по-умолчанию

Если не прописаны:
sudo ip route add 192.168.0.0/16 via 192.168.56.254 sudo ip route add 10.0.0.0/8 via 192.168.56.254 sudo ip route add 172.16.0.0/12 via 192.168.56.254

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

host4# sudo ip route replace default via 192.168.150.101 host4# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.150.0 0.0.0.0 255.255.255.0 U 0 0 0 tun5 192.168.56.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0 0.0.0.0 192.168.150.101 0.0.0.0 UG 0 0 0 tun5

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

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

host4# ping 8.8.8.8

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

nameserver 8.8.8.8 nameserver 8.8.4.4

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

host4# ping ya.ru

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

host1# # восстанавливаем правила файрвола на host1 host1# sudo iptables-restore < /tmp/iptables.rules.orig host1# # не забудьте восстановить также значение net.ipv4.ip_forward

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

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

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

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

client1# ssh-keygen -t rsa

По-умолчанию приватный ключ сохраняется в ~/.ssh/id_rsa, а открытый — в ~/.ssh/id_rsa.pub. Приватный ключ храните как зеницу ока и никому не давайте, никуда не копируйте.

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

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

ssh-copy-id user@sshserver

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

Права на файл ~/.ssh/authorized_keysUPD от sabio: В случае ручного создания файла ~/.ssh/authorized_keys на ssh-сервере необходимо задать следующие права:
chmod 0700 ~/.ssh chmod 0600 ~/.ssh/authorized_keys

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

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

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

PasswordAuthentication no

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

PubkeyAuthentication yes

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

GSSAPIAuthentication no UseDNS no

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

5. Перезапустите sshd:
service sshd restart

или
/etc/init.d/ssh restart

В случае ошибок полезно бывает смотреть лог /var/log/secure либо использовать опции -v, -vv или -vvv для вывода детального лога соединения:
ssh -vvv user@sshserver

7) Спасибо (ссылки)

help.ubuntu.com/community/SSH_VPN
habrahabr.ru/post/87197
blog.backslasher.net/ssh-openvpn-tunneling.html

Как подключиться к серверу по SSH?

SSH-протокол (англ. Secure Shell ) используется для безопасного удалённого управления операционной системой. По SSH можно подключиться к любому серверу с операционной системой семейства Linux.

Если на вашем сервере установлена ОС Windows Server — используйте подключение по RDP.

Где найти доступы к серверу

Для подключения по SSH потребуется указать IP-адрес, пароль и логин администратора сервера. Эти данные можно найти на почте, привязанной к аккаунту (после активации VDS приходит письмо с инструкцией) или в Личном кабинете — в разделе «Товары» откройте подраздел «Виртуальные серверы» — выберите сервер в списке, сверху «Инструкция».

В новой вкладке откроется страница с необходимой информацией.

Как подключиться по SSH с компьютера на ОС Windows

Если на вашем компьютере установлена ОС Windows, а на сервере — UNIX-подобная система (например, Ubuntu, Debian, CentOS и др.), то для установки SSH-соединения можно использовать PuTTY. Это бесплатная программа под Windows состоит из одного запускаемого файла и не требует установки.

Чтобы установить соединение при помощи PuTTY, необходимо проделать следующие действия:

0. Скачайте нужную версию PuTTY по ссылке
1. Запустите файл putty.exe. Откроется окно программы:

По умолчанию никаких настроек программы менять не нужно. Достаточно убедиться, что указан порт Port 22 и тип соединения Connection type — SSH.

2. В поле Host Name (or IP address) введите IP-адрес сервера. Нажмите кнопку Open.

Может появиться предупреждение системы безопасности PuTTY — оно срабатывает при подключении к новому серверу. Нажмите Да — и соединение продолжится.

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

4. В следующей строке введите пароль пользователя. При вводе пароля символы в командной строке не отображаются: можно набрать пароль вслепую или вставить кликом правой кнопки мыши, предварительно скопировав (Ctrl+C) его из инструкции. После ввода нажмите клавишу Enter. Если имя пользователя или пароль указаны неправильно, выведется ошибка «Access denied». В случае успешного подключения откроется командная строка виртуального сервера.

Как подключиться к серверу по SSH с компьютера на Linux/MacOS

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

В операционных системах семейства Linux (Ubuntu и др.) его можно открыть сочетанием клавиш Ctrl+Alt+T.

В MacOS приложение Терминал можно найти через Spotlight (иконка поиска в правом верхнем углу экрана).

Подключиться к виртуальному серверу по SSH можно одной командой:

ssh username@ip_adress

где вместо username нужно указать логин пользователя, вместо ip-adress — IP-адрес сервера, к которому вы подключаетесь. Если на сервере используется нестандартный порт SSH, команда изменится:

ssh username@ip_adress -p 22

где 22 — порт, по которому будет произведено подключение по SSH.

После ввода команды система запросит подтверждение подключения (необходимо ввести yes и нажать Enter) и пароль пользователя. После ввода нажмите клавишу Enter — откроется SSH-соединение:

Практические советы, примеры и туннели SSH / Хабр

Практические примеры SSH, которые выведут на новый уровень ваши навыки удалённого системного администратора. Команды и советы помогут не только использовать SSH, но и более грамотно перемещаться по сети.

Знание нескольких трюков ssh полезно любому системному администратору, сетевому инженеру или специалисту по безопасности.

Практические примеры SSH

SSH socks-прокси

Туннель SSH (переадресация портов)

SSH-туннель на третий хост

Обратный SSH-туннель

Обратный прокси SSH

Установка VPN по SSH

Копирование ключа SSH (ssh-copy-id)

Удалённое выполнение команд (неинтерактивно)

Удалённый перехват пакетов и просмотр в Wireshark

Копирование локальной папки на удалённый сервер по SSH

Удалённые приложения GUI с переадресацией SSH X11

Удалённое копирование файлов с помощью rsync и SSH

SSH через сеть Tor

SSH к инстансу EC2

Редактирование текстовых файлов с помощью VIM через ssh/scp

Монтирование удалённого SSH как локальной папки с SSHFS

Мультиплексирование SSH с помощью ControlPath

Потоковое видео по SSH с помощью VLC и SFTP

Двухфакторная аутентификация

Прыжки по хостам с SSH и -J

Блокировка попыток брутфорса SSH с помощью iptables

SSH Escape для изменения переадресации портов

Разбор командной строки SSH

В следующем примере используются обычные параметры, часто встречающиеся при подключении к удалённому серверу SSH.

localhost:~$ ssh -v -p 22 -C neo@remoteserver

-v: вывод отладочной информации особенно полезен при анализе проблем аутентификации. Можно использовать несколько раз для вывода дополнительной информации.

- p 22: порт для подключения к удалённому серверу SSH. 22 не обязательно указывать, потому что это значение по умолчанию, но если протокол на каком-то другом порту, то указываем его с помощью параметра -p. Порт прослушивания указывается в файле sshd_config в формате Port 2222.

-C: сжатие для соединения. Если у вас медленный канал или вы просматриваете много текста, это может ускорить связь.

neo@: строка перед символом @ обозначает имя пользователя для аутентификации на удалённом сервере. Если не указать его, то по умолчанию будет использоваться имя пользователя учётной записи, в которую вы вошли в данный момент (~$ whoami). Пользователя также можно указать параметром -l.

remoteserver: имя хоста, к которому подключается ssh, это может быть полное доменное имя, IP-адрес или любой хост в локальном файле hosts. Для подключения к хосту, который поддерживает и IPv4, и IPv6, можно добавить в командную строку параметр -4 или -6 для правильного резолвинга.

Все вышеперечисленные параметры являются необязательными, кроме remoteserver.

Использование файла конфигурации

Хотя многие знакомы с файлом sshd_config, есть ещё файл конфигурации клиента для команды ssh. Значение по умолчанию ~/.ssh/config, но его можно определить как параметр для опции -F.

Host *
     Port 2222

Host remoteserver
     HostName remoteserver.thematrix.io
     User neo
     Port 2112
     IdentityFile /home/test/.ssh/remoteserver.private_key

В приведённом выше примерном файле конфигурации ssh две записи хоста. Первая обозначает все хосты, для всех применяется параметр конфигурации Port 2222. Вторая говорит, что для хоста remoteserver следует использовать другое имя пользователя, порт, FQDN и IdentityFile.

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

Копирование файлов по SSH с помощью SCP

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

localhost:~$ scp mypic.png neo@remoteserver:/media/data/mypic_2.png

В этом примере файл mypic.png скопирован на remoteserver в папку /media/data и переименован в mypic_2.png.

Не забывайте о разнице в параметре порта. На этом попадаются многие, кто запускает scp из командной строки. Здесь параметр порта -P, а не -p, как в ssh-клиенте! Вы забудете, но не волнуйтесь, все забывают.

Для тех, кто знаком с консольным ftp, многие из команд похожи в sftp. Вы можете сделать push, put и ls, как сердце пожелает.

sftp neo@remoteserver

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

1. SSH socks-прокси

Функция SSH Proxy под номером 1 по уважительной причине. Она более мощная, чем многие предполагают, и даёт вам доступ к любой системе, к которой имеет доступ удалённый сервер, используя практически любое приложение. Клиент ssh может туннелировать трафик через прокси-сервер SOCKS одной простой командой. Важно понимать, что трафик к удалённым системам будет исходить от удалённого сервера, так будет указано в логах веб-сервера.

localhost:~$ ssh -D 8888 user@remoteserver

localhost:~$ netstat -pan | grep 8888
tcp        0      0 127.0.0.1:8888       0.0.0.0:*               LISTEN      23880/ssh

Здесь мы запускаем socks-прокси на TCP-порту 8888, вторая команда проверяет, что порт активен в режиме прослушивания. 127.0.0.1 указывает, что служба работает только на localhost. Мы можем применить немного другую команду для прослушивания всех интерфейсов, включая ethernet или wifi, это позволит другим приложениям (браузерам и т д.) в нашей сети подключаться к прокси-сервису через ssh socks-прокси.

localhost:~$ ssh -D 0.0.0.0:8888 user@remoteserver

Теперь можем настроить браузер для подключения к socks-прокси. В Firefox выберите Настройки | Основные | Параметры сети. Укажите IP-адрес и порт для подключения.

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

Активация socks-прокси в Chrome

Запуск Chrome с определёнными параметрами командной строки активирует socks-прокси, а также туннелирование DNS-запросов из браузера. Доверяй, но проверяй. Используйте tcpdump для проверки, что DNS-запросы больше не видны.

localhost:~$ google-chrome --proxy-server="socks5://192.168.1.10:8888"

Использование других приложений с прокси

Имейте в виду, что многие другие приложения тоже могут использовать socks-прокси. Веб-браузер просто самое популярное из них. У некоторых приложений есть параметры конфигурации для активации прокси-сервера. Другим нужно немного помочь вспомогательной программой. Например, proxychains позволяет запустить через socks-прокси Microsoft RDP и др.

localhost:~$ proxychains rdesktop $RemoteWindowsServer

Параметры конфигурации socks-прокси задаются в файле конфигурации proxychains.

Подсказка: если используете удалённый рабочий стол из Linux на Windows? Попробуйте клиент FreeRDP. Это более современная реализация, чем rdesktop, с гораздо более плавным взаимодействием.

Вариант использования SSH через socks-прокси

Вы сидите в кафе или гостинице — и вынуждены использовать довольно ненадёжный WiFi. С ноутбука локально запускаем ssh-прокси и устанавливаем ssh-туннель в домашнюю сеть на локальный Rasberry Pi. Используя браузер или другие приложения, настроенные для socks-прокси, мы можем получить доступ к любым сетевым службам в нашей домашней сети или выйти в интернет через домашнее подключение. Всё между вашим ноутбуком и домашним сервером (через Wi-Fi и интернет до дома) зашифровано в туннеле SSH.

2. Туннель SSH (переадресация портов)

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

localhost:~$ ssh  -L 9999:127.0.0.1:80 user@remoteserver

Разберём параметр -L. Его можно представить как локальную сторону прослушивания. Таким образом, в примере выше порт 9999 прослушивается на стороне localhost и переадресуется через порт 80 на remoteserver. Обратите внимание, что 127.0.0.1 относится к localhost на удалённом сервере!

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

localhost:~$ ssh  -L 0.0.0.0:9999:127.0.0.1:80 user@remoteserver

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

3. SSH-туннель на сторонний хост

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

localhost:~$ ssh  -L 0.0.0.0:9999:10.10.10.10:80 user@remoteserver

В данном примере мы перенаправляем туннель от remoteserver к веб-серверу, работающему на 10.10.10.10. Трафик с remoteserver к 10.10.10.10 уже не в SSH-туннеле. Веб-сервер на 10.10.10.10 будет считать remoteserver источником веб-запросов.

4. Обратный SSH-туннель

Здесь настроим прослушивающий порт на удалённом сервере, который будет подключаться обратно к локальному порту на нашем localhost (или другой системе).

localhost:~$ ssh -v -R 0.0.0.0:1999:127.0.0.1:902 192.168.1.100 user@remoteserver

В этой SSH-сессии устанавливается соединение с порта 1999 на remoteserver к порту 902 на нашем локальном клиенте.

5. Обратный прокси SSH

В этом случае мы устанавливаем socks-прокси на нашем ssh-соединении, однако прокси слушает на удалённом конце сервера. Подключения к этому удалённому прокси теперь появляются из туннеля как трафик с нашего localhost.

localhost:~$ ssh -v -R 0.0.0.0:1999 192.168.1.100 user@remoteserver

Устранение проблем с удалёнными SSH-туннелями

Если у вас возникли проблемы с работой удалённых опций SSH, проверьте с помощью netstat, к каким ещё интерфейсам подключён порт прослушивания. Хотя мы в примерах указали 0.0.0.0, но если значение GatewayPorts в sshd_config установлено в значение no, то листенер будет привязан только к localhost (127.0.0.1).

Предупреждение безопасности

Обратите внимание, что при открытии туннелей и socks-прокси внутренние сетевые ресурсы могут быть доступны ненадёжным сетям (например, интернету!). Это может быть серьёзной угрозой безопасности, поэтому убедитесь, что вы понимаете, что представляет собой слушатель и к чему у него есть доступ.

6. Установка VPN по SSH

Общий термин среди спецов по методам атаки (пентестеры и проч.) — это «точка опоры в сети». После установления соединения в одной системе эта система становится шлюзом для дальнейшего доступа к сети. Точка опоры, которая позволяет двигаться вширь.

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

Используя этот более продвинутый вариант VPN, подключение снижается до уровня 3. Затем мы можем просто направить трафик через туннель, используя стандартную сетевую маршрутизацию.

Метод использует ssh, iptables, tun interfaces и маршрутизацию.

Сначала нужно задать эти параметры в sshd_config. Поскольку мы вносим изменения в интерфейсы и удалённой, и клиентской системы, нам нужны права root с обеих сторон.

PermitRootLogin yes
PermitTunnel yes

Затем установим ssh-соединение, используя параметр, который запрашивает инициализацию tun-устройств.

localhost:~# ssh -v -w any root@remoteserver

Теперь у нас должно быть устройство tun при показе интерфейсов (# ip a). Следующий шаг добавит IP-адреса к туннельным интерфейсам.

Сторона клиента SSH:

localhost:~# ip addr add 10.10.10.2/32 peer 10.10.10.10 dev tun0
localhost:~# ip tun0 up

Сторона сервера SSH:

remoteserver:~# ip addr add 10.10.10.10/32 peer 10.10.10.2 dev tun0
remoteserver:~# ip tun0 up

Теперь у нас прямой маршрут к другому хосту (route -n и ping 10.10.10.10).

Можно маршрутизировать любую подсеть через хост на другой стороне.

localhost:~# route add -net 10.10.10.0 netmask 255.255.255.0 dev tun0

На удалённой стороне необходимо включить ip_forward и iptables.

remoteserver:~# echo 1 > /proc/sys/net/ipv4/ip_forward
remoteserver:~# iptables -t nat -A POSTROUTING -s 10.10.10.2 -o enp7s0 -j MASQUERADE

Бум! VPN через туннель SSH на сетевом уровне 3. Вот это уже победа.

Если возникают какие-то проблемы, используйте tcpdump и ping, чтобы установить причину. Поскольку мы играем на уровне 3, то наши пакеты icmp пойдут через этот туннель.

7. Копирование ключа SSH (ssh-copy-id)

Тут есть несколько способов, но эта команда экономит время, чтобы не копировать файлы вручную. Она просто копирует ~/.ssh/id_rsa.pub (или ключ по умолчанию) с вашей системы в ~/.ssh/authorized_keys на удалённом сервере.

localhost:~$ ssh-copy-id user@remoteserver

8. Удалённое выполнение команд (неинтерактивно)

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

localhost:~$ ssh remoteserver "cat /var/log/nginx/access.log" | grep badstuff.php

В данном примере grep выполняется на локальной системе после того, как лог скачался по ssh-каналу. Если файл большой, удобнее запустить grep на удалённой стороне, просто заключив обе команды в двойные кавычки.

Другой пример выполняет ту же самую функцию, что и ssh-copy-id из примера 7.

localhost:~$ cat ~/.ssh/id_rsa.pub | ssh remoteserver 'cat >> .ssh/authorized_keys'

9. Удалённый перехват пакетов и просмотр в Wireshark

Я взял один из наших примеров по tcpdump. Используйте его для удалённого перехвата пакетов с выдачей результата непосредственно в GUI локального Wireshark.

:~$ ssh root@remoteserver 'tcpdump -c 1000 -nn -w - not port 22' | wireshark -k -i -

10. Копирование локальной папки на удалённый сервер по SSH

Красивый трюк, который сжимает папку с помощью bzip2 (это параметр -j в команде tar), а затем извлекает поток bzip2 на другой стороне, создавая на удалённом сервере дубликат папки.

localhost:~$ tar -cvj /datafolder | ssh remoteserver "tar -xj -C /datafolder"

11. Удалённые приложения GUI с переадресацией SSH X11

Если на клиенте и удалённом сервере установлены «иксы», то можно удалённо выполнить команду GUI, с окном на вашем локальном рабочем столе. Эта функция существует давным давно, но по-прежнему очень полезна. Запустите удалённый веб-браузер или даже консоль VMWawre Workstation, как я делаю в этом примере.

localhost:~$ ssh -X remoteserver vmware

Требуется строка X11Forwarding yes в файле sshd_config.

12. Удалённое копирование файлов с помощью rsync и SSH

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

В этом примере используется сжатие gzip (-z) и режим архивирования (-a), который включает рекурсивное копирование.

:~$ rsync -az /home/testuser/data remoteserver:backup/

13. SSH через сеть Tor

Анонимная сеть Tor может туннелировать SSH-трафик с помощью команды torsocks. Следующая команда прокинет ssh-прокси через Tor.

localhost:~$ torsocks ssh myuntracableuser@remoteserver

Torsocks будет использовать для прокси порт 9050 на localhost. Как всегда при использовании Tor необходимо серьёзно проверять, какой трафик туннелируется и другие проблемы операционной безопасности (opsec). Куда идут ваши DNS-запросы?

14. SSH к инстансу EC2

Для подключения к инстансу EC2 необходим закрытый ключ. Скачайте его (расширение .pem) из панели управления Amazon EC2 и измените разрешения (chmod 400 my-ec2-ssh-key.pem). Храните ключ в надёжном месте или поместите его в свою папку ~/.ssh/.

localhost:~$ ssh -i ~/.ssh/my-ec2-key.pem ubuntu@my-ec2-public

Параметр -i просто указывает ssh-клиенту использовать этот ключ. Файл ~/.ssh/config идеально подходит для автоматической настройки использования ключа при подключении к хосту ec2.

Host my-ec2-public
   Hostname ec2???.compute-1.amazonaws.com
   User ubuntu
   IdentityFile ~/.ssh/my-ec2-key.pem

15. Редактирование текстовых файлов с помощью VIM через ssh/scp

Для всех любителей vim этот совет сэкономит немного времени. С помощью vim файлы редактируются по scp одной командой. Этот метод просто создаёт файл локально в /tmp, а затем копирует его обратно, как только мы его сохранили из vim.

localhost:~$ vim scp://user@remoteserver//etc/hosts

Примечание: формат немного отличается от обычного scp. После хоста у нас двойной //. Это ссылка на абсолютный путь. Один слэш будет означать путь относительно домашней папки users.

**warning** (netrw) cannot determine method (format: protocol://[user@]hostname[:port]/[path])

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

16. Монтирование удалённого SSH как локальной папки с SSHFS

При помощи sshfs — клиента файловой системы ssh — мы можем подключить локальный каталог к удалённому местоположению со всеми взаимодействиями файлов в зашифрованном сеансе ssh.

localhost:~$ apt install sshfs

На Ubuntu и Debian установим пакет sshfs, а затем просто приимонтируем удалённое расположение к нашей системе.

localhost:~$ sshfs user@remoteserver:/media/data ~/data/

17. Мультиплексирование SSH с помощью ControlPath

По умолчанию при наличии существующего подключения к удалённому серверу с помощью ssh второе подключение с помощью ssh или scp устанавливает новый сеанс с дополнительной аутентификацией. Опция ControlPath позволяет использовать существующий сеанс для всех последующих соединений. Это значительно ускорит процесс: эффект заметен даже в локальной сети, а тем более при подключении к удалённым ресурсам.

Host remoteserver
        HostName remoteserver.example.org
        ControlMaster auto
        ControlPath ~/.ssh/control/%r@%h:%p
        ControlPersist 10m

ControlPath указывает сокет для проверки новыми соединениями на предмет наличия активной сессии ssh. Последняя опция означает, что даже после выхода из консоли существующий сеанс останется открытым 10 минут, так что в течение этого времени вы сможете повторно подключиться по существующему сокету. Для дополнительной информации смотрите справку ssh_config man.

18. Потоковое видео по SSH с помощью VLC и SFTP

Даже давние пользователи ssh и vlc (Video Lan Client) не всегда знают об этой удобной опции, когда очень нужно посмотреть видео по сети. В настройках File | Open Network Stream программы vlc можно ввести местоположение как sftp://. Если требуется пароль, появится запрос.

sftp://remoteserver//media/uploads/myvideo.mkv

19. Двухфакторная аутентификация

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

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

См. наше 8-минутное руководство по использованию Google Authenticator и SSH.

20. Прыжки по хостам с ssh и -J

Если из-за сегментации сети приходится переходить через несколько хостов ssh, чтобы добраться до конечной сети назначения, вам сэкономит время ярлык -J.

localhost:~$ ssh -J host1,host2,host3 [email protected]

Здесь главное понимать, что это не аналогично команде ssh host1, затем user@host1:~$ ssh host2 и т. д. Параметр -J хитро использует переадресацию, чтобы localhost устанавливал сеанс со следующим хостом в цепочке. Таким образом, в приведённом выше примере наш localhost аутентифицируется на host4. То есть используются наши ключи localhost, а сеанс от localhost до host4 полностью зашифрован.

Для такой возможности в ssh_config укажите опцию конфигурации ProxyJump. Если регулярно приходится переходить через несколько хостов, то автоматизация через конфиг сэкономит массу времени.

21. Блокировка попыток брутфорса SSH с помощью iptables

Любой, кто управлял сервисом SSH и просматривал логи, знает о количестве попыток брутфорса, которые происходят каждый час каждый день. Быстрый способ уменьшить шум в логах — перенести SSH на нестандартный порт. Внесите изменения в файл sshd_config с помощью параметра конфигурации Port##.

С помощью iptables тоже можно легко блокировать попытки подключения к порту по достижении определённого порога. Простой способ сделать это — использовать OSSEC, поскольку он не только блокирует SSH, но выполняет кучу других мер по обнаружению вторжений на базе имени хоста (HIDS).

22. SSH Escape для изменения переадресации портов

И наш последний пример ssh предназначен для изменения переадресации портов на лету в рамках существующего сеанса ssh. Представьте такой сценарий. Вы глубоко в сети; возможно, прыгнули через полдюжины хостов и вам нужен локальный порт на рабочей станции, который перенаправлен на Microsoft SMB старой системы Windows 2003 (кто-нибудь помнит ms08-67?).

Нажав enter, попробуйте ввести в консоли ~C. Это управляющая последовательность в сессии, позволяющая вносить изменения в существующее соединение.

localhost:~$ ~C
ssh> -h
Commands:
      -L[bind_address:]port:host:hostport    Request local forward
      -R[bind_address:]port:host:hostport    Request remote forward
      -D[bind_address:]port                  Request dynamic forward
      -KL[bind_address:]port                 Cancel local forward
      -KR[bind_address:]port                 Cancel remote forward
      -KD[bind_address:]port                 Cancel dynamic forward
ssh> -L 1445:remote-win2k3:445
Forwarding port.

Здесь вы можете увидеть, что мы переадресовали наш локальный порт 1445 на хост Windows 2003, который нашли во внутренней сети. Теперь просто запустите msfconsole, и можно идти дальше (предполагая, что вы планируете использовать этот хост).
Эти примеры, советы и команды ssh должны дать отправную точку; дополнительная информация о каждой из команд и возможностей доступна на справочных страницах (man ssh, man ssh_config, man sshd_config).

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

Порт SSH

Как порт SSH стал 22

Порт SSH по умолчанию — 22. Это не совпадение. Это история о том, как он получил этот порт.

Когда я (Тату Илонен впервые опубликовал эту статью в апреле 2017 года, она стала вирусной и собрала около 120 000 читателей за три дня.

История получения 22 порта SSH

Я написал начальную версию SSH (Secure Shell) на Весна 1995 г. Это было время, когда широко использовались telnet и FTP

Так или иначе, я разработал SSH для замены telnet (порт 23) и ftp (порт 21).Порт 22 был свободен. Удобно было между портами telnet и ftp . Я подумал, что наличие этого номера порта может быть одной из тех мелочей, которые придают некоторую ауру доверия. Но как я мог получить этот номер порта? Я никогда не выделял его, но я знал кого-то, кто выделил порт.

В то время основной процесс распределения портов был довольно простым. Интернет был меньше, и мы были на очень ранней стадии интернет-бума. Номера портов были выделены IANA (Internet Assigned Numbers Authority).В то время это означало уважаемых пионеров Интернета по имени Джон Постел и Джойс К. Рейнольдс. Среди прочего, Джон был редактором таких второстепенных стандартов протоколов, как IP (RFC 791), ICMP (RFC 792) и TCP (RFC 793). Некоторые из вас, возможно, слышали о них.

Мне Джон чувствовал себя совершенно напуганным, будучи автором всех основных RFC для Интернета!

Во всяком случае, незадолго до объявления ssh-1.0 в июле 1995 года я отправил это письмо в IANA:

  From ylo Mon Jul 10 11:45:48 +0300 1995
От: Тату Илонен 
Кому: Управление по распределению номеров в Интернете 
Тема: запрос номера порта
Организация: Хельсинкский технологический университет, Финляндия

Уважаемый господин,

Я написал программу для безопасного входа с одной машины на другую
по небезопасной сети. Обеспечивает значительные улучшения в безопасности
и функциональность по существующим протоколам telnet и rlogin и
реализации. В частности, предотвращает IP, DNS и маршрутизацию.
спуфинг. Я планирую свободно распространять программное обеспечение на
Интернет и максимально широко использовать его.Я хочу получить зарегистрированный номер привилегированного порта для
программного обеспечения. Число предпочтительно должно быть в диапазоне 1-255, чтобы
его можно использовать в поле WKS на серверах имен.

Прилагаю проект RFC для протокола ниже. Программное обеспечение имеет
находился в местном использовании в течение нескольких месяцев и готов к публикации
кроме номера порта. Если присвоение номера порта может быть
в срок, я бы хотел опубликовать программу уже на этой неделе.
В настоящее время я использую порт номер 22 в бета-тестировании.Это было бы
отлично, если бы этот номер можно было использовать (в настоящее время он отображается как
Не назначен в списках).

Имя службы для программного обеспечения - «ssh» (для Secure Shell).

Искренне Ваш,

Тату Илонен 

... сопровождаемая спецификацией протокола для ssh-1.0

На следующий день в моем почтовом ящике ждала электронная почта от Джойс:

  Дата: Пн, 10 июля 1995 г. 15:35:33 -0700
От: [email protected]
Кому: [email protected]
Тема: Re: запрос номера порта
Копия: [email protected]

Тату,

Мы назначили порт номер 22 для ssh, с вами в качестве точки
контакт.Джойс

Вот и мы! SSH порт был 22 !!!

12 июля 1995 года в 2:32 я объявил о финальной бета-версии моим бета-тестерам в Хельсинкском технологическом университете. В 17:23 я объявил своим бета-тестерам о пакетах ssh-1.0.0. В 17:51 12 июля 1995 года я отправил объявление о SSH (Secure Shell) в список рассылки [email protected] . Я также разместил его в нескольких группах новостей, списках рассылки и непосредственно среди избранных людей, которые обсуждали связанные темы в Интернете.

Изменение порта SSH на сервере

По умолчанию сервер SSH все еще работает на порту 22. Однако бывают случаи, когда он запускается на другом порту. Тестовое использование — одна из причин. Другое дело — запуск нескольких конфигураций на одном хосте. В редких случаях он также может запускаться без привилегий root, и в этом случае он должен запускаться на непривилегированном порту (то есть с номером порта> = 1024).

Номер порта можно настроить, изменив директиву Port 22 в / etc / ssh / sshd_config.Его также можно указать с помощью параметра -p для sshd. Клиент SSH и программы sftp также поддерживают параметр -p .

Указание номера порта SSH в командной строке

Параметр -p можно использовать для указания номера порта для подключения при использовании команды ssh в Linux. Параметр -P <порт> (примечание: заглавная P) можно использовать с SFTP и scp . Параметр командной строки номера порта SSH переопределяет любое значение, заданное в файлах конфигурации.

Настройка доступа SSH через межсетевые экраны

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

Исходящий SSH

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

Обратное туннелирование — это риск

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

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

Однако, как правило, это нарушает политику и забирает контроль у администраторов брандмауэра и группы безопасности. Это может, например, нарушать PCI, HIPAA или NIST SP 800-53. Его могут использовать хакеры и иностранные спецслужбы, чтобы оставить лазейки в организациях

Входящий SSH-доступ

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

Настроить брандмауэр для перенаправления всех подключений к порту 22 на определенный IP-адрес. адрес во внутренней сети или DMZ.
Используйте разные порты на брандмауэре для доступа к разным серверам.
Разрешать доступ по SSH только после входа в систему с помощью VPN (виртуальной частной сети), обычно с использованием протокола IPsec.

Включение доступа по SSH через iptables

Iptables — это межсетевой экран хоста, встроенный в ядро Linux. Обычно он настраивается для защиты сервера, предотвращая доступ к любым портам, которые не были явно открыты.

Если на сервере включен iptables , для разрешения входящего доступа по SSH можно использовать следующие команды.Их нужно запускать как root.

  iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW, ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Если вы хотите сохранить правила навсегда, в некоторых системах это можно сделать с помощью команды:

  service iptables save

Перенаправление портов SSH — пример, команда, конфигурация сервера

Что такое перенаправление портов SSH, также известное как туннелирование SSH?

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

Local Forwarding

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

Типичные варианты использования для перенаправления локальных портов:

Сеансы туннелирования и передача файлов через серверы переходов
Подключение к службе во внутренней сети извне
Подключение к удаленному файловому ресурсу через Интернет

Довольно много организаций для всего входящего доступа SSH через один сервер перехода. Сервер может быть стандартным Linux / Unix-сервером, обычно с некоторым дополнительным усилением защиты, обнаружением вторжений и / или журналированием, или это может быть коммерческое решение для сервера перехода.

Многие серверы переходов разрешают переадресацию входящего порта после аутентификации соединения. Такая переадресация портов удобна тем, что позволяет технически подкованным пользователям достаточно прозрачно использовать внутренние ресурсы. Например, они могут перенаправить порт своего локального компьютера на корпоративный веб-сервер интрасети, на порт IMAP внутреннего почтового сервера, на порты 445 и 139 локального файлового сервера, на принтер, в репозиторий управления версиями или почти на любая другая система во внутренней сети.Часто порт туннелируется на порт SSH на внутренней машине.

В OpenSSH переадресация локальных портов настраивается с помощью параметра -L :

  ssh -L 80: intra.example.com: 80 gw.example.com

В этом примере открывается соединение с gw .example.com jump server и перенаправляет любое соединение с порта 80 на локальном компьютере на порт 80 на intra.example.com .

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

  ssh -L 127.0.0.1:80:intra.example.com:80 gw.example.com

The LocalForward Параметр в файле конфигурации клиента OpenSSH можно использовать для настройки пересылки без необходимости указывать его в командной строке.

Удаленная переадресация

В OpenSSH переадресация удаленных портов SSH указывается с помощью параметра -R . Например:

  ssh -R 8080: localhost: 80 public.example.com

Это позволяет любому на удаленном сервере подключаться к TCP-порту 8080 на удаленном сервере. Затем соединение будет туннелировано обратно на клиентский хост, а затем клиент установит TCP-соединение с портом 80 на localhost . Вместо localhost можно использовать любое другое имя хоста или IP-адрес для указания хоста для подключения.

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

По умолчанию OpenSSH позволяет подключаться только к удаленным перенаправленным портам с хоста сервера. Однако для управления этим можно использовать параметр GatewayPorts в файле конфигурации сервера sshd_config. Возможны следующие альтернативы:

  GatewayPorts №

Это предотвращает подключение к перенаправленным портам извне серверного компьютера.

  GatewayPorts да

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

  GatewayPorts clientpecified

Это означает, что клиент может указать IP-адрес, с которого разрешены подключения к порту. Синтаксис для этого:

  ssh -R 52.194.1.73:8080:localhost:80 host147.aws.example.com

В этом примере только соединения с IP-адреса 52.194.1.73 с на порт 8080 разрешены.

OpenSSH также позволяет указать для перенаправленного удаленного порта значение 0. В этом случае сервер будет динамически выделять порт и сообщать об этом клиенту. При использовании с опцией -O forward клиент будет выводить выделенный номер порта на стандартный вывод.

Открытие бэкдоров в предприятии

Удаленная переадресация портов SSH обычно используется сотрудниками для открытия бэкдоров в предприятии. Например, сотрудник может настроить получение сервера бесплатного уровня из Amazon AWS и войти в систему из офиса на этот сервер, указав удаленную переадресацию с порта на сервере на какой-либо сервер или приложение во внутренней корпоративной сети.Можно указать несколько удаленных переадресации, чтобы открыть доступ к более чем одному приложению.

Сотрудник также установил бы GatewayPorts да на сервере (у большинства сотрудников нет фиксированных IP-адресов дома, поэтому они не могут ограничить IP-адрес).

Например, следующая команда открывает доступ к внутренней базе данных Postgres на порту 5432 и внутреннему порту SSH на порту 2222.

  ssh -R 2222: d76767.nyc.example.com: 22 -R 5432: postgres3. Нью-Йоркexample.com:5432 aws4.mydomain.net

Конфигурация на стороне сервера

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

Другой интересный вариант — AllowStreamLocalForwarding , который можно использовать для пересылки сокетов домена Unix. Он допускает те же значения, что и AllowTcpForwarding . По умолчанию да .

Например:

  AllowTcpForwarding remote
    AllowStreamLocalForwarding нет

Опция конфигурации GatewayPorts , описанная выше, также влияет на переадресацию удаленных портов. Возможные значения: нет, (разрешены только локальные подключения с хоста сервера; по умолчанию), да (любой в Интернете может подключаться к удаленным перенаправленным портам) и , заданный клиентом (клиент может указать IP-адрес, который может подключаться, любой может если не указано).

Как предотвратить переадресацию портов SSH в обход межсетевых экранов

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

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

Дополнительная информация

Использование SSH через порт HTTPS

Документы GitHub

Все продукты
GitHub.com

Начиная
- Быстрый старт
  - Настроить Git
  - Создать репо
  - Форк репо
  - Быть социальным
- Изучение GitHub
  - Продукты GitHub
  - Изучение выпусков раннего доступа с предварительным просмотром функций
  - Типы аккаунтов GitHub
  - Часто задаваемые вопросы об изменениях в планах GitHub
  - GitHub CLI
  - GitHub Desktop
  - GitHub для мобильных устройств
  - Разрешения на доступ на GitHub
  - Глоссарий GitHub
  - Шпаргалка по Git
  - Учебные ресурсы Git и GitHub
- Регистрация на GitHub
  - Регистрация новой учетной записи GitHub
  - Подтверждение адреса электронной почты
  - Настройка пробной версии GitHub Enterprise Cloud
  - Настройка пробной версии GitHub Enterprise Server
- Изучение проектов на GitHub
  - Поиск способов внести свой вклад в открытый исходный код на GitHub
  - Сохранение репозиториев со звездочкой

ssh -L пересылать несколько портов

Переполнение стека

Около
Продукты
Для команд

Переполнение стека
Общественные вопросы и ответы
Переполнение стека для команд
Где разработчики и технологи делятся частными знаниями с коллегами
Вакансии
Программирование и связанные с ним технические возможности карьерного роста
Талант
Нанимайте технических специалистов и создавайте свой бренд работодателя
Реклама
Обратитесь к разработчикам и технологам со всего мира
О компании

Загрузка…

Декабрь 2024
Пн	Вт	Ср	Чт	Пт	Сб	Вс
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31

Ssh порт какой: Как SSH появился на 22 порту / Хабр

Как SSH появился на 22 порту / Хабр

Исходящий SSH

Обратное туннелирование — это риск

Входящий SSH

22 порт SSH переносить или нет / Хабр

1 этап — сбор информации о хосте, в том числе и открытых портах

2 этап — попытки получить доступ к системе через взлом SSH

Смена порта SSH-сервера как мера защиты от брутфорса

Соединение с SSH-сервером на альтернативном порту

Команда SSH | ИТ Блог. Администрирование серверов на основе Linux (Ubuntu, Debian, CentOS, openSUSE)

Установка OpenSSH клиента

Установка клиента OpenSSH в Linux

Установка OpenSSH в Ubuntu и Debian

Установка OpenSSH на CentOS и Fedora

Установка OpenSSH клиента в Windows 10

Установка OpenSSH клиента на macOS

Как использовать команду ssh

Файл конфигурации SSH

Аутентификация с открытым ключом

Перенаправление порта

Переадресация локального порта

Переадресация удаленных портов

Динамическая переадресация портов

Вывод

Магия SSH / Хабр

1) Local TCP forwarding

2) Remote TCP forwarding

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

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

5) SSH VPN Tunnel

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

7) Спасибо (ссылки)

Как подключиться к серверу по SSH?

Где найти доступы к серверу

Как подключиться по SSH с компьютера на ОС Windows

Как подключиться к серверу по SSH с компьютера на Linux/MacOS

Практические советы, примеры и туннели SSH / Хабр

Практические примеры SSH

Разбор командной строки SSH

Использование файла конфигурации

Копирование файлов по SSH с помощью SCP

1. SSH socks-прокси

Активация socks-прокси в Chrome

Использование других приложений с прокси

Вариант использования SSH через socks-прокси

2. Туннель SSH (переадресация портов)

3. SSH-туннель на сторонний хост

4. Обратный SSH-туннель

5. Обратный прокси SSH

Устранение проблем с удалёнными SSH-туннелями

Предупреждение безопасности

6. Установка VPN по SSH

7. Копирование ключа SSH (ssh-copy-id)

8. Удалённое выполнение команд (неинтерактивно)

9. Удалённый перехват пакетов и просмотр в Wireshark

10. Копирование локальной папки на удалённый сервер по SSH

11. Удалённые приложения GUI с переадресацией SSH X11

12. Удалённое копирование файлов с помощью rsync и SSH

13. SSH через сеть Tor

14. SSH к инстансу EC2

15. Редактирование текстовых файлов с помощью VIM через ssh/scp

16. Монтирование удалённого SSH как локальной папки с SSHFS

17. Мультиплексирование SSH с помощью ControlPath

18. Потоковое видео по SSH с помощью VLC и SFTP

19. Двухфакторная аутентификация

20. Прыжки по хостам с ssh и -J

21. Блокировка попыток брутфорса SSH с помощью iptables

22. SSH Escape для изменения переадресации портов

Порт SSH

Как порт SSH стал 22

История получения 22 порта SSH

Изменение порта SSH на сервере

Указание номера порта SSH в командной строке

Настройка доступа SSH через межсетевые экраны

Исходящий SSH

Обратное туннелирование — это риск

Входящий SSH-доступ

Включение доступа по SSH через iptables

Перенаправление портов SSH — пример, команда, конфигурация сервера