Настройка ssh на cisco: Вы заблудились на сайте компьютерного мастера

Содержание

Cisco настройка ssh доступа

Поговорим о том как настроить ssh доступ на маршрутизаторы Cisco.

SSH (Secure SHell) — сетевой протокол прикладного уровня, используется для удалённого управление различным оборудованием и операционными системами, а также для туннелирование TCP-соединений для просмотра, редактирования и передачи файлов, шифрует весь передаваемый трафик.

По умолчанию для управления оборудованием cisco используется протокол telnet, который является незащищённым и передаёт данные и пароли в открытом виде. Для обеспечения безопастности сетевого оборудования Cisco рекомендуется отключать протокол telnet, а для управления использовать протокол ssh.

Настройку ssh доступа на оборудование cisco

Заходим в привилегированный режим.

router>enable

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

Устанавливаем точную текущую дату и время.

router#clock set 15:00:00 15 May 2018

Входим в режим конфигурирования.

cisco#configure terminal

Задаем домен, если у вас нет домена можно указать любой домен например cisco.com.

cisco(config)#ip domain name mydomain.ru

Задаем имя роутера.

cisco(config)#hostname mycisco

Задаем версию протокола ssh. Рекомендуется версия 2.

mycisco(config)# ip ssh version 2

Задаем количество попыток подключения по ssh.

mycisco(config)# ip ssh authentication-retries 2

Задаем хранение пароли в зашифрованном виде.

mycisco(config)#service password-encryption

Включаем протокол aaa.

mycisco(config)#aaa new-model

Создаем пользователя admin с паролем qwerty и максимальными уровнем привелегий 15.

mycisco(config)#username admin privilege 15 secret qwerty

Задаем пароль qwerty для привилегированного режима.

mycisco(config)#enable secret qwerty

Генерируем rsa ключ для ssh длиной желательно не менее 1024.

mycisco(config)#crypto key generate rsa
The name for the keys will be:
Choose the size of the key modulus in the range of 360 to 4096 for your
  General Purpose Keys. Choosing a key modulus greater than 512 may take
  a few minutes.
How many bits in the modulus [512]:1024

Разрешаем доступ по ssh только из определенной сети (192.168.1.0/24).

mycisco(config)#access-list 23 permit 192.168.1.0 0.0.0.255

Входим в режим конфигурирования терминальный линий.

mycisco(config)#line vty 0 4

Разрешаем доступ только по ssh.

mycisco(config-line)# transport input ssh

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

mycisco(config-line)# logging synchronous

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

mycisco(config-line)# privilege level 15

Включаем автоматическое закрытие ssh сессии через 30 минут.

mycisco(config-line)# exec-timeout 30 0

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

mycisco(config-line)# access-class 23 in

Выходим из режима конфигурирования.

mycisco(config-line)# end

Сохраняемся.

mycisco# copy running-config startup-config

Вот и все, включение ssh на оборудование Cisco закончено.

Первичная настройка коммутатора cisco ssh. Настройка SSH на Cisco

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

Подключение и настройка Cisco Catalyst 2960 имеет свои нюансы и несколько отличается от подключения оборудования других производителей. Первоначальная настройка потребует наличие фирменного плоского кабеля RJ-45–RS-232 (в голубой оплетке, поставляется с оборудованием) и присутствие на материнской плате компьютера COM-порта, через который будут выполняться процедуры настройки.

На материнских платах современных компьютеров COM-порт отсутствует, поэтому чтобы провести настройку потребуется специальный переходник. Компания Cisco в своем оборудовании для консоли использует разъемы Mini–USB. Чтобы провести настройку через порт Mini–USB следует скачать программу cisco usb console driver.

Настройка Гипер Терминала

Если процедура настройки выполняется с использованием операционной системы Windows 7/8, то возникнет проблема отсутствия HyperTerminal. Ее можно быстро решить, если скопировать нужную папку с ОС Windows XP в любой каталог ОС Windows 7/8. В Windows XP папка располагается в каталоге Program Files. Чтобы запустить программу используется файл hypertrm.exe, который располагается в этой же папке. Также может использоваться другая программа – Putty. Кроме подключения к оборудованию Cisco, ее используют для работы с маршрутизаторами, серверами, когда для их подключения нужна настройка SSH.

Чтобы выполнить процедуру коммутации кабель нужно подключить в разъем RJ-45, который на передней панели обозначен, как «Console». Дале нужно включить электропитание коммутатора и зайти в HyperTerminal на компьютере. В программе нужно выбрать интерфейс разъема, соответствующий COM1 и его скорость, равную 9600 Б/с. На все последующие вопросы следует выбирать отрицательный ответ «No». Если выбрать в интерфейсе разъема настройка VLAN, то на нем можно будет настроить IP-адресс устройства.

Общие принципы настройки Cisco-оборудования

Чтобы обеспечивать высокий уровень безопасности коммутаторы Cisco поддерживают два режима ввода команд:

пользовательский – используется для поверки состояния оборудования;
привилегированный – применяется для того, чтобы менять конфигурацию коммутатора (он является аналогом режима администратора для Windows или root для UNIX).

Если в строке перед командой есть символ «#», то активный привилегированный режим. Как и в системе UNIX при вводе пароля на экране он отображаться не будет. Чтобы перейти в привилегированный режим используется команда enable, а для выхода disable.

Первоначальная настройка коммутатора. Когда во время первой загрузки установочный мастер выдаст сообщение пошаговой настройки нужно от нее отказаться: Continue with configuration dialog? : no. После этого загрузится пользовательский режим: Switch>

Switch>enable

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

Базовые настройки Cisco 2960

Замена имени коммутатора (изначально оно Switch):

Switch# configure terminal

Switch(config)# hostname Switch01 (задается новое имя – Switch01)

Switch01(config)#

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

Установка IP-адреса для порта управления коммутатором

Switch01(config)# interface fa0/0 (задается интерфейс для настройки)

Switch01(config-if)# no shutdown (включается интерфейс)

Switch01(config-if)# ip address 192.168.0.1 255.255.255.0 (задается IP-адрес и маска)

Switch01(config-if)# exit (выход из режима конфигурации интерфейса)

Switch01(config)#

Установка пароля привилегированного режима

Switch01(config)# enable secret pass1234 (пароль pass1234)

Switch01(config)# exit

Учитывая, что информация при telnet-соединениях передается в открытом виде, нужно использовать SSH-соединения, которые обеспечат шифрование трафика.

Switch01# conf t Switch01(config)# ip domain name geek-nose.com (задается домен, если его нет пишется любой)

Switch01(config)# crypto key generate rsa (генерация RSA-ключа под ssh)

Switch01(config)# ip ssh version 2 (версия ssh-протокола)

Switch01(config)# ip ssh autentification-retries 3 (число попыток подключения по ssh)

Switch01(config)# service password-encryption (сохранение паролей в шифрованном виде)

Switch01(config)# line vty 0 2 (преход к режиму конф-и терминальных линий)

Switch01(config-line)# transport input ssh (подключение только по ssh)

Switch01(config-line)# exec timeout 20 0 (активация автоматического разъединения ssh-сессии через 20 минут)

Switch01(config-line)# end (Выход из режима конфигурирования)

Switch01# copy running-config startup-config (Сохранение настроек)

Это была базовая настройка SSH. Более продвинутая имеет вид:

Switch01# conf t Switch01(config)# aaa new-model (включается ААА–протокол)

Switch01(config)# username root privilege 15 secret pass1234 (создается пользователь root, с максимальным уровнем привилегий – 15, и паролем pass1234)

Switch01(config)# access-list 01 permit 192.168.0 0.0.0.255 (задается правило доступа с названием 01 по ssh для всех хостов сети 192.168.0.0/24; может задаваться конкретный IP-адрес)

Switch01(config)# line vty 0 2 (пееход к режиму конф-и терминальных линий) Switch01(config-line)# privilege level 15 (разрешение входа в привилегированный режим)

Switch01(config-line)# access-class 23 in (привязка созданного правила доступа по ssh к терминальной линии)

Switch01(config-line)# logging synchronous (отключение журнальных сообщений)

Switch01(config-line)# end (выход из режима конфигурирования)

Switch01# copy running-config startup-config (сохранение настроек).

Базовая настройка коммутатора Cisco 2960 на этом завершается. При потребности всегда можно сделать сброс на заводские настройки и выполнить настройки «с нуля».

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

Почему именно SSH для Cisco

SSH — это защищенный протокол, который станет помехой для подборщиков и взломщиков, которые захотят завладеть вашим сетевым оборудованием Cisco.

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

А для Cisco настройка протокола SSH осуществляется по особым правилам, не так, как создается удаленное управление сервером во Free BSD.

Как настроить SSH подключение для Cisco

Настройка начинается с того, что вам необходимо войти в привилегированный режим. Для этого воспользуйтесь следующей командой: cisco> enable. Лучше всего использовать публичный ключ для соединения с оборудованием, потому рекомендуется сгенерировать RSA. А для этого в Cisco необходимо установить точную дату и время, иначе ключ не сработает: cisco# clock set 17:10:00 28 Aug 2016. После этого переходите в непосредственный режим изменения конфигураций, который понадобится для создания подключения по SSH протоколу: cisco# configure terminal

Чтобы сформировать открытый ключ, вам нужно будет ввести имя домена, под которым клиент будет подключаться к сетевому оборудованию. Для этого воспользуйтесь командой: cisco(config)# ip domain name имя_домена.ру. Уже после этого можно генерировть RSA-ключ, используя следующую комбинацию: cisco(config)# crypto key generate rsa. Если вы хотите усилить защиту вашего сетевого оборудования, то можете воспользоваться дополнительными паролями, только активируйте предварительно их шифрование при помощи команды: cisco(config)# service password-encryption.

Далее вам предстоит создать пользователя, придумать для него пароль и указать уровень доступа: cisco(config)# username имя_пользователя privilege 15 password 7 пароль. Только после того, как вы заведете хотя бы одного пользователя в системе, можно будет запустить протокол AAA, используя следующую команду: cisco(config)# aaa new-model. А чтобы окончательно запустить терминальные линии по SSH протоколу, вам нужно зайти в их конфигурации. Для этого напишите: cisco(config)# line vty 0 4, где можете указать значение конфигураций от 0 до 4. После этого вы сможете активировать подключение по SSH протоколу — пропишите cisco(config-line)# transport input ssh.

Хоть вы уже и запустили терминальные линии по протоколу SSH, введите эту функцию для сохранения изменений: cisco(config-line)# logging synchronous, а также пропишите значение для таймаута сессии SSH: cisco(config-line)# exec-timeout 60 0. После этого выйдете из config-line и config. И напоследок добавьте новые конфигурации в систему сетевого оборудования Cisco: cisco# copy running-config startup-config. Все — работа сделана, теперь ваше оборудование будет работать по защищенному подключению SSH.

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

SSH (Secure Shell) — сетевой протокол, позволяющий производить удаленное управление сетевым оборудованием и туннелировать TCP-соединения. Для своей работы SSH использует 22 порт.

Перед тем, как установить соединение происходит аутентификация. Аутентификация — это процедура установления подлинности. При аутентификации предварительно генерируется пара открытого и закрытого ключа для определенного пользователя. Оба файла хранятся как на удаленной машине, так и на машине, к которой производится подключение. Эти файлы не передаются при аутентификации, система лишь проверяет, что пользователь открытого ключа также владеет и закрытым. Открытый ключ используется для проверки электронной цифровой подписи и шифрования сообщений. Закрытый ключ используется для генерации электронной цифровой подписи и расшифрования сообщений. Электронная цифровая подпись позволяет проверить отсутствие искажений информации, а также подтвердить владельца сертификата. Для шифрования данных и создания ЭЦП используется криптографический алгоритм RSA. Работа RSA основывается на вычислительной сложности задачи факторизации больших целых чисел. Более подробно данный алгоритм описан по ссылке . Мы же рассмотрим работу RSA поверхностно.

Боб и Алиса переписываются в Интернете и хотят использовать шифрование для хранения переписки в секрете. В RSA открытый и закрытый ключ состоят из пары чисел. Закрытый ключ хранится в секрете, а открытый сообщается. Алиса заранее сгенерировала закрытый и открытый ключ, а затем отправила открытый Бобу. Боб хочет послать сообщение Алисе. Боб шифрует сообщение m , используя открытый ключ Алисы (e, N). В итоге он получает зашифрованное сообщение c . Далее по каналу связи сообщение c передается Алисе. Алиса расшифровывает сообщение c с помощью своего закрытого ключа (d, N) и получает отправленное сообщение m . Таким образом, для того, чтобы расшифровать данные необходимо иметь закрытый ключ, который имеется только у отправителя. В этом и заключается суть работы данного алгоритма.

Настройка доступа по SSH к коммутатору и маршрутизатору Cisco

В Packet Tracer собрана схема.

Между ноутбуком и коммутатором подключены два кабеля: первый — консольный (голубой), второй — Ethernet (черный). Консольный кабель имеет два разъема: DB-9 — для подключения к COM-порту компьютера и RG-45 для подключения к консольному порту коммутатора.

Первоначальную настройку мы будем осуществлять именно через консоль, так как для доступа по SSH необходимо задать IP-адрес интерфейса, который в данный момент не задан. Тут стоит отметить один нюанс. Вообще коммутатор работает на канальном уровне эталонной модели OSI. Иными словами, коммутатор смотрит только Ethernet заголовок (который содержит лишь MAC-адрес) и не заглядывает вглубь IP заголовка (который находится выше). Тот IP-адрес, который мы будем задавать никак не связан с передачей данных, он будет нужен лишь для управления.

Настройка IP-адреса коммутатора подобна таковой у компьютера с одним интерфейсом Ethernet. С этой точки зрения у компьютера есть процессор, выполняющий операционную систему. У него есть плата сетевого интерфейса Ethernet (сетевая плата). Согласно конфигурации операционной системы, с сетевой платой связан IP-адрес, заданный вручную или полученный динамически от сервера DHCP. Коммутатор использует концепции, подобные хосту, за исключением того, что он может использовать виртуальную сетевую плату. Как и у компьютера, у коммутатора есть процессор, выполняющий операционную систему (Cisco IOS). Коммутатор использует концепцию, подобную сетевой плате, — коммутируемый виртуальный интерфейс (Swithced Virtual Interface — SVI) или более привычно — интерфейс VLAN, действующий как собственная сетевая плата коммутатора для подключения к локальной сети и передаче пакетов IP. Подобно хосту, настройка коммутатора подразумевает установку таких параметров IP, как IP-адрес для этого интерфейса VLAN.

Типичный коммутатор LAN Cisco уровня 2 может использовать только один интерфейс VLAN, но какой конкретно, выбирает сетевой инженер, перемещая управляющий трафик коммутатор на специфический интерфейс.

Заходим с ноута на коммутатор через консоль. Стандартные параметры лучше не менять без надобности.

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

Switch>enable — для перехода в расширенный режим Switch#configure terminal — для перехода в режим конфигурации

Для управления всеми сетевыми устройствами в сети мы будем использовать сеть 172.16.0.0/24 и VLAN 2. Перед настройкой коммутатор необходимо вручную задать IP-адрес ноутбука, маску сети и основной шлюз. Пусть для примера IP-адрес 172.16.0.5, маска 255.255.255.0, шлюз по-умолчанию 172.16.0.1. Далее я привожу конфигурацию коммутатора с комментариями.

Switch(config)#interface vlan 2 — переходим в настройки виртуального интерфейса Switch(config-if)#ip address 172.16.0.100 255.255.255.0 — настраиваем ip-адрес и маску VLAN 2 Switch(config-if)#no shutdown — административно включаем интерфейс Switch(config-if)#exit — выходим из режима конфигурирования vlan-интерфейса Switch(config)#ip default-gateway 172.16.0.1 — задаем шлюз по-умолчанию

Мы только что создали виртуальный интерфейс vlan 2, присвоили ему ip-адрес из пула ip-адресов для управления, административно перевили его в состояние up (включен) и также задали шлюз по-умолчанию, в качестве которого будет выступать маршрутизатор. Мы настроили виртуальный интерфейс. Теперь необходимо сконфигурировать физический интерфейс. Изначально все порты находятся в vlan 1. Наш ноутбук подключен к порту коммутатора fastEthernet 0/1. Таким образом, необходимо добавить в vlan 2 порт fastEthernet 0/1.

Switch(config)#interface fastEthernet 0/1 — переходим в настройки физического интерфейса Switch(config-if)#description admin — описание интерфейса (подключен админ) Switch(config-if)#switchport mode access — переводим порт в режим доступа Switch(config-if)#switchport access vlan 2 — добавляем порт во 2 vlan. Switch(config-if)#exit

Теперь все готово для настройки SSH.

Switch(config)#username user secres pass — заводим пользователя user с паролем pass Switch(config)#enable secret pass — защищаем привилигированный режим Switch(config)#line vty 0 4 — переходим в настройки виртуальных линий (5 сессий) Switch(config-line)#login local — авторизация по имени и паролю (из локальной базы) Switch(config-line)#transport input ssh — разрешаем доступ только по SSH Switch(config-line)#exec-timeout 0 60 — при бездеятельности отключаем от консоли через 60 сек. Switch(config-line)#logging synchronous — убираем всплывающие сообщения-уведомления Switch(config-line)#exit Switch(config)#ip ssh version 2 — ставим последнюю версию SSH Switch(config)#ip domain-name Switch — указываем доменное имя Switch(config)#crypto key generate rsa — генерируем ключи (1024 kb)

На этом в принципе все. С ноута заходите в консоль и подключаетесь к свитчу

ssh -l user 172.16.0.100

Далее настроим доступ к маршрутизатору. Маршрутизатор подключен не напрямую. Для доступа к нему необходимо, чтобы коммутатор пропускал vlan 2 через порт fastEthernet 0/2. Настроим порт fastEthernet 0/2 как транковый (тегированный) и добавим vlan 2.

Switch(config)#interface fastEthernet 0/2 Switch(config-if)#switchport mode trunk Switch(config-if)#switchport trunk allowed vlan 2 Switch(config-if)#exit

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

Router(config)#interface fastEthernet 0/0 Router(config-if)#description Switch Router(config-if)#no shutdown Router(config-if)#exit Router(config)#interface fastEthernet 0/0.2 — создаем сабинтерфейс (виртуальный интерфейс) Router(config-subif)#encapsulation dot1Q 2 — тегируем 2 vlan Router(config-subif)#ip address 172.16.0.1 255.255.255.0 — задаем ip-адрес и маску Router(config-subif)#exit

Тут может возникнуть вопрос по поводу команды encapsulation dot1Q 2. Эта команда обозначает, что все кадры, попадающие на интерфейс fastEthernet 0/0 с тегом vlan 2 будут попадать на сабинтерфейс fastEthernet 0/0.2. А все кадры, которые будут уходить с этого сабинтерфейса — помечаются тегом vlan 2. Остальные настройки маршрутизатора абсолютно аналогичны тому, что мы делали ранее.

Router(config)#username user secres pass — заводим пользователя user с паролем pass Router(config)#enable secret pass — защищаем привилигированный режим Router(config)#line vty 0 4 — переходим в настройки виртуальных линий (5 сессий) Router(config-line)#login local — авторизация по имени и паролю (из локальной базы) Router(config-line)#transport input ssh — разрешаем доступ только по SSH Router(config-line)#exec-timeout 0 60 — при бездеятельности отключаем от консоли через 60 сек. Router(config-line)#logging synchronous — убираем всплывающие сообщения-уведомления Router(config-line)#exit Router(config)#ip ssh version 2 — ставим последнюю версию SSH Router(config)#ip domain-name Router — указываем доменное имя Router(config)#crypto key generate rsa — генерируем ключи (1024 kb)

___________________________

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

Настройка SSH на Cisco. Обязательные параметры.

Для включения SSH в Cisco IOS необходимо выполнить следующие 5 обязательных шагов.

1. Задать имя устройства при помощи команды hostname

(config)#hostname sw01

2. Задать имя пользователя и пароль

(config)#username Admin1 secret 5 $1$ukk…

3. Настроить DNS домен при помощи команды ip domain-name

(config)#ip domain-name domain.ru

4. Сгенерировать RSA ключ для использования SSH на устройстве.

Для этого используется команда

(config)#crypto key generate rsa

Проверить ключ можно при помощи команды:

#show crypto key mypubkey rsa

При наличии ключа, будет отображено его имя и дата создания:

% Key pair was generated at: 00:07:18 YEKT Jul 31 2014
Key name: sw01.domain.ru
Usage: Encryption Key
Key Data:
xxxxxxxx xxxxxxxx xxxxxxxx …

5. Разрешить поддержку SSH для виртуального терминала

(config)#line vty 0 4 (config-line)#transport input ssh (config-line)#login local (если не используется aaa new-model в пункте 2)

Настройка SSH на Cisco. Необязательные параметры.

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

1. Версия протокола SSH.

Используем 2-ю версию.

(config)#ip ssh version 2

2. Количество попыток аутентификации

Ограничение количества попыток аутентификации используется для предоствращения перебора пароля

(config)#ip ssh authentication-retries 2

3. Логирование событий протокола SSH

(config)#ip ssh logging events

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

1w5d: %SSH-5-SSh3_SESSION: SSh3 Session request from 192.168.1.2 (tty = 0)
using crypto cipher «aes128-cbc», hmac «hmac-md5» Succeeded
1w5d: %SSH-5-SSh3_USERAUTH: User «Admin1» authentication for SSh3 Session
from 192.168.1.2 (tty = 0) using crypto cipher «aes128-cbc», hmac «hmac-md5»
Succeeded

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

1w5d: %SSH-5-SSh3_USERAUTH: User «User» authentication for SSh3 Session from
192.168.1.2 (tty = 0) using crypto cipher «aes128-cbc», hmac «hmac-md5» Failed

4. Изменяю входящий порт SSH сервера на нестандартный.

Итак, настройки SSH закончены. Теперь можно скачать Putty с официального сайта и наслаждаться удаленным управлением Cisco!

Проверка настроек SSH на Cisco

Для проверки настроек используем команду show ip ssh, которая отображает статус и версию SSH сервера, а также некоторые параметры аутентификации.

Sw01.domain.ru#show ip ssh
SSH Enabled — version 2.0
Authentication timeout: 120 secs; Authentication retries: 3

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

Sw01.domain.ru#show ssh
%No SSHv1 server connections running.
Connection Version Mode Encryption Hmac State Username
0 2.0 IN aes128-cbc hmac-md5 Session started Admin1
0 2.0 OUT aes128-cbc hmac-md5 Session started Admin1
1 2.0 IN aes128-cbc hmac-md5 Session started Admin2
1 2.0 OUT aes128-cbc hmac-md5 Session started Admin2

В статье рассмотрен процесс настройки и проверки SSH сервера на коммутаторах и маршрутизаторах Cisco. Приятной работы!

Компания Cisco — одна из ведущих транснациональных корпораций на рынке телекоммуникационного оборудования.

Продукция компании Cisco получила признание во всем мире из-за своей надежности и неприхотливости.

Настройка Cisco 2960: в этой статье мы выполним базовую настройку коммутатора. Статья будет полезна всем, начинающим работать с продукцией компании Cisco.

Шаг 1. Подключение оборудования Cisco

Настройка оборудования Cisco весьма специфична и несколько отличается от оборудования .

Например, для выполнения первичных настроек коммутаторов компании Cisco , нам потребуется фирменный плоский кабель RJ -45 – RS -232 голубого цвета (идет в комплекте с оборудованием) и наличие COM -порта на компьютере, с которого будет производиться настройка.

Решением вопроса является копирование папки HyperTerminal c Windows XP (месторасположение каталога – Program Files ) в любой удобный каталог Windows 7/8 .

Для запуска программы используется файл hypertrm .exe , который можно найти в той же папке.

Либо использовать программу Putty , которую помимо подключения к Cisco -оборудованию можно использовать для подключения к серверам, пр. с помощью SSH -подключения.

Переходим к подключению. На передней панели коммутатора ищем разъем RJ -45 с подписью «Console », и подключаем кабель.

Включаем питание коммутатора.

Заходим на компьютере в HyperTerminal, выбираем интерфейс разъема (COM1), скорость порта – 9600 Б/с, на все дальнейшие вопросы даем отрицательный ответ («No »).

Шаг 3. Общие принципы настройки оборудования Cisco

В целях безопасности на коммутаторах Cisco доступно 2 режима ввода команд: пользовательский режим для проверки состояния коммутатора и привилегированный режим (аналог пользователя root в UNIX или администратора в Windows) для изменения конфигурации коммутатора.

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

Для пользователей, работающих в Windows дадим пояснение, — если строка перед командной начинается с символа «#», вы в привилегированном режиме.

То же самое касается ввода пароля, как и в UNIX-системах, пароль, который вводит пользователь не отображается на экране.

Для перехода в привилегированный режим служит команда «enable», без кавычек, а для выхода «disable».

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

Continue with configuration dialog? : no

После чего оказываемся в пользовательский режиме:

Переходим в привилегированный режим, пароль по умолчанию, как правило, отсутствует, поэтому ничего не вводим, а нажимаем «Enter».

Switch> enable

Для задания настроек, касающихся всего коммутатора (задание имени коммутатора, IP-адреса , указание сервера синхронизации времени, пр), используется режим глобальной конфигурации, для настройки отдельных интерфейсов существует режим конфигурации интерфейса.

Шаг 4. Базовая настройка Cisco 2960

1. Изменим имя нашего коммутатора (по умолчанию имя Switch):

Switch# configure terminal

Switch(config)# hostname Switch01 (Задаем имя коммутатора – Switch01)

Switch01(config)#

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

Также обращаем ваше внимание на то, что вместо длинных команд как, например, «configure terminal» существуют их короткие аналоги «conf t».

2. Зададим IP-адрес для интерфейса управления коммутатором.

Switch01(config)# interface fa0/0 (указываем интерфейс для настройки)

Switch01(config-if)# no shutdown (включаем интерфейс)

Switch01(config-if)# ip address 255.255.255.0 (задаем IP- адрес и маску)

Switch01(config-if)# exit (выходим из режима конфигурации интерфейса)

Switch01(config)#

3. Установим пароль для привилегированного режима:

Switch01(config)# enable secret pass1234 (пароль pass1234)

Switch01(config)# exit

Switch 01#

Важно! Установка пароля может быть выполнена двумя командами password и secret. В первом случае пароль хранится в конфигурационном файле в открытом виде, а во втором в зашифрованном. Если использовалась команда password , необходимо зашифровать пароли, хранящиеся в устройстве в открытом виде с помощью команды «service password-encryption» в режиме глобальной конфигурации.

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

Switch01# conf t

Switch 01(config )# ip domain name geek -nose .com (Указываем домен, если домена нет пишем любой)

Switch01(config)# crypto key generate rsa (Выполняем генерацию RSA- ключа для ssh)

Switch01(config)# ip ssh version 2 (Указываем версию ssh- протокола)

Switch01(config)# ip ssh autentification-retries 3 (Задаем кол- во попыток подключения по ssh)

Switch01(config)# service password-encryption (Сохраняем пароли в зашифрованном виде)

Switch 01(config )# line vty 0 2 (Переходим в режим конф-и терминальных линий)

Switch01(config-line)# transport input ssh (Разрешаем подключение только по ssh)

Switch01(config-line)# exec timeout 20 0 (Активируем автоматическое разъединение ssh- сессии через 20 минут)

Switch 01(config -line )# end (Выходим из режима конфигурирования)

Switch01# copy running-config startup-config (Сохраняем настройки)

Важно! Для выхода из подменю конфигурирования на 1 уровень выше, например, из «config -line » в «config » используется команда «exit ». Для полного выхода из режима конфигурирования используйте команду «end ».

Выше была описана базовая настройка ssh , с более продвинутой настройкой можно ознакомиться ниже:

Switch01# conf t

Switch01(config)# aaa new-model (Включаем ААА- протокол )

Доступ по протоколу SSH к оборудованию Cisco.

Настройка SSH на Cisco. Обязательные параметры.

Для включения SSH в Cisco IOS необходимо выполнить следующие 5 обязательных шагов.

1. Задать имя устройства при помощи команды hostname

(config)#hostname sw01

2. Задать имя пользователя и пароль

(config)#username Admin1 secret 5 $1$ukk…

3. Настроить DNS домен при помощи команды ip domain-name

(config)#ip domain-name domain.ru

4. Сгенерировать RSA ключ для использования SSH на устройстве.

Для этого используется команда

(config)#crypto key generate rsa

Проверить ключ можно при помощи команды:

#show crypto key mypubkey rsa

При наличии ключа, будет отображено его имя и дата создания:

% Key pair was generated at: 00:07:18 YEKT Jul 31 2014
Key name: sw01.domain.ru
Usage: Encryption Key
Key Data:
xxxxxxxx xxxxxxxx xxxxxxxx …

5. Разрешить поддержку SSH для виртуального терминала

(config)#line vty 0 4 (config-line)#transport input ssh (config-line)#login local (если не используется aaa new-model в пункте 2)

Настройка SSH на Cisco. Необязательные параметры.

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

1. Версия протокола SSH.

Используем 2-ю версию.

(config)#ip ssh version 2

2. Количество попыток аутентификации

Ограничение количества попыток аутентификации используется для предоствращения перебора пароля

(config)#ip ssh authentication-retries 2

3. Логирование событий протокола SSH

(config)#ip ssh logging events

1w5d: %SSH-5-SSh3_USERAUTH: User «User» authentication for SSh3 Session from
192.168.1.2 (tty = 0) using crypto cipher «aes128-cbc», hmac «hmac-md5» Failed

4. Изменяю входящий порт SSH сервера на нестандартный.

Проверка настроек SSH на Cisco

Sw01.domain.ru#show ip ssh
SSH Enabled — version 2.0
Authentication timeout: 120 secs; Authentication retries: 3

Почему именно SSH для Cisco

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

Как настроить SSH подключение для Cisco

Если вы работаете в IT, то наверняка тысячу раз сталкивались с необходимостью зайти на какое-то устройство или сервер удалённо – такая задача может быть выполнена несколькими путями, основные два для управления устройством через командную строку – Telnet и Secure Shell (SSH) .

Между ними есть одно основное различие – в протоколе Telnet все данные передаются по сети в незашифрованном виде, а в случае SSH все команды шифруются специальным ключом. SSH был разработан как замена Telnet, для безопасного управления сетевыми устройствами через небезопасную сеть, такую как Интернет. На всякий случай запомните, что Telnet использует порт 22 , а SSH – 23 .

Настройка

Для начала, вам понадобится Packet Tracer – программа для эмуляции сетей от компании Cisco. Он полностью бесплатен и его можно скачать с сайта netacad.com после регистрации. Запустите Packet Tracer и приступим к настройке.

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

Готово? Теперь обеспечим сетевую связность и настроим интерфейс vlan 1 на коммутаторе, для этого введите следующие команды:

Если сразу после создания в консоли коммутатора будет вопрос начать ли диалог изначальной настройки – ответьте «No».

en conf t interface vlan 1 ip address 192.168.1.1 255.255.255.0 no shutdown

Теперь давайте попробуем пингануть коммутатор и зайти на него по протоколу telnet с нашего ПК на коммутатор – и вы увидите, что соединение будет отклонено по причине того, что мы еще не настроили аутентификацию на коммутаторе.

Перейдем к настройке аутентификации. Система поддерживает 20 виртуальных tty/vty линий для Telnet, SSH и FTP сервисов. Каждая сессия, использующая вышеупомянутый протокол занимает одну линию. Также можно усилить общую безопасность с помощью валидации запросов на авторизацию на устройстве. Перейдите обратно в режим общей конфигурации (conf t ) на коммутаторе с помощью команды exit и введите следующие команды:

Line vty 0 15 password cisco login end

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

Теперь снова попробуйте зайти по Telnet на свитч – все должно получиться! Однако, при попытке перейти к настройке и выполнении команды enable вы увидите, что это невозможно, по причине того, что не установлен пароль на глобальный режи enable .

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

Conf t enable password cisco

Попробуйте еще раз – теперь все должно получиться!

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

Вводим следующие команды (из основного конфигурационного режима):

Hostname merionet_sw1 ip domain name merionet crypto key generate rsa

Выбираем длину ключа – по умолчанию значение стоит равным 512 битам, для SSH версии 2 минимальная длина составляет 768 бит. Генерация ключа займет некоторое время.

После генерации ключа продолжим настройку коммутатора:

Ip ssh version 2 line vty 0 15 transport input ssh

Теперь зайти по протоколу Telnet уже не выйдет, так как мы заменили его на SSH. Попробуйте зайти по ssh, используя логин по умолчанию – admin. Давайте-ка поменяем его на что-то поприличнее (опять из conf t):

Username admin secret cisco line vty 0 15 login local do wr

Теперь попробуйте зайти с рабочей станции на коммутатор и удостоверьтесь, что новые настройки вступили в силу.

Пожалуйста, расскажите почему?

Нам жаль, что статья не была полезна для вас:(Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

Устанавливаем SSH

Для сетевого оборудования этот шаг не нужен – поддержка SSH практически всегда интегрирована даже в самый минималистичный вариант ОС. Исключением можно считать разве что достаточно старые Cisco IOS варианта W/O CRYPTO.

Данный вариант IOS – с осознанным удалением всех даже малозначительных следов того, что относится к криптографии (вплоть до отсутствия (config)#enable secret) был нужен для экспорта в страны с жёстким законодательством в плане ввоза криптографии. Это, кстати, не только очевидные Куба + Северная Корея + Сирия + Иран, но и, например, Австралия.

Если у вас подобный IOS – это может быть, к примеру, на Catalyst 2950, которые хоть и древние, но вполне могут попадаться в production – обновите его. Без обновления нужные для SSH features, в частности:

Secure Shell SSH Version 1 Integrated Client;
Secure Shell SSH Version 1 Server Support;
Secure Shell SSH Version 2 Server Support;

будут физически отсутствовать в составе IOS.

Добавление поддержки SSH в Windows Server

Начиная с Windows Server 2016 build 1709, поддержка SSH добавлена в платформу Windows.

Включить её несложно.

Первым делом – выясним, какая версия клиента и сервера OpenSSH есть в доступных для установке репозиториях прямо сейчас. Это нужно, чтобы когда версии пойдут увеличиваться (на момент написания версия одна, 1.0), то мы не получали бы проблем вида “что-то скрипт, ставящий конкретную версию, не срабатывает”. Сделаем это вот таким командлетом:

Get-WindowsCapability -Online | ? Name -like «OpenSSH*»

У меня Windows Server 2019, поэтому вывод выглядит так:

Видим, что SSH-клиент уже установлен изначально, а SSH-сервер – нет. У Windows Server 2016 вывод будет чуть другой, там ничего не установлено изначально. ОК, будем ставить SSH-сервер:

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

Клиент, как понятно, если отсутствует, то ставится аналогично. Тильд – четыре штуки, не опечатайтесь.

Если получили ошибку 0x800f0950 , не отчаивайтесь – это просто Feature-On-Demand не может найти репозиторий. Попробуйте через старый добрый DISM:

dism /Add-Capability /CapabilityName:OpenSSH.Server~~~~0.0.1.0 /LimitAccess /Online

Проверим, что всё установилось:

Get-Service sshd

ну либо просто запросим ещё раз Get-WindowsCapability -Online | ? Name -like «OpenSSH*» :

Если всё ОК, то сервис sshd у нас появился – правда, остановленный. Не включайте его сразу – вначале надо провести минимальные настройки, про которые будет в соответствующем разделе статьи.

Фиксируем версию SSHv2

Стартовый зоопарк версий SSH – SSH 1.3, потом SSH 1.5, потом “специальная версия от Cisco, показывающая, что сервер умеет и 2.0 и предыдущие”, которая 1.99 – сейчас совершенно не актуален, т.к. весь софт умеет SSHv2. Найти ПО, которое поддерживает только SSH 1.x – реально сложная задача. Поэтому, конечно, убедитесь, что такого ПО у вас нет, и обновите при необходимости – но рассматривать мы будем функциональность и безопасность только второй версии SSH.

Включаем SSH 2.х в Cisco IOS

Фиксируется она просто – для Cisco IOS это будет команда:

atraining(config)#ip ssh version 2

Если на данный момент вы ещё не создали ни одной ключевой пары, пригодной для работы SSHv2, то будет примерно такое сообщение:

Please create RSA keys to enable SSH (and of atleast 768 bits for SSH v2).

Это не страшно, разве что заметим, что у SSHv2 есть “нижние” требования по длине ключа в ключевой паре. Впрочем, мы не будем пытаться создать ключи, не подпадающие под это ограничение – времена, когда например 512ти битовые ключи RSA активно использовались, ушли.

Если ключи ещё не созданы, то делается это просто:

atraining(config)#crypto key generate rsa modulus 2048 label SSH_KEYS

Параметры несложны – rsa задаст алгоритм (в новых IOS добавляется вариант ec), modulus – битовую длину (можете выставить её в 4096, так будет, безусловно, безопаснее), метка label – чтобы создать “именованную для конкретного назначения” ключевую пару.

В ряде версий Cisco IOS есть ограничение на хранимые ключевые пары – до 10 на устройство и до 2 на пользователя – поэтому может быть выведено предупреждение типа “внимание, новая ключевая пара затрёт предыдущую” . Отслеживайте это.

Теперь скажем SSH, чтобы он использовал именно эту пару:

atraining(config)#ip ssh rsa keypair-name SSH_KEYS

Если всё ОК, нам выведется примерно такое:

%SSH-5-DISABLED: SSH 2.0 has been disabled
%SSH-5-ENABLED: SSH 2.0 has been enabled

Это будет обозначать, что переключение с “какие попало ключи” на “явно указанная пара” произошло успешно.

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

atraining(config)#line vty 0 5 (или line vty 0 15 – зависит от модели)

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

atraining(config-line)#transport input ssh

Включаем SSH 2.х в Cisco NX-OS

С Cisco Nexus’ами будет просто – они поддерживают только SSH 2.x, поэтому дополнительных действий по ограничению возможности подключения старыми версиями SSH – не нужно.

Не забудьте разве что явно включить использование SSH:

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

atraining-nx(config)#no feature ssh

atraining-nx(config)#ssh key rsa 2048

atraining-nx(config)#feature ssh

Параметры у ssh key тривиальны, разве что замечу, что автоматически перезаписываться старые ключи не будут, если надо, чтобы перезаписались – добавьте в конце команды force

Включаем SSH 2.х в sshd

В настройках sshd нам надо будет добавить (либо заменить) строку:

Включаем SSH 2.х в Windows Server

В каталоге %WINDIR%\System32\OpenSSH\ будет стандартный файл конфигурирования OpenSSH, sshd_config_default – и там в теории может быть настройка про “только вторую версию”, но по факту всегда используется только SSHv2. Поэтому специального действия для включения SSHv2 на Windows Server нет.

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

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

SSH поддерживает несколько вариантов подтверждения подлинности узла, к которому идёт подключение – с использованием алгоритмов DSA, ECDSA, RSA и распространённой эллиптической кривой 25519.

DSA нам сразу не нравится, т.к. он умеет только ключи по 1024 бита и есть мнение, высказанное тов.Сноуденом, что NSA не просто так активно любит DSA.

Поэтому сразу отсечём вариант использования DSA.

Фиксируем в Cisco IOS использование RSA для host identification

У Cisco это будет просто:

atraining(config)#ip ssh server algorithm hostkey ssh-rsa

Фиксируем алгоритмы host identification у sshd

В настройках sshd нам надо будет пойти в папку /etc/sysconfig/sshd и там поправить строку AUTOCREATE_SERVER_KEYS:

AUTOCREATE_SERVER_KEYS=»RSA ED25519″

Как понятно, это настройка “в вариантах каких алгоритмов ключи хоста автогенерить”. Замечу, что если стоит задача высокой надёжности, то 4096ти битовый RSA – это правильный выбор, а если скорости – то EC 25519 будет предпочтительнее.

После этого зайдём в каталог настроек sshd – в нашем варианте это будет /etc/ssh – и удалим там файлы неиспользуемых алгоритмов с ключами хоста. То есть из списка вида:

ssh_host_dsa_key
ssh_host_dsa_key.pub
ssh_host_ecdsa_key
ssh_host_ecdsa_key.pub
ssh_host_rsa_key
ssh_host_rsa_key.pub
ssh_host_ed25519_key
ssh_host_ed25519_key.pub

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

Если боитесь удалить лишнее – не бойтесь, при запуске сервис sshd прочитает конфигурационный файл и создаст отсутствующие, если надо.

После этого в конфигурационном файле надо найти директивы об использовании этих файлов с ключами – выглядят они (директивы) обычно так:

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

и оставить только нужные, закомментировав остальные путём добавления символа # (диез) перед строками.

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

Например, если оставить только модный Ed25519, а RSA выключить, то широко используемый PuTTY может говорить примерно такое:

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

Оставив только нужные типы ключей – обычно это ED25519 и RSA – нужно пересоздать их вручную, т.е. отдавать на откуп “пусть сервер сам это сделает на следующем рестарте сервиса” – не очень хорошая идея.

Делается это так:

Для Ed25519: ssh-keygen -t ed25519 -f ssh_host_ed25519_key -N «»

Для RSA: ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key -N «»

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

Ограничиваем протоколы для подтверждения подлинности SSH в Windows Server

Схема та же – идём в файл sshd_config_default и там оставляем только:

HostKey ssh_host_rsa_key
HostKey ssh_host_ed25519_key

Если надо и Ed25519 и RSA, или вообще только Ed25519. После – генерим ключи:

Для Ed25519: .\ssh-keygen -t ed25519 -f ssh_host_ed25519_key

Для RSA: .\ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key

.\ssh-add ssh_host_ed25519_key

В принципе всё, сервис sshd можно запускать.

Фирменный костыль от Microsoft

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

Install-Module -Force OpenSSHUtils

Repair-SshdHostKeyPermission -FilePath

Оно потребует NuGet и в общем … смотрите сами:

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

Теперь про обмен ключевой информацией.

Настройка обмена ключами / создания ключевого материала

Вариантов DH, или алгоритма Диффи-Хеллмана-Меркля – множество. Не углубляясь в данной статье в матчасть по самому алгоритму, посмотрим, как нам можно укрепить фронт с этой стороны.

Обмен ключами и совместная генерация ключевого материала для конкретной сессии – очень серьёзная тема в безопасности. Наша задача – избежать варианта, когда у нас будет возможен сценарий “аутентификация стойкая, а обмен ключами нет”.

Посмотрим, как сейчас у нас настроен DH в SSH на Cisco IOS:

atraining#sh ip ssh | inc Diffie

Minimum expected Diffie Hellman key size: 1024 bits

Плохо. Надо не ниже 2048 бит. Задаём это командой:

atraining(config)#ip ssh dh min size 2048

Поэтому выбирайте сами – SHA-512, при поддержке его на всём используемом оборудовании, будет лучшим выбором.

Но есть одна тонкость – режим использования хэша и шифрования.

По умолчанию SSH использует вариант, называемый Encrypt-and-MAC – к зашифрованным данным добавляется MAC, который считался от незашифрованных. В этом случае для проверки MAC надо вначале расшифровать принятый блок информации, чтобы получить plaintext, а после уже посчитать и сравнить хэши. Такой вариант делает возможными атаки на алгоритмы шифрования и получение “промежуточных” данных в случае компрометации целевой системы.

Лучшим вариантом с точки зрения безопасности будет Encrypt-Then-MAC. Почему? В случае, когда используется схема “хэш от уже зашифрованного”, первым делом проверяется целостность, и если что-то не так – данные сразу отбрасываются; никакой пробной расшифровки не происходит. Такие варианты MAC будут иметь суффикс -etm . С учётом этих моментов наша конфигурация будет выглядеть так:

MACs [email protected],[email protected]

В Cisco IOS тип MAC будет задаваться так:

atraining(config)#ip ssh server algorithm mac hmac-sha1

У Cisco IOS выбор небогатый – hmac-sha1 и hmac-sha1-96 . Второй вариант с урезанием выхода SHA-1 со 160 бит до 96 (как в ipsec) нам не подойдёт, потому что считается он с той же скоростью (считать-то все равно надо обычный SHA-1), а экономия трафика – ну, кхм, вообще никакая.

MAC для подсчёта fingerprint’а ключа

В OpenSSH мы также можем задать алгоритм, которым будет высчитываться “отпечаток” – fingerprint ключа. По умолчанию используется MD5 – однако будет лучше явно указать, что для отображения и сравнения хэшей ключей лучше использовать SHA-2/256:

FingerprintHash sha256

Теперь перейдём от криптографической части к сетевой.

Сетевые настройки SSHv2

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

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

Port 22
AddressFamily inet
IgnoreRhosts yes
UseDNS no
ListenAddress x.x.x.x
TCPKeepAlive yes
#VerifyHostKeyDNS no
#UseRoaming no

Часть настроек понятна – например Port 22 привязывает сервис SSH к указанному номеру порта, который можно при необходимости изменить – как минимум, чтобы боты-подбиратели-паролей не стучались, а ListenAddress явно указывает, на каких L3-адресах принимать запросы на подключение (ограничение актуально в случае нескольких адресов и/или сетевых интерфейсов, либо в сценарии “у хоста могут появляться на ходу новые сетевые интерфейсы, и это не значит, что на них надо ждать SSH-подключений”). Другие же настройки менее очевидны.

AddressFamily inet говорит о том, что мы будем ждать подключений только по IPv4. Если у вас используется IPv6 и подключения к SSH-серверу возможны по нему – добавьте AddressFamily inet,inet6 .

TCPKeepAlive yes будет нужен, чтобы на сетевом уровне определять отключившихся пользователей и прекращать их сеансы. Выключение этого механизма, которое иногда рекомендуется “для экономии трафика” (слёзы, а не экономия) приведёт к ситуации, когда ssh не сможет в ряде случаев понять, что пользователь не просто неактивен, а уже никогда не сможет продолжить работу в данной сессии. Поэтому включаем.

IgnoreRhosts yes отключает древний механизм создания списка узлов (обычно в файле.rhosts), с которых возможен вход без аутентификации.

UseDNS no будет нужна, чтобы отключить проверку PTR-записи у подключающегося абонента – помимо того, что во внутренней сети, да и при подключении из внешних тоже наличие PTR совершенно необязательно, данная мера лишь замедляет подключение, а уровень безопасности не поднимает – максимум, что делает – пишет в журнал warning про “подключающийся не сказал своё настоящее FQDN-имя”. Хотя возможна ситуация, когда проверка эта включена, а DNS на узле не работает (например, указывает на неправильный IP-адрес DNS-сервера) – в этом случае возможен сценарий, что подключиться к узлу не получится. Но это совсем не “защитная мера” а, скорее, ещё одна причина отключать эту проверку, т.к. из-за неё, получается, растёт количество задействованных подсистем, а следовательно падает общая надёжность работы системы.

Используется, то отключать его не надо. Это по своей логике клиентская настройка, но почему-то иногда встречаются мысли “включить её на сервере”. Я её добавил в этот список и закомментировал, чтобы подчеркнуть данный момент – не нужно в настройках сервера эту опцию указывать.

UseRoaming no выключает поддержку роуминга – экспериментального расширения OpenSSH, которое должно было обрабатывать сценарии вида “начал админить из одного места, потом перешёл в другое и продолжил оттуда”. По факту функционал этот оказался никому не нужен и никаких прорывных нововведений не добавил, а вот проблемы безопасности – вплоть до уязвимостей с PoC – принёс. Поэтому в явном виде отключаем. Как и предыдущий параметр – клиентский, т.е. здесь приведён потому что опять же в ряде гайдов пишется “выключите везде, и на клиенте, и на сервере”. Это не так, только на клиенте.

Ограничения SSH на процедуру подключения к сеансу

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

Блок наших настроек про всё это будет выглядеть так:

RhostsRSAAuthentication no
PubkeyAuthentication no
HostbaseAuthentication no
ChallengeResponseAuthentication no
KerberosAuthentication no
PasswordAuthentication yes

LoginGraceTime 15

ClientAliveInterval 1800
ClientAliveCountMax 0

MaxAuthTries 3
MaxSessions 1
PermitTunnel no

MaxStartups 10:50:20
ShowPatchLevel no

Разберёмся, что и как.

Блок из RhostsRSAAuthentication no , PubkeyAuthentication no , HostbaseAuthentication no , ChallengeResponseAuthentication no , KerberosAuthentication no отключает неиспользуемые методы аутентификации. Безусловно, если вы используете для входа на SSH-сервер, допустим, Kerberos, то отключать Kerberos не нужно. Но в типовом сценарии, когда вход осуществляется более распространёнными способами, лишнее надо в явном виде отключать.

Параметр LoginGraceTime говорит о том, сколько времени пользователю можно потратить на процедуру входа. По умолчанию – 2 минуты. Это очень много. Очень медленный пользователь должен быть, чтобы столько времени ему требовалось на вход. Поэтому этот параметр выставляется в 15 – за 15 секунд войти можно. Если надо дольше – можно увеличить, но разумно. Важнее то, что сервер будет быстрее “сбрасывать” сессии, которые начались, но ещё не завершили аутентификацию, и экономить ресурсы.

Аналог LoginGraceTime в Cisco IOS – это команда atraining(config)#ip ssh time-out , задающая максимальное время для процедуры входа. По умолчанию также 2 минуты и это также многовато и надо уменьшать. В случае с Cisco NX-OS это будет atraining-nx(config)#ssh login-gracetime .

Пара настроек ClientAliveCountMax и ClientAliveInterval будет нужна, чтобы определять, когда надо отключать неактивного клиента. ClientAliveInterval – время неактивности в секундах, через которое клиента отключат, а ClientAliveCountMax – количество попыток “разбудить” клиента. В нашем случае клиента отключат через полчаса неактивности.

Параметр MaxAuthTries говорит, через сколько попыток неудачной аутентификации (например, ввода неверного пароля) сессия будет отключена сервером. По умолчанию это 6, многовато. Трёх раз хватит.

Аналог MaxAuthTries в Cisco IOS – команда atraining(config)#ip ssh authentication-retries , с умолчанием в 3 попытки.

Параметр MaxSessions показывает, сколько сессий внутри одного SSH-подключения можно инициализировать. Это не ограничение на “параллельные сессии с одного хоста”! Это именно “поставил SSH-трубу до сервера и внутри неё мультиплексируешь много сессий с форвардингом данных”. Если вам такой сценарий не нужен – когда подключаетесь до сервера X и через него форвардите трафик вглубь сети, то хватит и единицы – а надо именно подключаться к конкретному серверу и его администрировать, то MaxSessions 1 , да. Параметр PermitTunnel no будет довершать конфигурирование режима “ssh только для администрирования сервера, к которому подключаемся”.

MaxStartups 10:50:20 – это WRED-подобный механизм, про семейство которых обсуждается на и логика его конфигурирования будет следующей – первое и последние значения – это стартовое количество подключений (речь только про подключения, которые не прошли аутентификацию), начиная с которых механизм начнёт работать и максимальное количество подключений, возможных вообще (в нашем случае механизм включится, когда к серверу будет 10 подключений, а 21е подключение будет технически невозможно), а средний параметр – это вероятность в процентах. У нас она 50, т.е. мы будем отказывать в половине случаев, когда количество “висящих на фазе аутентификации” сессий будет от 10 до 20.

Можно сделать и проще – например, MaxStartups 10 , т.е. задать MaxStartups с одним параметром. Это просто укажет максимальное число параллельно аутентифицирующихся сессий.

Аналог MaxStartups N с одним параметром в Cisco IOS – это команда atraining(config)#ip ssh maxstartups N , где N – то же самое максимальное число параллельно аутентифицирующихся сессий.

Командой ShowPatchLevel no мы выключим публикацию детальной информации о версии SSH подключающемуся клиенту.

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

Группы и пользователи в настройке SSH-сервера

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

AllowUsers admin admin2
AllowGroups nixadmins
DenyUsers nginx
DenyGroups nginx
PermitEmptyPasswords no
PermitRootLogin no
UsePrivilegeSeparation sandbox

Тут тоже особо ничего удивительного нет, все параметры названы весьма точно – разве что остановлюсь на явном запрете входа через ssh для служебных учётных записей и групп (в моём примере nginx). Не ленитесь явно прописать это, такие учётные записи меняются исключительно редко, а подстраховка не помешает. Да, и не работайте под рутом, как бы тривиально это не звучало.

В варианте с Cisco IOS такие настройки локально на устройстве делать смысла не имеет, т.к. логичнее использовать AAA и перенаправлять запросы про аутентификацию и авторизацию через RADIUS/TACACS на какой-либо централизованный сервер, либо (в новых IOS) обращаться напрямую в LDAP-хранилище с запросами “есть ли такой пользователь”. Плодить локальные базы на каждом устройстве неудобно и небезопасно. Весь этот механизм не привязан к SSH, а является более общим способом перенаправления запросов на аутентификацию/авторизацию, поэтому здесь не описывается, чтобы статья осталась про SSH, а не “про всё, что может иметь отношение к SSH”.

Впрочем, по части паролей настройку сделать всё ж не помешает – команда

atraining(config)#security password min-length N

установит минимальную длину паролей на данном устройстве.

Настройка UsePrivilegeSeparation sandbox будет в явном виде говорить ssh, что для каждого входящего подключения будет создаваться отдельный процесс sshd с минимальными привилегиями – а после удачной авторизации уже будет создаваться новый, который и будет обрабатывать сеанс конкретного подключившегося пользователя. Это снижает потери при появлении новой уязвимости в механизме подключения к sshd – тот, кто будет эксплуатировать эту уязвимость, даже при захвате процесса ssh получит минимум прав в системе.

Краткий итог

Надеюсь, этот небольшой “чеклист” будет вам полезен. SSH крайне широко используется, поэтому предсказуемо настроенный и безопасный доступ через него – фундамент для надёжной сетевой инфраструктуры.

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