Логин пользователя vty lines ssh. Ограничения 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 практически всегда интегрирована даже в самый минималистичный вариант ОС. Исключением можно считать разве что достаточно старые 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 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, в отличие от telnet, осуществляет шифрование всей информации, в том числе передаваемых паролей. В статье будет рассмотрена настройка SSH сервера на оборудовании Cisco, позволяющего осуществлять безопасное удаленное управление устройствами.
Настройка SSH на Cisco. Обязательные параметры.
Для включения SSH в Cisco IOS необходимо выполнить следующие 5 обязательных шагов.
1. Задать имя устройства при помощи команды hostname
(config)#hostname sw012. Задать имя пользователя и пароль
(config)#username Admin1 secret 5 $1$ukk...3. Настроить DNS домен при помощи команды ip domain-name
(config)#ip domain-name domain.ru4. Сгенерировать 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 23. Логирование событий протокола SSH
(config)#ip ssh logging eventsПри этом в логах можно будет увидеть какие пользователи с каких хостов пытались получить доступ к устройству.
1w5d: %SSH-5-SSH2_SESSION: SSH2 Session request from 192.168.1.2
(tty = 0)
using crypto cipher "aes128-cbc", hmac "hmac-md5" Succeeded
1w5d: %SSH-5-SSH2_USERAUTH: User "Admin1"
authentication for SSH2 Session
from 192.168.1.2
(tty = 0) using crypto cipher "aes128-cbc", hmac "hmac-md5"
Succeeded
Наличие в логах большого количества записей о неуспешной аутентификации либо записей с попыткой аутентификации под несуществующим именем пользователя может говорить о попытках подбора пароля.
1w5d: %SSH-5-SSH2_USERAUTH: User "User"
authentication for SSH2 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.