Устанавливаем 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 по протоколу SSH ?» возникает у каждого, кто сталкивается с этим оборудованием. Ответ — «Просто!»
Для примера возьмем модель маршрутизатора Cisco 881 . Команды для настройки других маршрутизаторов (1841, 2800, 3825…) или коммутаторов (2900, 3500, 4800…) будут аналогичными. Различие может быть лишь в настройке интерфейсов. (Настройка доступ по протоколу SSH на межсетевые экраны Cisco ASA описана в статье « »
Итак, в нашем распоряжении:

Задача: настроить защищенное подключение к маршрутизатору Cisco с помощью протокола SSH и обеспечить безопасное удаленное управление.

Шаг 0. Настройка интерфейса

На маршрутизаторе должен быть включен интерфейс, который будет использоваться для управления. В нашем случае это будет внутренний (LAN ) интерфейс Fastethernet 0 .

Для справки:
На Маршрутизаторе Cisco 881 имеется один интерфейс 3го уровня Fastethernet 4 (тот, на котором сразу можно задать IP адрес) и встроенный коммутатор с четырьмя интерфейсами 2го уровня (Fastethernet 0 – Fastethernet 3 ). На каждый из этих 4ех интерфейсов можно привязать по одному(!) виртуальному интерфейсу 3го уровня. (Vlan ).
Для интерфейса управления маршрутизатора выбираем первый доступный адрес в сети офиса — 192.168.0.1 . Далее заходим в настройки виртуального интерфейса Vlan 1 и присваиваем ему этот ip адрес. После этого привязываем его к одному из физических интерфейсов маршрутизатора (Fastethernet 0 ) и включаем его командой no shut .

Для наглядности:
ip address => interface Vlan X => interface Fastethernet Y
Задаем ip адрес на интерфейсе Vlan 1
R-DELTACONFIG (config)#
interface Vlan 1
ip address 192.168.0.1 255.255.255.0
no shutsown
Привязываем Vlan 1 к физическому интерфейсу FastEthernet 0
R-DELTACONFIG (config)#
interface Fa 0
switchport access vlan 1
no shutsown
Последнее действие выполняется для того, чтобы убедиться в корректности настройки. Vlan 1 привязан по умолчанию к каждому интерфейсу 2го уровня и строчка будет отображаться в конфигурации только, если номер Vlan будет отличаться от 1.
Далее необходимо проверить доступность созданного интерфейса с самого маршрутизатора, а затем с любой рабочей станции офиса, например с рабочей станции администратора. Подойдет простая проверка командой Ping . Естественно, что интерфейс маршрутизатора Fastethernet 0 должен быть соединен с коммутатором локальной сети (или напрямую с компьютером администратора) и адрес компьютера, с которого выполняется проверка, находится в той же сети, что и адрес интерфейса маршрутизатора (например 192.168.0.10 ).

Шаг 1 Создание учетной записи администратора

Для удаленного управления требуется создать учетную запись, если таковая еще отсутствует.
R-DELTACONFIG (config)#
username admin secret *****
Вместо звездочек ****** задаем пароль для учетной записи admin.

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

Шаг 2 задание пароля на режим конфигурирования

При открытии консоли управления маршрутизатором пользователь попадает в упрощенный режим, из которого возможно посмотреть лишь некоторые параметры устройства и техническую информацию о нем. При этом рядом с названием устройства присутствует знак стрелки «> »
R-DELTACONFIG>
Для просмотра конфигурации маршрутизатора и дальнейшей его настройки необходимо ввести команду enable
> enable
#
Изначально этот режим не защищен паролем и любой пользователь, который подключился консольным кабелем (про кабель и как подключиться описано в ) сможет попасть в режим конфигурирования . С другой стороны, пользователь, который подключился удаленно (ssh/telnet ),для которого не задан уровень привилегий (как раз наш случай), не сможет попасть в режим конфигурирования.
Задаем пароль на привилегированный режим (знак решетки # рядом с именем маршрутизатора), зайдя в режим конфигурирования (conf t ).
R-DELTACONFIG (config)#
R-DELTACONFIG (config)# enable secret ******
Этот пароль будет единым для всех пользователей.
Подробнее про режимы конфигурирования можно прочитать .

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

Для удаленного управления необходимо указать способ аутентификации пользователя командой login local
R-DELTACONFIG (config)#
line vty 0 4
login local
После выполнения этого шага и при условии, что интерфейс управления маршрутизатора доступен пользователю, становится возможным подключение к маршрутизатору с помощью протокола telnet . Для этого необходимо из командной строки рабочей станции администратора выполнить команду
C:\Documents and Settings\***>telnet 192.168.0.1
Должен последовать запрос пользователя и пароля, которые были заданы в шаге 1 . После успешной авторизации будет доступен упрощенный режим управления маршрутизатора (со стрелкой «> «). Для доступа к привилегированному режиму (# ) необходимо ввести команду enable , а после пароль из шага 2 .

Шаг 4 Настройка SSH

При использовании протокола Telnet (TCP порт 23) все команды и данные о конфигурировании устройства передаются в открытом виде, что потенциально небезопасно. Для защиты подключения используется протокол SSH (TCP порт 22).
Для настройки подключения через протокол SSH необходимо задать имя домена (любое), сгенерировать криптографический ключ доступа и включить сам протокол SSH версии 2.
R-DELTACONFIG (config)#
ip domain-name сайт
crypto key generate rsa
Choose the size of the key modulus in the range of 360 to 2048 for your
General Purpose Keys. Choosing a key modulus greater than 512 may take
a few minutes.
// после запроса необходимо указать 1024
How many bits in the modulus : 1024
% Generating 1024 bit RSA keys, keys will be non-exportable...
ip ssh ver 2
После выполнения этого шага появляется возможность подключаться через SSH с помощью специальной программы, поддерживающей данную функцию, например putty . Скачать можно по этой ссылке .

Шаг 5. Ограничение подключения к маршрутизатору только через SSH

Для того, чтобы исключить возможность подключения к маршрутизатору по протоколу Telnet необходимо ввести следующие команды:
R-DELTACONFIG (config)#
line vty 0 4
transport input ssh
После этого удаленный доступ к консоли устройства будет невозможен кроме как по протоколу SSH.
Дополнительно можно ограничить доступ к управлению маршрутизатором или коммутатором Cisco только с определенных ip адресов. Как это сделать описано .

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

Важно!

Не забудьте сохранить конфигурацию всех устройств командой write или copy run start . Иначе после перезагрузки все изменения будут потеряны.
write
Building configuration...

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

Подключение и настройка 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 на этом завершается. При потребности всегда можно сделать сброс на заводские настройки и выполнить настройки «с нуля».