Как проверить наличие ssh на linux

Обновлено: 07.07.2024

Если выбрать yes то в файл

/.ssh/known_hosts добавится похожая строка:

|1| abcdef+abcdefghijklmnopqrst=|abcdefghijklmnopqrstuvwxyz1= ssh-rsa abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrst/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz12345/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzB1234567

Обычно файл known_hosts имеет следующий формат (записи идут через пробел)

Это хэш от имени сервера.

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

Сгенерировать пару ключей

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

ssh-keygen -b 4096

sudo ssh-keygen -b 4096

Нужно придумать имя ключа.

Я назову ключ andrei-key101 а сохранять буду в текущую директорию.

Нужно два раза ввести пароль. Если он вам нужен. Обычно нет.

Ключи готовы. Я сохранил их в текущую директорию поэтому увижу их сделав ls

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

.pub ключ отправляйте на удалённую машину

приватный ключ храните на своём клиенте

Передать ключ на удалённый хост

После того, как ключи созданы нужно передать .pub ключ на удалённый хост.

Сделать это можно несколькими способами начнём с утилиты ssh-copy-id

ssh-copy-id

Я предпочитаю использовать с флагом -i и задавать путь до нужного ключа

sudo ssh-copy-id -i

Введите yes

Теперь на хосте 192.168.0.2 в файле /home/andrei/.ssh/authorized_keys появилась новая запись вида

Знак … заменяет длинные последовательности случайных символов для экономии места.

Проверить ключ можно командой

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

Last login: Sun Jan 10 16:48:27 2021 from 192.168.0.1

Узнать версию OpenSSH в Linux

Чтобы узнать версию OpenSSH в вашем дистрибутиве Linux выполните

OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017

Выполнить команду из скрипта на удалённом компьютере

Если подключение по ssh происходим из bash-скрипта , и при этом нужно ещё выполнить ряд команд после подключения - достаточно перечислить эти команды через точку с запятой

Если нужно выполнить команду, требующую sudo попробуйте флаг -t

known_hosts

Список известных хостов находится в файле known_hosts

Обычно файл known_hosts имеет следующий формат (записи идут через пробел) ( подробнее )

Примеры алгоритмов: ssh-rsa, ssh-dss, ssh-ed25519, ecdsa-sha2-nistp256 …

Это хэш от имени сервера.

Это алгоритм шифрования

Это публичный ключ хоста

Создать SSH туннель

Туннели обычно создают для перенаправления траффика. SSH tunnel это то же самое что и SSH port forwarding.

На удалённом хосте у вас есть пользователь с именем andrei и вы знаете его пароль.

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

Предположим, вы выбрали 9119 для локального и 9200 для удаленного хостов.

То есть вы хотите, чтобы всё, что идёт на localhost:9119 было перенаправлено на 192.168.0.2 : 9200

ssh -L 9119: 192.168.0.2 : 9200 andrei@192.168.0.2

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

Если вам нужен туннель с поддержкой графического интерфейса X Window System используйте флаг -X

ssh -X -L 9119: 192.168.0.2 : 9200 andrei@192.168.0.2

Демонстрация

Туннель создан, не закрывайте терминал. Откройте два новых терминала или две новые вкладки в старом.

У вас два пустых терминала, оба на локальном хосте. Назовём их 1 и 2.

Из терминала 2 подключимся к удалённому хосту 192.168.0.2 по ssh и будем слушать на порту 9200 с помощью nmap

ssh andrei@192.168.0.2
nmap -l 9200

nmap localhost 9119

Введём любой текст

Откройте терминал 2 там дожен появиться тот же текст

Список всех открытых SSH туннелей

Чтобы получить список туннелей открытых именно ssh выполните

ssh 14695 andrei 3u IPv4 230080 0t0 TCP 192.168.0.1:46356->192.168.0.2:ssh (ESTABLISHED) ssh 14695 andrei 4u IPv6 230103 0t0 TCP [::1]:9119 (LISTEN) ssh 14695 andrei 5u IPv4 230104 0t0 TCP 127.0.0.1:9119 (LISTEN)

Вывод этой команды при практически идентичных условиях почему-то разный.

Ниже пример второго варианта. Если вы знаете почему так получается - напишите в комментариях.

ssh 15151 andrei 3u IPv4 239364 0t0 TCP 192.168.0.1:46464->192.168.0.2:ssh (ESTABLISHED) ssh 15151 andrei 4u IPv6 239380 0t0 TCP [::1]:mxit (LISTEN) ssh 15151 andrei 5u IPv4 239381 0t0 TCP 127.0.0.1:mxit (LISTEN) ssh 15151 andrei 9u IPv6 239428 0t0 TCP [::1]:mxit->[::1]:54306 (ESTABLISHED)

Закрыть все SSH туннели

Чтобы закрыть всё, что связано с ssh можно выполнить

sudo killall ssh sshd

Этот метод хорош только если вы работаете один, например на какой-то виртуальной машине.

Запустить SSH в фоновом режиме

Существует несколько способов запустить ssh соединение в фоновом режиме - то есть освободим текущий терминал.

-L, screen, tmux, nohup

Мне запустить ssh фоном из скрипта помог nohup, поэтому начнём с него

nohup ssh user@host "cd scripts;python3 my_script.py $ARG1 $ARG2; exit" &

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

Чтобы уйдя из первого подключения не оборвать мониторинг потребления памяти перед ssh нужно было добавить nohup, а в самом конце поставить &

SSH_MSG_USERAUTH_BANNER

Клиенту, подключившемуся к ssh серверу можно показать баннер SSH_MSG_USERAUTH_BANNER

И отредактируйте файл добавив свой баннер

Откройте sshd_config и укажите путь до баннера

Этот баннер будет показан ДО авторизации, то есть во время ввода пароля

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

После редактирования файлов перезапустите sshd

sudo systemctl restart sshd.service

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

Рассмотрим простой пример: вы достали из базы данных сертификат MIIC4jCCAc … A7A6Rpt8V9Q== , но он не отформатирован и не проходит валидацию

Сертификат, конечно, длиннее, я поставил троеточие для экономии места и вашего времени.

Либо, если вам нужно работать с файлами - сохраните исходный сертифика в фай raw_cert

echo MIIC4jC … 7A6Rpt8V9Q== > raw_cert
cat raw_cert | base64 -d | openssl x509 -inform der > cert
cat cert

-----BEGIN CERTIFICATE-----
MIIC4jC … 7A6Rpt8V9Q==
-----END CERTIFICATE-----

Такого же результата можно было добиться аккуратно добавив -----BEGIN CERTIFICATE----- в начало и -----END CERTIFICATE----- в конец файла, но не всегда всё так просто.

Ребят, имеется такая проблема. У меня есть доступ к виртуальному серверку. Мне нужна команда, которая определяет есть ли доступ к серверу по определенному порту или нет. Когда соединение сброшено, я могу без проблем получить от ssh код 255 и понять, что ничего не работает, а вот когда работает, ssh просит ввести пароль. Т.к. скрипт не будет вводить пароль, ssh не вернет код. Мне нужно сделать уведомление через bash, что сервер заработал.

Возвращает 0 или 255 в зависимости от доступности ssh на той стороне.

Настрой аутентификацию по ключам.

Он все равно ждет ввода логина. А мне нужно что-то типа ping.

На сервере к которому я подключаюсь?

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

check_ssh от nagios/icinga

Мне нужна команда, которая определяет есть ли доступ к серверу по определенному порту или нет.

На сервере к которому я подключаюсь?

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

Фишка вот в чем. Мне выделили сервер, но пока он не работает. Я просто хотел сделать уведомлялку, что он заработал и все:). Думал, что справлюсь одной командой ну да ладно. Всем спасибо.

ребята выше жгут

Мне нужна команда, которая определяет есть ли доступ к серверу по определенному порту или нет

хотел сделать уведомлялку, что он заработал

SSH или Secure Shell является распространенным протоколом администрирования на системах Linux. Часто он работает на многих системах с настройками по умолчанию. Так как этот сервис открывает потенциальный шлюз в систему, улучшение его безопасности является одним из шагов по усилению защиты системы Linux. В этой статье представлены советы по усилению безопасности сервиса OpenSSH и повышения уровня защиты системы.

Безопасность OpenSSH

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

Что мы рассмотрим в статье?

В этой статье мы рассмотрим настройки сервера и клиента. Синтаксис и настройки конфигурации базируются на OpenSSH версии 7 и выше. Примеры команд будут работать для большинства дистрибутивов Linux, таких как CentOS, Debian, Ubuntu и RHEL. Также, они могут подойти для FreeBSD, OpenBSD и других систем, которые используют OpenSSH.

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

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

Основы SSH

SSH состоит из двух частей: сервер sshd, принимающий запросы на соединения от клиентов, и клиент ssh, который используется для соединения с сервером. Обычно администрирование сервера производится с использованием клиента SSH из системы, на которой вы работаете. В ОС семейства Windows часто используется клиентское программное обеспечение Putty.

Говоря о безопасности конфигурации SSH, наибольший интерес представляет серверная часть. Например, на уровне сервера решается, разрешаются или запрещаются вход с использованием пароля. Даже если у клиента некоторые опции установлены явно, окончательное решение принимает сервер. Файл конфигурации сервера находится в каталоге /etc/ssh/sshd_config .

Настройки конфигурации клиента можно найти в /etc/ssh/ssh_config (на уровне системы) или в

/.ssh/config (на уровне пользователя). Настройки также можно определить в процессе подключения посредством передачи параметра командной строки.

Прежде, чем вносить изменения, рассмотрим, как сделать это правильно.

Советы по установке

Проверка статуса SSH

Вы впервые редактируете конфигурации SSH? Тогда сначала проверьте статус SSH-демона и посмотрите, запущен ли нужный сервис при загрузке. При использовании дистрибутива, использующего systemd , убедитесь, что демон запущен и включен.

На некоторых дистрибутивах Linux сервис называется sshd.service .

В ответе должно вернуться значение enabled :

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

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

При внесении изменений в конфигурацию SSH, целесообразно перезапустить сервис. Настоятельно рекомендуем перед запуском проверять конфигурацию ( sshd_config ). Это можно сделать используя флаг test mode. Этот дополнительный шаг позволяет убедиться, что синтаксис и опции корректны.

Команда не должна возвращать текст или ошибки.

Внесение изменений в настройки SSHD удаленной системы

Для систем c systemd используйте systemctl для перезагрузки сервиса SSH:

Для остановки процесса используйте CTRL+C .

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

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

Активные соединения SSH

Перед применением изменений или перезапуском демона, проверьте активные SSH-соединения. Это можно сделать с помощью инструмента ss .

Вы увидите установленное соединение TCP. С помощью dport и sport можно проверить, какие соединения являются активными.

Улучшение безопасности сервера SSH

Подготовка

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

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

Ответ может выглядеть следующим образом (листинг приведен не полностью):

Настройки конфигурации и значения отображаются в нижнем регистре.

Настройки безопасности SSH

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

Использование нестандартного порта для сервера

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

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

Если пересылка графического трафика X11 поверх SSH не требуется, отключите его:

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

Отключение rhosts

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

Проверка имени хоста DNS

Сервер SSH может проверять, устанавливает соответствие доменного имени клиента его адресу с помощью DNS. Такая проверка может быть активирована следующим способом:

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

Отключите пустые пароли

Максимальное количество попыток аутентификации

Для защиты от атак на пароли пользователя ограничьте число попыток входа с помощью настройки MaxAuthTries .

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

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

Аутентификация с помощью публичного ключа

Больше информации об использовании ключей SSH вместо паролей для аутентификации вы найдете в статье.

Отключите вход для учетной записи root

Более новые версии OpenSSH также поддерживают значение without-password . Это значение позволяет устанавливать соединение для учетной записи root только с использованием инфраструктуры публичных ключей.

Установите версию разрешенного протокола SSH

Если вы используете старую версию SSH, там может использоваться протокол версии 1. В этом протоколе есть ошибки, и его не стоит использовать. Начиная с OpenSSH версии 7.0 протокол версии 1 автоматически отключается при компиляции. Если вы используете раннюю версию SSH, установите версию протокола явно:

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

Полезно помнить, что SSH проверяет списки пользователей для доспуска в систему в следующем порядке: DenyUsers , AllowUsers , DenyGroups и наконец AllowGroups .

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

Каждый раз, когда SSH-клиент подключается к серверу, он сохраняет соответствующую подпись (ключ) сервера. Эта информация хранится в файле known_hosts , доступный в поддиректории .ssh соответствующего пользователя (на клиенте). В случае, когда подпись сервера отличается, SSH уведомляет пользователя об этом, и подключение не устанавливается. Это полезная опция, но есть риск. Изначально обычной практикой считалось сохранять имя хоста, соответствующего конкретному ключу хоста. Это позволяло червям и другим вредоносным скриптам легко использовать данную информацию и после взлома одной системы передавать ее другим системам. Чтобы противостоять этому, используйте HashKnownHosts , который будет создавать хэши имён хостов из

/.ssh/known_hosts . Использование хэшей имён хостов вместо самих имён хостов поддерживается в ssh(1) и sshd(8), и позволяет предотвратить утечку информации в случае разглашения содержимого файла. По умолчанию стоит значение no . Файл становится нечитабельным для человеческого глаза, но он по-прежнему позволяет SSH проверять ключ сервера при следующем подключении к той же системе.

Запрет разрешенных для выполнения команд

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

В примере выше замените поля TYPE_OF_KEY , KEY и COMMENT . Значения, которые должны использоваться, соответствуют тем, которые используются при аутентификации по открытому ключу.

Дополнительные ограничения

Настройка брандмауэра

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

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

Настройки безопасности клиента OpenSSH

Доступно множество клиентов SSH, поэтому рассказать о каждом из них в одной статье невозможно. Остановимся подробнее на инструменте клиента OpenSSH.

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

Клиент OpenSSH можно настроить тремя способами. Они обрабатываются по порядку и проверяются для каждого доступного параметра конфигурации. Выбирается первый подходящий.

Настройки задаются через командную строку;
Через файл конфигурации в домашней директории (

Просмотр активных настроек

Помните, как мы просматривали настройки для сервера ( sshd -T )? У клиента есть похожий инструмент.

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

Настройки SSH для отдельной системы

Допустим, есть система secureserver. Вместо того, чтобы работать на порте 22, она принимает соединения по SSH на порте 2222. Вместо применения -p в командной строке можно добавить блок Host в файл конфигурации. Для этого необходимо в каталоге .ssh домашней директории создать файл config ( /home/username/.ssh/config ).

Затем создадим блок и определим нужные настройки.

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

Какие же настройки следует определять в файле конфигурации клиента?

Рекомендуем использовать те, которые облегчат вам ежедневную работу. Если вы отдаете предпочтение безопасности, задайте надежные настройки по умолчанию. Если какой-то хост использует другой SSH-порт, создайте блок Host и переопределите его настройки нужным образом. Что касается KexAlgorithms, используйте более новые доступные алгоритмы. Это сильно зависит от версии OpenSSH на серверах. Если на сервере используется новая версия OpenSSH, то хорошо подойдет curve25519. Это высокоскоростной алгоритм на основе эллиптических кривых, который на данный момент считается безопасным.

Инструменты для анализа безопасности SSH

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

Lynis

Универсальный инструмент безопасности с открытым кодом для тестирования безопасности систем Linux. Он проверит все, что может, от загрузчика до сервера. Он бесплатный и написан с помощью shell script. Lynis работает в самой системе, поэтому может просматривать как файлы конфигурации, так и фактически загруженную конфигурацию. Он включает в себя несколько тестов для OpenSSH и его конфигураций, включая параметры безопасности. Результаты или возможные улучшения отображаются на экране, что позволяет непосредственно приступить к действиям и начать усиливать безопасность системы.

Скачайте утилиту с GitHub или с сайта. Используйте инструкцию, чтобы быстрее понять, с чего начать работу.

ssh-audit

Несмотря на то, что инструмент ssh-audit немного устарел, его стоит иметь в своем арсенале. Вместо тестирования на самом хосте, он может подключаться к SSH-серверу через сеть. Он выполняет тестирование на выбранной системе и просматривает полученные ответы, на основании которых узнает о системе и сервере SSH. Он даже узнает о конкретных уязвимостях и может предупредить о них. Загрузите инструмент через GitHub и попробуйте применить.

Чтобы найти больше информации о других инструментах, читайте раздел «Сканеры конфигурации безопасности Linux».

Ресурсы

Справочная страница

Хорошим ресурсом о настройках конфигурации SSH является man-страница. Хотя это звучит как простой совет, на самом деле важно помнить, что справочная страница является полезной и актуальной. При всех незначительных различиях между релизами часто сложно догадаться самостоятельно, что делает настройка. Вместо этого лучше прочитать о настройке и посмотреть, есть ли в ней изменения. Объедините эти знания с выводом команды sshd -T , и это позволит выбрать максимально правильный вариант для вашей конкретной ситуации.

В спецификации протокола SSH есть некоторые незначительные различия между версиями, но есть две основные основные версии:SSH1(Номер версии 1.XX) иSSH2(Номер версии 2.00).

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

SSH2 стандартизирован IETF, и его реализация широко применяется и принимается в отрасли. Из-за популярности и преимуществ шифрования SSH2 перед SSH1 многие продукты отказываются от поддержки SSH1. На момент написания этой статьи OpenSSH все ещеожидатьSSH1 и SSH2. Однако во всех современных дистрибутивах Linux на сервере OpenSSH по умолчанию отключен SSH1.

Проверьте поддерживаемую версию протокола SSH

метод первый

Если вы хотите проверить версию протокола SSH, поддерживаемую локальным сервером OpenSSH, вы можете обратиться к/etc/ssh/sshd_configЭтот файл. Откройте / etc / ssh / sshd_config в текстовом редакторе и проверьте поле «Протокол».

Если отображается следующее, это означает, что сервер поддерживает только SSH2.

Если отображается следующее, это означает, что сервер поддерживает как SSH1, так и SSH2.

Метод второй

Если вы не можете получить доступ к / etc / ssh / sshd_config, потому что служба OpenSSH работает на удаленном сервере. Вы можете использовать SSH-клиент ssh для проверки поддерживаемых протоколов. В частности, он должен заставить ssh использовать определенный протокол SSH, а затем мы проверяем ответ SSH-сервера.

Следующая команда заставляет SSH использовать SSH1:

Следующая команда заставляет ssh использовать SSH2:

Если сервер SSH поддерживает как SSH1, так и SSH2, обе команды действительны.

Метод третий

Другой способ проверить версию - запустить инструмент сканирования SSH под названиемscanssh. Этот инструмент командной строки полезен, когда вы хотите проверить набор IP-адресов или всю локальную сеть для обновления SSH1-совместимого сервера SSH.

Ниже приводится базовый синтаксис сканирования версий SSH.

Параметр «-n» может указать порт SSH для сканирования. Вы можете сканировать несколько портов со всеми разделенными, без этой опции scanssh будет сканировать порт 22 по умолчанию.

Используйте следующую команду, чтобы обнаружить SSH-сервер в локальной сети 192.168.1.0/24 и проверить версию протокола SSH v:

Если scanssh сообщает «SSH-1.XX-XXXX» для определенного IP-адреса, это означает, что минимальная версия, поддерживаемая соответствующим SSH-сервером, - SSH1. Если удаленный сервер поддерживает только SSH2, scanssh отобразит «SSH-2.0-XXXX».

Читайте также: