Настройка 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, в отличие от 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. Приятной работы!

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.

Если вы работаете в 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 крайне широко используется, поэтому предсказуемо настроенный и безопасный доступ через него – фундамент для надёжной сетевой инфраструктуры.

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

Компания 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

Привет.

Протокол SSH уже продолжительное время является основным используемым средством для удалённого администрирования сетевых устройств и unix-ОС.

Гайдов по настройке SSH много. Часть из них устарела. Часть состоит из сверхценных советов “перевесьте на другой порт, например 2222, и не работайте под рутом”. Часть состоит из копипасты чьей-то конфиги с подписью “это секурно”. Часть содержит откровенно вредные советы.

Попробуем избежать всего вышеперечисленного.

В качестве подопытных и настраиваемых систем будет выбран Centos Linux 7й версии и семейство ОС Cisco IOS / NX-OS, а также Windows Server 2016, имеющий с билда 1709 встроенную поддержку SSH.

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

Если используется другая *nix-ОС, а не redhad-based, то расположение конфигурационных файлов может быть иным. Это принципиально ничего не меняет.

Также, Про настройку SSH в Cisco IOS есть отдельный вебинар из трека Advanced CCNA, запись которого бесплатно доступна на нашем YouTube, а настройку SSH в плане разграничения доступа – типа “хочу, чтобы на коммутаторы и маршрутизаторы могли заходить с админскими правами только участники группы ATRAINING\Cisco Admins из домена Active Directory” – мы делаем на онлайн-курсе Cisco IINS 3.0.

Начнём.

Устанавливаем 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:

atraining-nx(config)#feature 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 нам надо будет добавить (либо заменить) строку:

Protocol 2

Включаем 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-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

2048 бит – это 14я группа по RFC 3526. Можно поставить и 16ю группу, это 4096 бит – так ещё лучше, но надо дополнительно проработать вопрос совместимости со стороны клиентского ПО. Потому что поддержка 1й и 14й DH-групп есть везде, это стандарт по RFC 4253 – а вот остальные MODP-группы DH поддерживаются опционально. Главное, на самом деле, отсечь 1, 2 и 5 группы – наша настройка это и делает.

В варианте sshd нам надо будет добавить в конфигурацию строчку вида:

KexAlgorithms diffie-hellman-group14-sha1

Можно добавить туда и другие алгоритмы, если есть поддержка их со стороны клиента – например, curve25519-sha256. Главное – ограничить выбор, чтобы нельзя было согласовать “слабые” варианты. “Усиленный” вариант будет выглядеть, например, так:

KexAlgorithms [email protected],diffie-hellman-group18-sha512,diffie-hellman-group16-sha512

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

Зачастую предлагается заменить diffie-hellman-group14-sha1 на diffie-hellman-group-exchange-sha256 – мол, “там же SHA-2, это круче, чем SHA-1”. Это так, но diffie-hellman-group-exchange-sha256 – это “любая DH-группа, а целостность – SHA-2”. Т.е. уходит критерий “минимальная битовая длина”, а он важен. SHA-2 тут не особо даст плюсы – потому что предположить существование атаки, которая “на лету” в момент DH-обмена успевает подделать SHA-1 пока трудно.

Весь комплект EC-вариантов от NIST – ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521 – лучше не использовать вообще; помимо известных вопросов к NIST есть и новые предположения – впрочем, это тема для отдельной статьи, потому что тема выбора эллиптических кривых достаточно актуальна.

Алгоритмы выбрали – надо настроить вопрос обновления ключевого материала, он же rekeying.

Будет не очень хорошо, если всегда будет выполняться правило “Одна сессия = один набор битового материала после стартового обмена ключами”. Есть целый класс потенциальных атак, начинающихся с условия “надо набрать не менее N байт данных, зашифрованных этим методом/ключом”. Поэтому лучше, если сессия или продолжительная, или в ней передаётся много данных, периодически менять ключи.

За это в sshd будет отвечать настройка RekeyLimit. Она действует только для SSHv2, и по умолчанию имеет значение “отключено”:

RekeyLimit default none

Мы выставим её в разумное значение “менять ключи, когда передадим очередной гигабайт данных” – это будет выглядеть так:

RekeyLimit 1G

Очень интересным моментом является то, что изначально в стандарте SSH не было жёстко прописано, кто из пары клиент-сервер должен запрашивать rekeying. То есть по идее, могут оба. И настройка долгое время была “клиентской”, то есть в клиентском ПО можно было выставить “через сколько минут/мегабайт запросить”, а у сервера это как-то не предполагалось. В результате в части руководств прямо указывается, что сервер не может делать rekeying. Может.

В случае Cisco IOS (кстати, только в некоторых IOS) настройка параметров rekey делается командой:

atraining(config)#ip ssh rekey

с параметром time или volume. Заметьте, или-или.

В конфигурации могут быть параметры KeyRegenerationInterval и ServerKeyBits – они используются только для SSH 1.x, смело удаляйте; SSHv2 их не использует.

ОК, с этим разобрались – теперь от подтверждения подлинности хоста перейдём к генерации криптографических данных для каждой сессии.

Перегенерация модулей SSHv2

При подключении и стартовой совместной генерации ключевого материала по алгоритму Диффи-Хеллмана-Меркля системе нужно быстро откуда-то достать новое простое число, притом большого размера. Чтобы не делать эту трудоёмкую вычислительную задачу в момент подключения, замедляя оное, используется заранее созданный массив таких чисел и их параметров.

В момент установки ОС и установки/обновления sshd это действие не производится, поэтому оно обязательно должно быть выполнено администратором.

ssh-keygen -G "${HOME}/moduli2048.bak" -M 127 -v -b 2048 -W 2

Я попросил сгенерить новые “предварительно заготовленные числа” в файл moduli2048.bak в домашнем каталоге (файл, откуда sshd будет брать эти числа, обычно называется /etc/ssh/moduli), выделил под это побольше оперативной памяти (ключ -M 127) – 127 мегабайт, а не 4 стандартных, т.к. процесс генерации любит оперативную память, установил битовую длину в 2048 (для доступных из Интернета узлов лучше ставить 4096, но учтите – генериться это будет долго), выставил основание 2 (-W 2 или -W 5 – на безопасность не влияет, а на скорость при последующем использовании – может).

Когда вы сделаете такое же действие, система подумает какое-то время и выдаст подобное: Increased memory: 127 MB; need 4190208 bytes Sieve next 2130706432 plus 2047-bit Sieved with 203277289 small primes in 360 seconds Found 1468150 candidates

Как видим, процесс генерации занял 6 минут ровно. В результате получился файл с пачкой “заготовок” для 2048-битового обмена/совместной генерации ключевого материала. Кратко отвлечёмся на то, как устроен данный файл.

Формат файла moduli

Файл состоит из краткого заголовка-комментария, описывающего содержимое колонок таблицы (выглядит он обычно так – # Time Type Tests Tries Size Generator Modulus) и строк, в которых содержатся интересующие нас параметры.

  • Time – это время генерации, формат YYYYMMDDHHMMSS.
  • Type – это, как понятно, тип. По результатам работы генератора у нас будут сплошь type 4 – это так называемые простые числа Софи Жермен – для них выполняется правило, что у числа Софи Жермен p число 2*p + 1 также будет простым. После того, как мы проверим список чисел-кандидатов на простоту, тип поменяется на двойку – это будут уже “безопасные простые числа”.
  • Tests – битовая маска, говорящая о том, какие тесты прошло данное число, и иногда сообщающая о прискорбных результатах. Если это значение нуль, то число вообще не проверялось на простоту. Если включен первый бит (0x01) – проверялось и оказалось составным (такие использовать совсем не надо). Бит 0x02 говорит о том, что число выжило после решета Эратосфена (у свежесозданных “заготовок” будет как раз такое значение). Бит 0x04 скажет о том, что число выжило после теста Миллера-Рабина – поэтому после второго шага по проверке “заготовок” у всех хороших чисел в колонке Tests будет стоять число 6 – что говорит о том, что они прошли оба теста.
  • Trials – количество тестов, проведённых над числом (будет впечатляющим, но тут важнее вопрос, какие именно это тесты – поэтому сотни миллионов итераций не равны гарантии надёжности).
  • Size – длина числа в битах. Чаще всего вы увидите “странные” значения – не 1024/2048/4096/8192, а на бит меньше. Это нормально, т.к. у простого числа есть как минимум два известных бита – первый и последний. Первый будет единицей, т.к. это число имеет фиксированную длину – если бы число могло начинаться с нуля или пачки нулей, оно было бы короче заданного размера, а это недопустимо – мы заказывали генерацию чисел именно нужно длины. Последний будет единицей, т.к. если у числа последний бит нуль, то это число чётное, а чётные числа редко (только в случае двойки) бывают простыми. Поэтому в принципе можно и сэкономить на хранении простых чисел, предположив два вышеупомянутых тезиса.
  • Generator – основание – т.е. 2 или 5 (или нуль – тогда тоже 2).
  • Modulus – само число.

Продолжим.

Эти заготовки теперь надо прогнать через процедуру тестирования, чтобы отсеять модули, которые “слишком легко” будут разлагаться на множители, или вообще не будут простыми числами. Т.е. процедура генерации создаёт именно “кандидатов, предположительно годных для ношения гордого звания простого числа”, а тестирование отсеивает из них тех, кто явно не подходит.

ssh-keygen -T /etc/ssh/moduli -f "${HOME}/moduli2048.bak" -a 500

Параметры тут очевидны – где брать тестируемые и куда складывать готовые – разве что хочу отметить -a 500. Этот параметр – это “глубина” проверки, по умолчанию она равняется 100, я выставляю 500 для более тщательной проверки и отсева. Так как мы делаем разовую процедуру, то увеличение времени работы тут не критично. А оно будет, притом неслабое. Система начнёт отчитываться на консоль раз в 5 минут о том, как двигается процесс – в моём случае это выглядит так: [[email protected] ~]# ssh-keygen -T /etc/ssh/moduli -f "${HOME}/moduli2048.bak" -a 500 processed 31311 of 1468725 (2%) in 0:05, ETA 3:49 processed 61015 of 1468725 (4%) in 0:10, ETA 3:51 processed 93610 of 1468725 (6%) in 0:15, ETA 3:40 processed 114521 of 1468725 (7%) in 0:20, ETA 3:57 processed 145914 of 1468725 (9%) in 0:25, ETA 3:47 processed 180592 of 1468725 (12%) in 0:30, ETA 3:34 processed 204619 of 1468725 (13%) in 0:35, ETA 3:37 processed 233644 of 1468725 (15%) in 0:40, ETA 3:32 processed 263243 of 1468725 (17%) in 0:45, ETA 3:27 processed 290385 of 1468725 (19%) in 0:50, ETA 3:24 processed 316302 of 1468725 (21%) in 0:55, ETA 3:21 processed 350252 of 1468725 (23%) in 1:00, ETA 3:12 processed 381090 of 1468725 (25%) in 1:05, ETA 3:06 processed 407552 of 1468725 (27%) in 1:10, ETA 3:03 processed 432599 of 1468725 (29%) in 1:15, ETA 3:00 processed 463306 of 1468725 (31%) in 1:20, ETA 2:54 processed 494272 of 1468725 (33%) in 1:25, ETA 2:48 processed 521319 of 1468725 (35%) in 1:30, ETA 2:44 processed 547391 of 1468725 (37%) in 1:35, ETA 2:40 processed 577760 of 1468725 (39%) in 1:40, ETA 2:34 processed 607799 of 1468725 (41%) in 1:45, ETA 2:29 processed 634402 of 1468725 (43%) in 1:50, ETA 2:25 processed 664471 of 1468725 (45%) in 1:55, ETA 2:19 processed 690995 of 1468725 (47%) in 2:00, ETA 2:15 processed 717235 of 1468725 (48%) in 2:05, ETA 2:11 processed 745487 of 1468725 (50%) in 2:10, ETA 2:06 processed 774837 of 1468725 (52%) in 2:15, ETA 2:01 processed 811298 of 1468725 (55%) in 2:20, ETA 1:54 processed 843016 of 1468725 (57%) in 2:25, ETA 1:48 processed 867423 of 1468725 (59%) in 2:30, ETA 1:44 processed 895713 of 1468725 (60%) in 2:35, ETA 1:39 processed 922506 of 1468725 (62%) in 2:40, ETA 1:35 processed 953693 of 1468725 (64%) in 2:45, ETA 1:29 processed 984896 of 1468725 (67%) in 2:50, ETA 1:23 processed 1012815 of 1468725 (68%) in 2:55, ETA 1:19 processed 1035874 of 1468725 (70%) in 3:00, ETA 1:15 processed 1066079 of 1468725 (72%) in 3:05, ETA 1:10 processed 1097883 of 1468725 (74%) in 3:10, ETA 1:04 processed 1124370 of 1468725 (76%) in 3:15, ETA 0:59 processed 1150179 of 1468725 (78%) in 3:20, ETA 0:55 processed 1178185 of 1468725 (80%) in 3:25, ETA 0:50 processed 1208345 of 1468725 (82%) in 3:31, ETA 0:45 processed 1231626 of 1468725 (83%) in 3:36, ETA 0:41 processed 1256634 of 1468725 (85%) in 3:41, ETA 0:37 processed 1285065 of 1468725 (87%) in 3:46, ETA 0:32 processed 1314094 of 1468725 (89%) in 3:51, ETA 0:27 processed 1344108 of 1468725 (91%) in 3:56, ETA 0:21 processed 1375328 of 1468725 (93%) in 4:01, ETA 0:16 processed 1410594 of 1468725 (96%) in 4:06, ETA 0:10 processed 1439388 of 1468725 (98%) in 4:11, ETA 0:05 processed 1465957 of 1468725 (99%) in 4:16, ETA 0:00 Found 917 safe primes of 1223961 candidates in 15426 seconds [[email protected] ~]#

Я специально показываю полный вывод команды, чтобы можно было оценить и масштабы времени, и КПД отсеивания “плохих” модулей. Из 1.2 с лишним миллиона потенциальных primes прошли тесты лишь около 900! За четыре с лишним часа.

Кстати, процесс не распараллеливается – т.е. добавлением ядер вопрос не ускорить. У той машины, на которой это делалось, их 12 – это никак не помогло ускорить процесс, одно ядро лежало под 100%, другие простаивали.

Чтобы можно было оценить влияние количества тестов на общее время выполнения – вот так выглядит вариант с -a 10: processed 47249 of 1468725 (3%) in 0:05, ETA 2:30

(только первая строка, для сравнения этого достаточно).

Заметно, что оценка времени ощутимо изменилась, но не в 50 раз, как количество тестов – т.е. “минимальный” комплект проверок всё ж завязан на битовость ключа и общее число candidates.

После всего этого временный файл с расширением bak надо удалить, он больше не нужен, и наличие его вне каталога, доступного для sshd – опасно.

Добавлю ещё один момент – при запуске ssh-keygen -T в файл /etc/ssh/moduli новые строки будут добавляться, а старые при этом – остаются. То есть если вы не стёрли этот файл перед генерацией, в нём будут и предыдущие и новые модули. Если так, то надо как-то почистить от старых – например, можно отфильтровать по критерию длины:

awk '$5 > 2000' /etc/ssh/moduli > "${HOME}/moduli.2048"

Этой командой мы скопировали в moduli.2048 только те строки, в которых в 5й колонке, где длина, значение более 2000.

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

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

Теперь про главный протокол шифрования – которым шифруются сами данные.

Настраиваем используемый алгоритм шифрования трафика SSHv2

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

Старые варианты, в частности 3DES, нас не интересуют – и в силу вопросов по стойкости, и в силу отсутствия аппаратного ускорения. Нам проще использовать AES.

Но какой? Помимо выбора длины в битах, нам надо не ошибиться с выбором режима работы AES. Нам не подойдёт простой AES-CBC, потому что в 2008 году была продемонстрирована потенциальная уязвимость в SSH с AES-CBC, из-за которой можно получить до 32х бит исходных данных. Наш выбор – AES256-CTR.

В Cisco IOS это будет задаваться так:

atraining(config)#ip ssh server algorithm encryption aes256-ctr

После aes256-ctr можно указать и другие алгоритмы, в этом случае будет задаваться список согласовываемых с клиентом вариантов; однако найти клиентское ПО, которое не поддерживает AES – сложно.

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

Ciphers aes256-ctr

в конфигурационном файле. Ранее была настройка Cipher, в единственном числе, но она используется только в SSH 1.x, поэтому если она есть в конфигурационном файле – спокойно удаляйте строку с ней.

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

ssh -Q cipher

Думаю, aes256-ctr там точно будет.

Отключаем сжатие SSHv2-трафика

Это простое действие, нужное для защиты от класса атак на или некорректную/неточную обработку распаковки каких-то специфичных данных со стороны клиента, или на различные переполнения.

Сжатие – штука полезная и трафик экономит, кто же спорит. Просто в реальности в SSH вы или осуществляете администрирование – тогда объём отправляемых/принимаемых данных смешной и КПД сжатия с точки зрения использования будет совершенно не заметным, либо передаёте большие файлы при помощи SFTP – тогда, соответственно, эти файлы “досжать” при помощи встроенного в SSH сжатия обычно не получится, т.к. это или архивы, или мультимедийное содержимое.

Отключаем просто – добавляя в конфигурационный файл строку:

Compression no

В Cisco IOS сжатие в SSH не поддерживается официально, поэтому и отключать нечего.

Выбираем Message Authentication Code у SSHv2

Алгоритмы шифрования (за исключением варианта AEAD) не умеют проверять целостность данных, которые шифруют. Поэтому в нашем случае, когда используется AES256-CTR, надо озаботиться выбором MAC.

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

Поэтому, честно говоря, базового варианта hmac-sha1-96 вполне достаточно.

Вы можете добавить поддержку более стойких вариантов – например, hmac-sha2-512, предварительно командой ssh -Q mac выяснив, что умеет ваш сервер, но будьте аккуратны – далеко не все клиенты поддерживают продвинутые варианты (опять же по причине не особо заметного влияния на безопасности). Упомянутый SHA-2/512, например, несмотря на то, что он быстрый, поддерживается только последними версиями PuTTY.

Команда по части MAC, если всё же хотите вариант “безопаснее и не используя SHA-1” будет, например, такой:

MACs hmac-sha2-512

Вариант hmac-sha2-256 поддерживается большинством существующих SSH-клиентов даже не самой последней версии. А вот hmac-sha2-512 может не поддерживаться даже последней доступной (на момент публикации – 0.70) версией популярного клиента PuTTY:

Поэтому выбирайте сами – 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-сервера) – в этом случае возможен сценарий, что подключиться к узлу не получится. Но это совсем не “защитная мера” а, скорее, ещё одна причина отключать эту проверку, т.к. из-за неё, получается, растёт количество задействованных подсистем, а следовательно падает общая надёжность работы системы.

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

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-подобный механизм, про семейство которых обсуждается на курсах по QoS и логика его конфигурирования будет следующей – первое и последние значения – это стартовое количество подключений (речь только про подключения, которые не прошли аутентификацию), начиная с которых механизм начнёт работать и максимальное количество подключений, возможных вообще (в нашем случае механизм включится, когда к серверу будет 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 крайне широко используется, поэтому предсказуемо настроенный и безопасный доступ через него – фундамент для надёжной сетевой инфраструктуры.

Удач!

Дата последнего редактирования текста: 2017-07-11T23:25:05+08:00

Настройка доступа к Cisco по SSH | Мерион Нетворкс

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

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

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

НАСТРОЙКА

Для начала, вам понадобится 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

Далее, настроим сетевую карту компьютера – укажем сетевой адрес в настройках FastEthernet0: 192.168.1.2. По умолчанию все новые компьютеры будут находиться в vlan 1.

Теперь давайте попробуем пингануть коммутатор и зайти на него по протоколу 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 сервер на коммутаторе Cisco Catalyst с IOS v.15 [Вики IT-KB]

Имеем коммутатор Cisco Catalyst с включенным Telnet и заданными паролями «Virtual terminal password» и «Enable secret». Для улучшения уровня безопасности при администрировании коммутатора, нам требуется включить встроенный сервер SSH и исключить возможность используемого по умолчанию Telnet. Обратите внимание на то, что включение SSH возможно не во всех версиях Cisco IOS.

Подключаемся к коммутатору через Telnet, указав пароль «Virtual terminal password»:

User Access Verification

Password: 
Switch>

Повышаем привелегии до уровня администратора командой enable:

Switch> enable
Password: 
Switch#

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

Входим в режим изменения конфигурации (configure terminal) и задаём коммутатору имя хоста, если оно не было задано ранее…

Switch# configure terminal
Switch(config)# hostname SW001
SW001(config)#

…затем задаём имя домена…

SW01(config)# ip domain-name my.holding.com
SW01(config)# end
SW01#

Если время в IOS не настроено, то при попытке генерации ключей RSA, которую мы будем в дальнейшем придпринимать, мы можем получить ошибку «% Rsa keys cannot be generated, as system clock is invalid». Итак, настраиваем синхронизацию времени.

SW01# show clock
20:18:51.664 UTC Mon Aug 29 1932

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

SW01#
SW01# configure terminal
SW01(config)# clock timezone MSK 3
SW01(config)# ntp server 10.5.0.3 prefer
SW01(config)# ntp server 10.5.1.2
SW01(config)# end
SW01#

Здесь мы указали местную временную зону (Московское время, со сдвигом +3 часа от UTC) и задали в качестве источника времени два NTP-сервера, один из которых (с опцией prefer) является приоритетным. Через несколько секунд часы нашего коммутатора должны отображать правильное время:

SW01# show clock

14:35:32.272 MSK Thu Jan 11 2018

Проверить статус синхронизации можно следующим образом:

SW01# show ntp status

Clock is unsynchronized, stratum 4, reference is 1.5.0.3
nominal freq is 286.1023 Hz, actual freq is 286.1023 Hz, precision is 2**20
ntp uptime is 76500 (1/100 of seconds), resolution is 3496
reference time is DE01CCFD.A2B78D5D (14:46:05.635 MSK Thu Jan 11 2018)
clock offset is 9.2496 msec, root delay is 75.43 msec
root dispersion is 146.12 msec, peer dispersion is 16.55 msec
loopfilter state is 'FREQ' (Drift being measured), drift is 0.000000000 s/s
system poll interval is 64, last update was 10 sec ago.

Проверить состояние источников синхронизации времени можно так:

SW01# show ntp associations

  address   ref clock   st   when   poll reach  delay  offset   disp
+~10.5.0.3    10.0.1.2   3     16     64   377 12.505   5.026 16.552
*~10.5.1.2    10.0.1.2   3     12     64   377 12.932   9.249 16.550
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

Теперь всё готово для того, чтобы сгенерировать ключевую пару RSA.

SW01# configure terminal
SW01(config)# crypto key generate rsa

The name for the keys will be: SW001.my.holding.com
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]: 4096
% Generating 4096 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 79 seconds)

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

SW01# configure terminal
SW01(config)# username vasya privilege 15 secret MyPa$$w0rd
SW01(config)# service password-encryption
SW01(config)# end
SW01#

Запрещаем Telnet и оставляем только SSH для виртуальных терминалов vty с 0 по 15

SW01# configure terminal
SW01(config)# line vty 0 15
SW01(config-line)# transport input ssh
SW01(config-line)# end
SW01#

Разрешаем использование локальных учётных записей в конфигурации виртуальных терминалов

SW01# configure terminal
SW01(config)# line vty 0 15
SW01(config-line)# login local
SW01(config-line)# end
SW01#

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

SW01# write

Дополнительные источники информации:


Проверено на следующих конфигурациях:

Модель коммутатора Версия IOS
Cisco Catalyst WS-2960X-48TD-L V05 15.2.2E7
Cisco Catalyst WS-C3560X-48T-L V05 15.2.4E8

Автор текущей редакции:
Алексей Максимов
Время публикации: 13.01.2018 23:01

Как настроить аутентификацию без пароля по ключу на Cisco IOS

PKI (Public Key Authentication) метод аутентификации, использующий пару ключей для аутентификации вместо пароля. Пара с генерированных ключей:

  • Публичный ключ
  • Приватный ключ

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

На этом уроке мы создадим публичный и приватный ключи на компьютерах с Windows и Linux. Затем мы добавим публичный ключ к Cisco IOS маршрутизатору и используем его для аутентификации SSH. Маршрутизатор будет отправлять нам зашифрованные сообщения, которые можем расшифровать только мы потому, что у нас есть приватный ключ. Это доказывает, что мы являемся пользователем, который, как мы заявляем, есть администратором, что позволяет получить доступ к маршрутизатору.

 

1. Конфигурация устройств

Сперва нужно с генерировать пару ключей RSA — публичный и приватный. Сейчас будет показано как это сделать на Windows и Linux.

 

1.1 Создание ключей на Windows

PuTTY один из самых популярных SSH клиентов для Windows, потому его мы и будем использовать. Putty сам по себе не способен генерировать RSA ключи, однако можно использовать PuTTYgen (PuTTY Key Generator).

После его запуска, вы увидите главный экран программы:

 

 

Начальные настройки нам подходят, мы с генерируем 248 битную пару ключей RSA. Нажмите кнопку Generate и вы увидите это:

 

 

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

 

 

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

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

Нажмите save public key и save private key кнопки:

 

 

Мы будем использовать следующие имена файлов:

  • публичный ключ: windows_user.pub
  • приватный ключ: windows_user.ppk

 

Это все, что нам нужно сделать. Но чтобы проверить это, мы должны сначала настроить наш Cisco IOS маршрутизатор (или коммутатор) .

 

1.2 Создание ключей на Linux

В большинстве Linux дистрибутивов есть встроенный SSH, мы будем использовать Ubuntu для этого примера.

Сперва надо с генерировать 2048 битную пару ключей RSA:

$ ssh-keygen -b 2048 -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/ubuntu/.ssh/id_rsa):
Created directory '/home/ubuntu/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/ubuntu/.ssh/id_rsa.
Your public key has been saved in /home/ubuntu/.ssh/id_rsa.pub.
The key fingerprint is:
39:97:0c:ab:33:ea:bb:8b:e3:9f:4f:db:9a:fe:cf:fe [email protected]
The key's randomart image is:
+--[ RSA 2048]----+
| |
| |
| . |
| = . |
| S + |
| . o |
| = |
| .. + * . |
| .o+O**ooo+.E |
+-----------------+

 

Имена файлов:

  • публичный ключ: id_rsa.pub
  • приватный ключ: id_rsa

 

Мы можем просмотреть их тут:

$ ls -lh /home/ubuntu/.ssh
total 8,0K
-rw------- 1 ubuntu ubuntu 1,7K jan 10 19:41 id_rsa
-rw-r--r-- 1 ubuntu ubuntu 394 jan 10 19:41 id_rsa.pub

 

Готово. Теперь пора настроить Cisco IOS маршрутизатор (или коммутатор) .

1.3 Конфигурация Cisco IOS

Давайте начнем с базовой конфигурации SSH. Сначала мы настраиваем имя узла:

Router(config)#hostname R1

 

А также имя домена:

R1(config)#ip domain-name SEDICOMM.LOCAL

 

С генерируем 2048 битную пару ключей RSA:

R1(config)#crypto key generate rsa modulus 2048
The name for the keys will be: R1.SEDICOMM.LOCAL

% The key modulus size is 2048 bits
% Generating 2048 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 24 seconds)

%SSH-5-ENABLED: SSH 1.99 has been enabled

 

И включим SSH версии 2:

R1(config)#ip ssh version 2

 

Настроим линии VTY на прием только SSH и локальной авторизации:

R1(config)#line vty 0 4
R1(config-line)#transport input ssh
R1(config-line)#login local

 

Опционально можно отключить запрос пароля при подключении по SSH

R1(config)#no ip ssh server authenticate user password
R1(config)#no ip ssh server authenticate user keyboard

 

Теперь мы можем добавить с генерированные нами ранее на Windows и Linux ключи.

 

1.3.1 Активация ключа, сгенерированого под Windows на устройстве Cisco

 

Вы можете открыть файл публичного ключа (windows_user.pub) в любом текстовом редакторе. Он будет выглядеть так:

---- BEGIN SSh3 PUBLIC KEY ----
Comment: "WINDOWS_USER"
AAAAB3NzaC1yc2EAAAABJQAAAQEAijoMF9oBwyQxwYbVlFprz+fG8oe5uAcCxwMw
eIR1lyAnDJIsYbTbcdm+n5KiQnCt2561MpN4yOFpajFNM/dqH7/jYaqaicHCSV2F
RGauEp7FzN/uXxsX7mii6qOuxovl9OflLpXcvH5QH6551ycmL8nIv8UCY8uayiGI
INsC0LyKEctWDW6qWp43T7rhcP0y4JoMraTCZLIPNE0Bo0bHgnGLg6fEvJmyB3sX
H+7BaxHdYKg2OcIgVqYzclWhDwxj32kqd1BCq089iBMrb4QppDU2eM/t22iK29mn
eqOGTiCkxB80ix+KULT9okmqkj3TbhCpunTfuPCCRNrjqndBsw==
---- END SSh3 PUBLIC KEY ----

 

 

Можно убрать все кроме самого ключа, тогда это будет выглядеть так:

AAAAB3NzaC1yc2EAAAABJQAAAQEAijoMF9oBwyQxwYbVlFprz+fG8oe5uAcCxwMw
eIR1lyAnDJIsYbTbcdm+n5KiQnCt2561MpN4yOFpajFNM/dqH7/jYaqaicHCSV2F
RGauEp7FzN/uXxsX7mii6qOuxovl9OflLpXcvH5QH6551ycmL8nIv8UCY8uayiGI
INsC0LyKEctWDW6qWp43T7rhcP0y4JoMraTCZLIPNE0Bo0bHgnGLg6fEvJmyB3sX
H+7BaxHdYKg2OcIgVqYzclWhDwxj32kqd1BCq089iBMrb4QppDU2eM/t22iK29mn
eqOGTiCkxB80ix+KULT9okmqkj3TbhCpunTfuPCCRNrjqndBsw==

 

 

Можно добавить публичный ключ любому пользователю. Мы назовем этого пользователя WINDOWS_USER. После ввода key-string команды, вводим строки ключа, пока не введем exit:

R1(config)#ip ssh pubkey-chain
R1(conf-ssh-pubkey)#username WINDOWS_USER
R1(conf-ssh-pubkey-user)#key-string
R1(conf-ssh-pubkey-data)#AAAAB3NzaC1yc2EAAAABJQAAAQEAijoMF9oBwyQxwYbVlFprz+fG8oe5uAcCxwMw
R1(conf-ssh-pubkey-data)#eIR1lyAnDJIsYbTbcdm+n5KiQnCt2561MpN4yOFpajFNM/dqH7/jYaqaicHCSV2F
R1(conf-ssh-pubkey-data)#RGauEp7FzN/uXxsX7mii6qOuxovl9OflLpXcvH5QH6551ycmL8nIv8UCY8uayiGI
R1(conf-ssh-pubkey-data)#INsC0LyKEctWDW6qWp43T7rhcP0y4JoMraTCZLIPNE0Bo0bHgnGLg6fEvJmyB3sX
R1(conf-ssh-pubkey-data)#H+7BaxHdYKg2OcIgVqYzclWhDwxj32kqd1BCq089iBMrb4QppDU2eM/t22iK29mn
R1(conf-ssh-pubkey-data)#eqOGTiCkxB80ix+KULT9okmqkj3TbhCpunTfuPCCRNrjqndBsw==
R1(conf-ssh-pubkey-data)#exit
R1(conf-ssh-pubkey-user)#exit
R1(conf-ssh-pubkey)#exit

 

Теперь наш маршрутизатор знает публичный ключ для пользователя windows.

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

1.3.2 Активация ключа, сгенерированого под Linux на устройстве Cisco

 

Сделаем то же самое для Linux пользователя. Сперва откроем ключ:

$ cat /home/ubuntu/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC80DsOF4nkk15V0V2U7r4Q2MyAwIbgQX/7rqdUyNCTulliYZWdxnQHaI0WpvcEHQTrSXCauFOBqUrLZglI2VExOgu0TmmWCajW/vnp8J5bArzwIk83ct35IHFozPtl3Rj79U58HwMlJ2JhBTkyTrZYRmsP+r9VF7pYMVcuKgFS+gDvhbuxM8DNLmS1+eHDw9DNHYBA+dIaEIC+ozxDV7kF6wKOx59E/Ni2/dT9TJ5Qge+Rw7zn+O0i1Ib95djzNfVdHq+174mchGx3zV6l/6EXvc7G7MyXj89ffLdXIp/Xy/wdWkc1P9Ei8feFBVLTWijXiilbYWwdLhrk7L2EQv5x [email protected]

 

Ключ выводится одной строкой, это нормально, но Cisco IOS поддерживает только 254 символа в строке, потому вы не сможете ввести ключ одной строкой. В Linux есть удобная команда, позволяющая разделить ключ на несколько частей:

$ fold -b -w 72 /home/ubuntu/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC80DsOF4nkk15V0V2U7r4Q2MyAwIbgQX/7
rqdUyNCTulliYZWdxnQHaI0WpvcEHQTrSXCauFOBqUrLZglI2VExOgu0TmmWCajW/vnp8J5b
ArzwIk83ct35IHFozPtl3Rj79U58HwMlJ2JhBTkyTrZYRmsP+r9VF7pYMVcuKgFS+gDvhbux
M8DNLmS1+eHDw9DNHYBA+dIaEIC+ozxDV7kF6wKOx59E/Ni2/dT9TJ5Qge+Rw7zn+O0i1Ib9
5djzNfVdHq+174mchGx3zV6l/6EXvc7G7MyXj89ffLdXIp/Xy/wdWkc1P9Ei8feFBVLTWijX
iilbYWwdLhrk7L2EQv5x [email protected]

 

Можно удалить ssh-rsa в начале и комментарий в конце, получаем вот такой ключ:

AAAAB3NzaC1yc2EAAAADAQABAAABAQC80DsOF4nkk15V0V2U7r4Q2MyAwIbgQX/7
rqdUyNCTulliYZWdxnQHaI0WpvcEHQTrSXCauFOBqUrLZglI2VExOgu0TmmWCajW/vnp8J5b
ArzwIk83ct35IHFozPtl3Rj79U58HwMlJ2JhBTkyTrZYRmsP+r9VF7pYMVcuKgFS+gDvhbux
M8DNLmS1+eHDw9DNHYBA+dIaEIC+ozxDV7kF6wKOx59E/Ni2/dT9TJ5Qge+Rw7zn+O0i1Ib9
5djzNfVdHq+174mchGx3zV6l/6EXvc7G7MyXj89ffLdXIp/Xy/wdWkc1P9Ei8feFBVLTWijX
iilbYWwdLhrk7L2EQv5x

 

 

Давайте добавим его маршрутизаторе Cisco, будем использовать имя пользователя LINUX_USER:

R1(config)#ip ssh pubkey-chain
R1(conf-ssh-pubkey)#username LINUX_USER
R1(conf-ssh-pubkey-user)#key-string
R1(conf-ssh-pubkey-data)#AAAAB3NzaC1yc2EAAAADAQABAAABAQC80DsOF4nkk15V0V2U7r4Q2MyAwIbgQX/7
R1(conf-ssh-pubkey-data)#rqdUyNCTulliYZWdxnQHaI0WpvcEHQTrSXCauFOBqUrLZglI2VExOgu0TmmWCajW/vnp8J5b
R1(conf-ssh-pubkey-data)#ArzwIk83ct35IHFozPtl3Rj79U58HwMlJ2JhBTkyTrZYRmsP+r9VF7pYMVcuKgFS+gDvhbux
R1(conf-ssh-pubkey-data)#M8DNLmS1+eHDw9DNHYBA+dIaEIC+ozxDV7kF6wKOx59E/Ni2/dT9TJ5Qge+Rw7zn+O0i1Ib9
R1(conf-ssh-pubkey-data)#5djzNfVdHq+174mchGx3zV6l/6EXvc7G7MyXj89ffLdXIp/Xy/wdWkc1P9Ei8feFBVLTWijX
R1(conf-ssh-pubkey-data)#iilbYWwdLhrk7L2EQv5x
R1(conf-ssh-pubkey-data)#exit
R1(conf-ssh-pubkey-user)#exit
R1(conf-ssh-pubkey)#exit

 

Все настройки завершены, давайте проверим работоспособность.

 

2. Проверка работоспособности

 

Сперва проверим WINDOWS_USER пользователя, затем LINUX_USER.

 

2.1 Проверка работоспособности Windows

 

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

R1#show running-config | begin pubkey
ip ssh pubkey-chain
username WINDOWS_USER
key-hash ssh-rsa 8FB4F858DD7E5AFB372780EC653DB371
quit

 

Можем проверить с генерировал ли PuTTY Key Generator такой же хэш

 

 

Если хэш совпадает, мы ввели все правильно, и ключи совпадают. Пора настроить PuTTY. Заходим в PuTTY и открываем Connection > SSH setting.

Нажимаем browse и выбираем файл приватного ключа (windows_user.ppk):

 

 

Далее переходим в Connection > Data setting, и вводим тут имя пользователя:

 

 

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

 

 

Нажимаем Open и видим это:

Using username "WINDOWS_USER".
Authenticating with public key "WINDOWS_USER"

R1>

 

Отлично, мы подключились к маршрутизатору, используя, RSA ключи.

2.2 Проверка работоспособности LINUX_USER

 

Давайте теперь проверим может ли LINUX_USER подключится. Первым делом сравним хэш:

R1#show running-config | begin pubkey
ip ssh pubkey-chain
username WINDOWS_USER
key-hash ssh-rsa 8FB4F858DD7E5AFB372780EC653DB371
quit
username LINUX_USER
key-hash ssh-rsa 39970CAB33EABB8BE39F4FDB9AFECFFE
quit

 

 

Посмотреть хэш на Linux можно следующей командой:

$ ssh-keygen -l -f /home/ubuntu/.ssh/id_rsa.pub
2048 39:97:0c:ab:33:ea:bb:8b:e3:9f:4f:db:9a:fe:cf:fe [email protected] (RSA)

 

 

Хэш совпадает, давайте посмотрим можем ли мы подключится:

$ ssh [email protected]
R1>

 

Все работает, мы подключены!

 

3. Вывод

Мы разобрались как настроить аутентификацию без пароля по ключу на Cisco IOS, чтобы можно было подключаться как из под Windows так и из под Linux.

 

 

Спасибо за уделенное время на прочтение статьи о том, как настроить аутентификацию без пароля по ключу на Cisco IOS!

Если возникли вопросы, задавайте их в комментариях.

Подписывайтесь на обновления нашего блога и оставайтесь в курсе новостей мира инфокоммуникаций!

Чтобы знать больше и выделяться знаниями среди толпы IT-шников, записывайтесь на курсы Cisco, курсы по кибербезопасности,  полный курс по кибербезопасности, курсы DevNet (программируемые сети) от Академии Cisco, курсы Linux от Linux Professional Institute на платформе SEDICOMM University (Университет СЭДИКОМ.

Курсы Cisco и Linux с трудоустройством!

Спешите подать заявку! Осталось пару мест. Группы стартуют 22 июля, а следующая 19 августа, 23 сентября, 21 октября, 25 ноября, 16 декабря, 20 января, 24 февраля.

Что Вы получите?

  • Поможем стать экспертом в сетевом администрировании и получить международные сертификаты Cisco CCNA Routing & Switching или Linux LPI.
  • Предлагаем проверенную программу и учебник экспертов из Cisco Networking Academy и Linux Professional Institute, сертифицированных инструкторов и личного куратора.
  • Поможем с трудоустройством и сделать карьеру. 100% наших выпускников трудоустраиваются.

Как проходит обучение?

  • Проводим вечерние онлайн-лекции на нашей платформе или обучайтесь очно на базе Киевского офиса.
  • Спросим у вас об удобном времени для практик и подстроимся: понимаем, что времени учиться мало.
  • Если хотите индивидуальный график — обсудим и осуществим.
  • Выставим четкие дедлайны для самоорганизации. Личный куратор будет на связи, чтобы ответить на вопросы, проконсультировать и мотивировать придерживаться сроков сдачи экзаменов.

А еще поможем Вам:

  • отредактировать резюме;
  • подготовиться к техническим интервью;
  • подготовиться к конкурсу на понравившуюся вакансию;
  • устроим на работу в Cisco по программе Cisco Incubator, New Graduate и Experienced. Наши студенты, которые уже работают там: жмите на #НашиВCisco Вконтакте, #НашиВCisco Facebook.
Чтобы учиться на курсах Cisco CCNA Routing & Switching и Linux LPI, подайте заявку или получите бесплатную консультацию.

Как включить SSH на коммутаторе Cisco, маршрутизаторе и ASA

Q: В моей сети есть коммутатор Cisco, к которому я могу получить доступ, подключив консольный кабель непосредственно к устройству. Мне нравится получать доступ к коммутатору удаленно, используя SSH. Как я могу включить ssh на моем коммутаторе Cisco 3750 Catalyst?

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

1. Настройка управления IP

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

В следующем примере IP-адрес управления установлен как 192.168.101.2 в 101 VLAN. Шлюз по умолчанию указывает на брандмауэр, это 192.168.101.1

# IP-шлюз по умолчанию 192.168.101.1

# интерфейс vlan 101
(config-if) # IP-адрес 192.168.101.2 255.255.255.0
 

2. Задайте имя хоста и имя домена

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

# config t
(config) # имя хоста myswitch
(config) # ip доменное имя thegeekstuff.com
 

3. Создайте ключи RSA

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

myswitch (config) # криптоключ генерирует rsa
 Название ключей будет: myswitch.thegeekstuff.com.
 Выберите размер ключевого модуля в диапазоне от 360 до 2048 для вашего
   Ключи общего назначения. Выбор ключевого модуля больше 512 может занять
   несколько минут.

Сколько бит в модуле [512]: 1024
 % При генерации 1024-битных ключей RSA ключи не будут экспортироваться ... [OK]
 

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

4. Настройте конфигурации линии VTY

Установите следующие параметры конфигурации vty строки, где входной транспорт установлен на SSH. Установите локальный логин и пароль 7.

# строка vty 0 4
(config-line) # транспортный ввод ssh
(config-line) # вход локальный
(config-line) # пароль 7
(config-line) # выход
 

Если вы еще не установили консольную строку, установите для нее следующие значения.

# строка консоли 0
(config-line) # ведение журнала синхронно
(config-line) # вход локальный
 

5.Создайте пароль для имени пользователя

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

myswitch # config t
Введите команды конфигурации, по одной в каждой строке. Закончите CNTL / Z.
myswitch (config) # имя пользователя ramesh пароль mypassword
 

Примечание. Если у вас нет правильной настройки пароля включения, сделайте это сейчас.

myswitch # включить секретный пароль myenablepassword
 

Убедитесь, что включена служба шифрования паролей, которая будет шифровать пароль, и когда вы сделаете «sh run», вы увидите только зашифрованный пароль, а не пароль в виде открытого текста.

myswitch # сервисный пароль-шифрование
 

5. Проверьте доступ по SSH.

Если на коммутаторе вы выполните «sh ip ssh», он подтвердит, что SSH включен на этом устройстве cisco.

myswitch # sh ip ssh
SSH включен - версия 1.99
Тайм-аут аутентификации: 120 секунд; Попыток аутентификации: 3
 

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

В этом примере 192.168.101.2 — это IP-адрес управления коммутатором.

удаленная машина # ssh 192.168.101.2
войти как: ramesh
Использование интерактивной аутентификации с клавиатуры.
Пароль:

myswitch> ru
Пароль:
myswitch #
 

Как настроить SSH на Cisco IOS

В предыдущем уроке я объяснил, как можно использовать telnet для удаленного доступа к устройствам Cisco IOS. Проблема с telnet заключается в том, что все отправляется в виде открытого текста, поэтому вам не следует его использовать.

SSH (Secure Shell) — это безопасный метод удаленного доступа, включающий аутентификацию и шифрование. Для этого он использует пару открытых / закрытых ключей RSA.

Существует две версии: версия 1 и версия 2. Версия 2 более безопасна и широко используется.

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

Конфигурация

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

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










SSH-сервер

имя пары ключей RSA будет именем хоста и доменным именем маршрутизатора. Настроим имя хоста:

  Маршрутизатор (конфигурация) #  имя хоста R1   

И доменное имя:

  R1 (config) #  ip доменное имя NETWORKLESSONS.LOCAL   

Теперь мы можем сгенерировать пару ключей RSA:

  R1 (config) #  криптоключ генерирует RSA 
Название ключей будет: R1.УРОКИ СЕТИ. МЕСТНЫЕ
Выберите размер ключевого модуля в диапазоне от 360 до 4096 для вашего
  Ключи общего назначения. Выбор ключевого модуля больше 512 может занять
  несколько минут.

Сколько бит в модуле [512]:  2048 
% При генерации 2048-битных ключей RSA ключи не будут экспортироваться ...
[OK] (прошедшее время 3 секунды)  

Когда вы используете команду crypto key generate rsa , она спросит вас, сколько битов вы хотите использовать для размера ключа.Сколько выбрать?

Для этого лучше всего проверить статью о шифровании следующего поколения от Cisco. На данный момент допустим размер ключа 2048 бит. Следует избегать размеров ключей 1024 или меньше. Для расчета ключей большего размера также требуется больше времени.

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

  R1 #
% SSH-5-ENABLED: SSH 1.99 включен  

Как видно выше, версия SSH 1 является версией по умолчанию.Перейдем к версии 2:

  R1 (конфигурация) #  ip ssh версия 2   

SSH включен, но мы также должны настроить линии VTY:

  R1 (конфигурация) #  строка vty 0 4 
R1 (config-line) #  транспортный вход ssh 
R1 (config-line) #  логин локальный   

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

  R1 (config) #  имя пользователя пароль администратора my_password   

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

Клиент SSH

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

.

Вы увидите это на консоли шпатлевки:

  логин как:  admin 
Использование интерактивной аутентификации с клавиатуры.
Пароль:
R1>  

Вы также можете использовать другое устройство Cisco IOS в качестве клиента SSH.Вот как это сделать:

  R2 #  SSH? 
  -c Выбрать алгоритм шифрования
  -l Войти под этим именем пользователя
  -m Выбрать алгоритм HMAC
  -o Указать параметры
  -p Подключиться к этому порту
  -v Указать версию протокола SSH
  -vrf Указать имя vrf
  WORD IP-адрес или имя хоста удаленной системы  

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

  R2 #  ssh -l admin 192.168.12.1 
Пароль:

R1>  

Теперь мы подключены к R1 через SSH.

Конфигурации

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

R1

  имя хоста R1
!
доменное имя ip NETWORKLESSONS.LOCAL
ip cef
!
имя пользователя пароль администратора 0 my_password
!
интерфейс GigabitEthernet0 / 1
 IP-адрес 192.168.12.1 255.255.255.0
!
ip ssh версия 2
!
строка vty 0 4
 войти в систему
 транспортный ввод ssh
!
конец  

R2

  имя хоста R2
!
ip cef
!
интерфейс GigabitEthernet0 / 1
 IP-адрес 192.168.12.2 255.255.255.0
!
конец  

Сервер и клиент SSH

Заключение

Теперь вы узнали, как настроить SSH-сервер на вашем маршрутизаторе или коммутаторе Cisco IOS и как использовать SSH-клиент.

  • SSH — это безопасный метод удаленного доступа к вашему маршрутизатору или коммутатору, в отличие от telnet.
  • SSH требует пары открытый / закрытый ключ RSA.
  • SSH версии 2 более безопасен, чем версия 1.
  • Убедитесь, что у вас есть образ IOS, который поддерживает функции шифрования, иначе вы не сможете использовать SSH.

Как настроить маршрутизатор / коммутатор Cisco для включения SSH (Secure Shell) и Как подключить маршрутизатор / коммутатор Cisco с помощью SSH (Secure Shell)

Telnet — это протокол, который сетевые администраторы использовали для удаленного доступа к консоли CLI сервера или сетевого устройства. Telnet — это небезопасный протокол для настройки удаленного сервера. SSH заменил telnet, и SSH намного безопаснее, чем telnet. SSH поддерживает аутентификацию, конфиденциальность и целостность для удаленного администрирования.В наши дни Telnet используется только в качестве инструмента тестирования сети, такого как ping или netstat. Сетевые администраторы должны отключить telnet и по возможности использовать только SSH.

SSH (Secure Shell) — это протокол, который определяет, как безопасно подключаться по сети. Протокол SSH (Secure Shell) обеспечивает три основные идеи аутентификации безопасности, конфиденциальности (через шифрование) и целостности передачи данных по сети.

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

SSH имеет две основные версии: SSh2 и SSh3. И SSh2, и SSh3 поддерживают безопасное соединение по сети, но SSh3 поддерживает сертификаты открытого ключа и обмен ключами Диффи-Хеллмана.

SSH использует TCP в качестве протокола транспортного уровня и использует хорошо известный номер порта 22.

Как настроить SSH (Secure Shell) в маршрутизаторе или коммутаторе Cisco для безопасного удаленного доступа

Шаг 1: Первым шагом в настройке SSH для удаленного безопасного доступа к интерфейсу CLI маршрутизатора или коммутатора Cisco является создание локальной базы данных пользователей для аутентификации пользователей.Выполните следующие действия, чтобы создать локального пользователя с именем пользователя «jajish» и паролем «OmniSecuPass» и с уровнем привилегий 15.

 OmniSecuR1 # настроить терминал
OmniSecuR1 (config) # имя пользователя jajish привилегия 15 секрет OmniSecuPass
OmniSecuR1 (конфигурация) # выход
 

Шаг 2: Устройства Cisco используют алгоритм шифрования с открытым ключом RSA для подключения по SSH. Перед созданием ключей шифрования RSA необходимо изменить имя хоста по умолчанию для маршрутизатора или коммутатора Cisco. Имя устройства по умолчанию для маршрутизатора Cisco — «Маршрутизатор», а имя устройства по умолчанию для коммутатора Cisco — «Коммутатор».Вы также должны настроить доменное имя перед генерацией ключей RSA.

Следуйте этим командам интерфейса командной строки Cisco IOS, чтобы настроить имя хоста, имя домена и сгенерировать ключи RSA длиной 1024 бита. После генерации ключей RSA маршрутизатор / коммутатор Cisco автоматически включит SSH 1.99. SSH 1.99 показывает, что устройство Cisco поддерживает как SSH 2, так и SSH 1. SSH 1.99 — это не версия, а показатель обратной совместимости.

 Маршрутизатор #
Маршрутизатор # настроить терминал
Маршрутизатор (конфигурация) #hostname OmniSecuR1
OmniSecuR1 (config) #ip доменное имя omnisecu.ком
OmniSecuR1 (config) #crypto key сгенерировать общие ключи RSA
Название ключей будет: OmniSecuR1.omnisecu.com.
Выберите размер ключевого модуля в диапазоне от 360 до 2048 для вашего
  Ключи общего назначения. Выбор ключевого модуля больше 512 может занять
  несколько минут.

Сколько бит в модуле [512]: 1024
% При генерации 1024-битных ключей RSA ключи не будут экспортироваться ... [OK]
* 15 ноября 16:54: 20.595:% SSH-5-ENABLED: SSH 1.99 был включен
OmniSecuR1 (конфигурация) # выход
OmniSecuR1 #
 

Шаг 3: Следующим важным шагом, который вам нужно сделать, является настройка маршрутизатора / коммутатора на использование локальной базы данных пользователей для аутентификации и отключение telnet.Отключение telnet предотвратит случайное подключение кого-либо к маршрутизатору или коммутатору Cisco с помощью telnet и вызовет проблемы с безопасностью.

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

 OmniSecuR1 # настроить терминал
OmniSecuR1 (конфигурация) # строка vty 0 1869
OmniSecuR1 (строка конфигурации) #login local
OmniSecuR1 (строка конфигурации) #transport input ssh
OmniSecuR1 (строка конфигурации) #exit
OmniSecuR1 (конфигурация) #
 

Шаг 4: Для подключения к маршрутизатору Cisco или коммутатору Cisco с помощью SSH с рабочей станции Windows необходимо использовать клиентский инструмент SSH (клиентская утилита SSH не входит в комплект операционных систем Windows вплоть до Windows 7).Перейдите по ссылке, чтобы загрузить PuTTY, один из лучших бесплатных программ-эмуляторов терминала.

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

Шаг 5: Если вы подключаетесь к маршрутизатору Cisco или коммутатору Cisco впервые, вы получите предупреждение, как показано ниже, о том, что ключ узла маршрутизатора / коммутатора не кэшируется локально.Примите предупреждающее сообщение и нажмите «Да», чтобы подключиться к маршрутизатору или коммутатору Cisco.

Шаг 6: Введите идентификатор пользователя (jajish) и соответствующий пароль, которые мы настроили в маршрутизаторе / коммутаторе Cisco ранее, и нажмите «Enter».

Шаг 7: Теперь вы подключены к маршрутизатору или коммутатору Cisco по протоколу SSH. Теперь вы можете начать безопасную настройку маршрутизатора / коммутатора Cisco из удаленного места. Спасибо SSH и Тату Илонен (гению, который разработал SSH).

Настройка SSH и локальной аутентификации на Cisco ASA

Вот как настроить SSH на новом ASA из коробки, а также настроить локальную аутентификацию.

Шаг 1: Настройте aaa для использования локальной базы данных для ssh и консоли

ciscoasa # aaa authentication ssh console LOCAL

*** ПРИМЕЧАНИЕ *** aaa = аутентификация (разрешение доступа), авторизация (укажите команды при предоставлении доступа), учет (отслеживает отчеты об использовании пользователей после входа в систему и генерирует учетные отчеты для выставления счетов)
LOCAL = локальная база данных

Шаг 2: Создайте имя пользователя администратора с привилегией 15 (имя пользователя, P @ ssw0rd)

ciscoasa # имя пользователя имя пользователя пароль P @ ssw0rd priv 15

*** ПРИМЕЧАНИЕ *** priv 15 = высший уровень привилегий (полный суперпользователь, может давать разные команды доступа к разным уровням привилегий)

Шаг 3. Включите пароль для включения

ciscoasa # aaa authentication enable console LOCAL

*** NOTE *** принудительное введение пароля для запроса включения

Шаг 4. Включите аутентификацию последовательной консоли

ciscoasa # aaa authentication serial console L OCAL

*** ПРИМЕЧАНИЕ *** включает пользователя / пароль для последовательного доступа

Шаг 5: Сохраните изменения

ciscoasa # write mem

Шаг 6: выйдите из консоли и проверьте доступ

ciscoasa (config ) # end
ciscoasa # exit
Выход из системы
Имя пользователя: имя пользователя
Пароль: ********

Шаг 7: Сгенерируйте пару ключей ssh ​​

ciscoasa # crypto key generate rsa modulus 4096
INFO: Имя для ключи будут:
Процесс генерации пары ключей начнется.Подождите…
ciscoasa (config) # *** ПРИМЕЧАНИЕ *** SSH — это зашифрованный протокол, использующий RSA для генерации открытого и закрытого ключей
4096 = размер блока
rsa = алгоритм шифрования

Шаг 8: Разрешить доступ к внутренним данным interface

ciscoasa # ssh 0.0.0.0 0.0.0.0 внутри

*** ПРИМЕЧАНИЕ *** включить ssh-доступ к внутреннему интерфейсу с любого IPv4

Шаг 9: Принудительно использовать ssh версии 2

ciscoasa # ssh version 2

Шаг 10: Добавьте таймаут в 15 минут для ssh

ciscoasa # ssh timeout 15

Шаг 11: Подтвердите вход с помощью ssh через 192.168.1.1 in putty

вход в систему как: имя пользователя
имя пользователя@192.168.1.1 пароль:
Пользователь peiadmin вошел в систему ciscoasa
Входов за последние 1 день: 2. Последний вход: 16:47:06 UTC 2 августа 2018 г. с консоли
Неудачные попытки входа с момента последнего входа в систему: 0.
Введите help или «?» для получения списка доступных команд.
ciscoasa> en
Пароль: ********
ciscoasa #

Элисон Уоллик, PEI

Как настроить SSH на Cisco IOS XR

Обучение работе с Cisco Nexus — от новичка к продвинутому!
VDC, VPC, OTV, FRX и многие другие…

В этом уроке мы настроим SSH на маршрутизаторе с поддержкой Cisco IOS XR .Ранее мы настроили SSH на Cisco IOS, если вы хотите проверить эту статью, нажмите SSH на устройствах Cisco IOS.

SSH на Cisco IOS XR

Прежде всего, вы должны создать имя хоста и имя домена точно так же, как IOS или IOS-XE.
( ПРИМЕЧАНИЕ: В отличие от обычной IOS, IOS-XR не требует имени хоста и имени домена для генерации ключа RSA.)

 RP / 0/0 / CPU0: ios (config) #hostname IOS-XR
RP / 0/0 / CPU0: ios (config) #domain name ios-xr.local 

Создание RSA немного отличается от обычного IOS.Это нужно делать в режиме EXEC. Вам нужно использовать команду crypto key generate rsa и нажать ENTER , чтобы использовать биты 2048, которые используются по умолчанию в IOS-XR.

 RP / 0/0 / CPU0: IOS-XR # криптоключ генерирует rsa
Ср 29 янв 10: 21: 54.667 UTC
Имя для ключей будет: the_default
  Выберите размер ключевого модуля в диапазоне от 512 до 4096 для вашей пары ключей общего назначения. Выбор ключевого модуля более 512 может занять несколько минут.

Сколько бит в модуле [2048]:
Генерация ключей RSA...
Готово с генерацией криптографической пары ключей
[OK]

RP / 0/0 / CPU0: IOS-XR # 

Для проверки ключа RSA используйте команду show crypto key mypubkey rsa .

 RP / 0/0 / CPU0: IOS-XR # показать криптоключ mypubkey rsa
Ср 29 янв 10: 24: 51.315 UTC
Ярлык ключа: the_default
Тип: RSA общего назначения
Размер: 2048
Создано: 10:22:19 UTC Ср 29 Янв 2020
Данные     :
 30820122 300D0609 2A864886 F70D0101 01050003 82010F00 3082010A 02820101
 00953D06 8133BAC3 D6A2FAA7 D50AE7C2 3BD4A5EF 495E2022 3AA0A59E 8FF6BCEF
 9783BA10 8518B5E0 C3E11616 5E1814E7 048A5A0B 7157C88E AF413D99 AA69DE91
 9FB9B796 67378912 44FB6073 FFD153CE 19B364F4 6F9CCCF7 135DF7DD BF22C1EE
 48A32171 D9D2C004 9FF18E93 58AEEFF6 72B5EF60 30F4D4B4 A1493960 D4D5A9F7
 3E2553BC 17D3395C C28EC8F2 A78EBF1E DB092783 C71C1579 34829D1B 8E933F8B
 9A71BBD7 CB84DF90 F3F59557 4368DC5B 9D2528AA 5FEC4CED D5C9F73C 0303BC24
 CA01C6C8 D622A269 12C915F6 3246A624 C72AF20F 2DFBCBEA 9C4C339C 8BB607A3
 BEBCC6CC 1C4E4460 81B21716 3AD7DF98 C71D7AD2 1CB7DA59 03FAD3DF 776A96A0
 3D020301 0001 

Давайте включим SSH версии 2, а также разрешим ssh для удаленного доступа.

 RP / 0/0 / CPU0: ios (config) #ssh server v2
RP / 0/0 / CPU0: ios (config) #line default transport input ssh 

Вот как вы настраиваете ssh на устройствах Cisco IOS-XR .

А что, если вы хотите ограничить вход по SSH. Для этого вам нужно перейти на control-plane management-plane . Здесь вы выбираете опцию входящего или исходящего управления.

 RP / 0/0 / CPU0: ios (config) # control-plane management-plane
RP / 0/0 / CPU0: ios (config-mpp) #?
....
  inband Настроить внутриполосный интерфейс / протокол
....
  внеполосный Настроить внеполосный интерфейс / протокол
....
RP / 0/0 / CPU0: ios (config-mpp) # 

В нашем случае это входящий, потому что мы используем gigabitEthernet 0/0/0/0 . Итак, окончательная конфигурация будет ниже, где мы разрешаем только блокировку 10.1.1.0/24.

 RP / 0/0 / CPU0: ios (config) # control-plane management-plane
RP / 0/0 / CPU0: ios (config-mpp) #inband interface gigabitEthernet 0/0/0/0
RP / 0/0 / CPU0: ios (config-mpp-inband-if) # разрешить одноранговый адрес SSH ipv4 10.1.1.0 / 24
RP / 0/0 / CPU0: ios (config-mpp-inband-if) #commit 

Verification:

Чтобы проверить, мы можем иметь собственный IP-адрес SSH (192.168.3.100 — это IP-адрес управления для нашего примера).

 RP / 0/0 / CPU0: IOS-XR # ssh 192.168.3.100

Пожалуйста, войдите с любым настроенным пользователем / паролем или cisco / cisco

Пароль: 

Команда «показать подробности сеанса ssh» покажет сведения о сеансе ssh.

 RP / 0/0 / CPU0: IOS-XR # показать детали сеанса ssh
Ср 29 янв, 10: 28: 02.322 UTC
Версия SSH: Cisco-2.0

Идентификатор обмена ключами pubkey incipher outcipher inmac outmac
-------------------------------------------------- -----------------
Входящая сессия
0 diffie-hellman ssh-rsa aes256-cb aes256-cb hmac-sha1 hmac-sha1

Исходящее соединение
RP / 0/0 / CPU0: IOS-XR # 

Как настроить SSH в GNS3

Для настройки маршрутизаторов Cisco в первый раз необходимо использовать консольное соединение. После подключения к устройству с помощью консоли вы можете назначить IP-адрес, а затем включить Telnet или SSH для управления через LAN / WAN.

Как настроить SSH на маршрутизаторе Cisco

По соображениям безопасности не рекомендуется настраивать маршрутизаторы с Telnet через LAN или WAN. Рекомендуется настроить SSH-соединение вместо Telnet.

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

В нашей предыдущей статье мы рассмотрели, как установить Telnet-соединение. В этой статье мы также настроим SSH на маршрутизаторе с помощью симулятора сети.

Как включить SSH в маршрутизаторе Cisco

Мы будем использовать GNS3 и VMware Workstation для настройки. Создайте новую виртуальную машину в VMware и установите операционную систему Windows.

Если вы еще не добавляли образ маршрутизатора IOS, вы можете взглянуть на Добавление маршрутизаторов в GNS3.

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

Шаг 1

Теперь откройте программу GNS3 и введите имя нового проекта.

Шаг 2

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

Шаг 3

Добавьте коммутатор и хост в рабочую область и подключите сетевые устройства.

Шаг 4

После создания небольшой топологии сети откройте редактор виртуальной сети программы виртуализации VMware и настройте VMnet для виртуальной машины.

Шаг 5

Создайте виртуальную сеть в программе Virtual Network Editor, а затем назначьте ей IP-адрес из сети и настройки центра общего доступа на вашем хосте, как показано на изображении ниже.

Шаг 6

Введите IP-блок для VMnet3 в виртуальном редакторе, выберите Host-Only и нажмите OK.

Шаг 7

Настройте параметр сетевого адаптера виртуальной машины на Custom (VMnet3).

Шаг 8

Настройте параметр сетевого адаптера виртуальной машины на Custom (VMnet3). Щелкните Start / Resume all nodes , чтобы запустить маршрутизатор.

Шаг 9

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

  R1 # конф т
R1 (config) # interface fastethernet0 / 0
R1 (config-if) # IP-адрес 192.168.8.1 255.255.255.0
R1 (config-if) # выключения нет
R1 (config-if) # выход
R1 (config) #ip доменное имя sysnettechsolutions.com
R1 (config) #crypto key генерирует модуль общих ключей rsa 1024
Название ключей будет: R1.sysnettechsolutions.com.
% Размер ключевого модуля составляет 1024 бит
% При генерации 1024-битных ключей RSA ключи не будут экспортироваться ... [OK]
R1 (config) # тайм-аут ip ssh 15
R1 (config) # ip ssh повторные попытки аутентификации 2
R1 (config) # ip ssh версия 2
R1 (config) # имя пользователя cisco привилегия 15 пароль cisco123
R1 (config) # строка vty 0 4
R1 (config-line) # вход локальный
R1 (config-line) # уровень привилегий 15
R1 (config-line) # транспортный ввод ssh
R1 (config-line) # выход
R1 (config) # конец
R1 # wr
  


Шаг 10

Откройте программу Putty на своем виртуальном компьютере и введите IP-адрес интерфейса FastEthernet0 / 0 маршрутизатора в разделе IP-адресов и введите 22 в раздел Номер порта и нажмите кнопку Открыть .

Шаг 11

В окне предупреждения безопасности Putty нажмите Да.

Шаг 12

SSH-соединение с маршрутизатором будет успешно установлено, как показано на следующем рисунке.

Введите имя пользователя, которое вы создали в поле «Войти как», и нажмите Enter.

Шаг 13

Введите пароль пользователя (cisco123), который вы создали в разделе «Пароль», и нажмите Enter.

Step 14

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

Шаг 15

Чтобы просмотреть сеансы SSH на маршрутизаторе, введите команду show line в привилегированном режиме и нажмите Enter.

Вы можете проверить соединения Telnet или SSH на изображении ниже.

Шаг 16

Чтобы проверить версию SSH, выполните команду show ssh в привилегированном режиме настройки.

Вы можете проверить, что версия SSH — 2.0 в выходных данных команды show.

Шаг 17

Вы можете использовать [ ssh -l (имя пользователя) (IP-адрес маршрутизатора) ] в командной строке, чтобы инициировать сеанс SSH на ПК или другом маршрутизаторе на сеть.

Шаг 18

Чтобы подключиться от маршрутизатора к маршрутизатору, выполните команду ssh -l cisco 192.168.8.1 , введите свой пароль и нажмите Enter.

Шаг 19

Вы можете снова увидеть сеансы SSH, используя команду show ssh.

Шаг 20

Используйте команду show line для отображения текущего сеанса.

Шаг 21

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

Как подключиться от маршрутизатора к маршрутизатору с помощью протокола SSH ⇒ Видео

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

Final Word


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

Статьи по теме


♦ Интерфейс маршрутизатора Cisco
♦ Как подключить GNS3 к VMware
♦ GNS3 DHCP
♦ Статический NAT GNS3
♦ GNS3 Dynamic NAT

Конфигурация

SSH на маршрутизаторе Cisco

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

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

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

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

Зачем использовать Secure Shell (SSH)?

Secure Shell (SSH) повышает безопасность сети, предоставляя средства установления безопасных соединений с сетевыми устройствами для управления, тем самым предотвращая доступ хакеров.

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

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

Цифровые сертификаты можно получить тремя разными способами. Самый безопасный (и дорогостоящий) — запросить его у доверенной компании, которая называется CA — Certificate Authorities. Примером одной из таких компаний является VeriSign, которая пользуется большой популярностью в индустрии CA благодаря своей роли в предоставлении всемирно доверенных сертификатов; Однако эти сертификаты могут стоить довольно дорого.

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

А как насчет Telnet?

Как и SSH, Telnet также можно использовать для подключения к вашему маршрутизатору, но основным недостатком использования Telnet является то, что он не шифрует свои соединения.Это означает, что если хакер может перехватывать пакеты из сеанса Telnet, он или она сможет просматривать информацию, содержащуюся в этих пакетах, такую ​​как имя пользователя и пароль клиента, тем самым получая доступ к вашему маршрутизатору.

Диаграмма ниже даст вам представление о том, как это работает.

Конфигурация маршрутизатора SSH

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

Для этого упражнения я буду использовать маршрутизатор SOHO серии Cisco 871 с версией IOS. 12.4 программное обеспечение. В зависимости от того, является ли ваш маршрутизатор новым или в настоящее время находится в производственной среде, вам придется подключиться либо через сеанс консоли, либо через сеанс Telnet.

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

Вот шаги:

1. Настройте имя хоста для маршрутизатора с помощью этих команд.

ваше имя # configure terminal

Введите команды настройки, по одной в каждой строке. Закончите CNTL / Z.

yourname (config) #hostname LabRouter

LabRouter (config) #

2. Сконфигурируйте доменное имя с помощью команды ip domain-name , за которой следует любое имя вашего домена. Я использовал CiscoLab.com.

LabRouter (config) #ip доменное имя CiscoLab.com

3. Мы генерируем сертификат, который будет использоваться для шифрования пакетов SSH с помощью команды crypto key generate rsa .

Обратите внимание на сообщение, которое отображается сразу после ввода этой команды: «Имя ключей будет: LabRouter.CiscoLab.com» — оно объединяет имя хоста маршрутизатора вместе с именем домена, которое мы настроили. получить имя сгенерированного ключа шифрования; Вот почему для нас было важно, прежде всего, настроить имя хоста, а затем имя домена, прежде чем мы сгенерируем ключи.

Обратите внимание, что он просит нас выбрать размер модуля для ключа, который мы собираемся сгенерировать. Чем выше модуль, тем сильнее шифрование ключа. В нашем примере мы будем использовать модуль 1024.

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

LabRouter (config) #line vty 0 4

LabRouter (config-line) #login local

LabRouter (config-line) #transport input ssh

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

LabRouter (config) # имя пользователя XXXX привилегия 15 секрет XXXX

Тонкая настройка конфигурации SSH

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

С одной стороны, я настоятельно рекомендую вам включить тайм-аут exec на вашем маршрутизаторе, чтобы никто не мог получить доступ к устройству в случае, если вы забыли выйти из системы или отвлеклись из-за чрезвычайной ситуации. Таким образом, маршрутизатор автоматически выйдет из системы после того, как сеанс будет бездействовать в течение установленного времени.

Вы должны настроить эту команду на линейном интерфейсе, как показано ниже.

LabRouter (config) #line vty 0 4

LabRouter (config-line) # exec-timeout 5

Это означает, что если сеанс простаивал в течение 5 минут, маршрутизатор автоматически отключит сеанс.

Используйте списки контроля доступа (ACL) в качестве дополнительного уровня безопасности; это гарантирует, что только устройства с определенным IP-адресом смогут подключиться к маршрутизатору.

Итак, предположим, что IP-подсеть для вашей LAN — 192.168.100.0/24, вы должны создать acl, чтобы разрешить только трафик из этой подсети, и применить этот acl к линиям vty.

LabRouter (config) # access-list 1 permission 192.168.100.0 0.0.0.255

LabRouter (config) #line vty 0 4

LabRouter (config-line) # access-class 1 in

Заключительный совет: Включить SSh3

Еще один важный момент, на который следует обратить внимание, — это использование SSh3, а не SSh2.

Добавить комментарий

Ваш адрес email не будет опубликован.