SSH к Cisco без пароля: настройка через RSA-ключи

SSH-аутентификация по ключам давно стала стандартом в Linux/Unix-мире, а Cisco IOS (и NX-OS) поддерживает её ещё с начала 2000-х.

Основное преимущество ключей перед паролями:

⏺невозможно перебрать брутфорсом (если ключ длинный),
⏺админ не хранит пароли в заметках/Excel,
⏺удобно централизованно управлять доступом: добавил или удалил ключ в pubkey-chain — и доступ сразу появился/пропал.

У каждого пользователя есть пара ключей: приватный (хранится у него) и публичный (копируется на устройство).

При подключении клиент доказывает владение приватным ключом, а Cisco сравнивает это с публичным — если совпадает, вход разрешён.

В отличие от классической схемы логин+пароль, тут нет ввода секретов в консоль, поэтому утечка через keylogger или сниффинг невозможна (при условии, что приватный ключ защищён паролем).

Практика

1️⃣Включаем SSH на Cisco

conf t
ip domain-name lab.local
crypto key generate rsa modulus 2048
ip ssh version 2

2️⃣Создаём пользователя

username admin privilege 15 secret StrongPass123

3️⃣Подтягиваем публичный ключ
На клиенте:

ssh-keygen -t rsa -b 2048

Копируем содержимое ~/.ssh/id_rsa.pub и добавляем на Cisco:

ip ssh pubkey-chain
  username admin
   key-string
    ssh-rsa AAAAB3... user@host
   exit
 exit

4️⃣Ограничиваем доступ только по ключам

line vty 0 4
 transport input ssh
 login local

Теперь при подключении:

ssh admin@router

пароль не нужен.

Нюансы

⏺Можно завести нескольких пользователей с разными ключами.
⏺При увольнении сотрудника ключ просто удаляется из pubkey-chain → не надо менять общий пароль.
⏺Минимальный размер ключа лучше 2048, а в проде — 4096 бит.
⏺Рекомендовано всегда включать только SSHv2 — SSHv1 давно небезопасен.

NAT64 и DNS64: доступ IPv6-only клиентов к IPv4 ресурсам

В сетях, где используется только IPv6, часто возникает проблема: клиентам нужно обращаться к сервисам, которые ещё доступны только по IPv4. Решение — комбинация NAT64 и DNS64.

DNS64 преобразует A-записи IPv4 в синтетические AAAA-записи IPv6. 

Когда клиент делает запрос к IPv4-хосту, он получает IPv6-адрес, который указывает на NAT64-шлюз.

NAT64 на маршрутизаторе или сервере превращает этот IPv6-трафик обратно в IPv4 и перенаправляет его к целевому серверу. Ответ идёт обратно по тому же пути.

Где применяют:
⏺IPv6-only датацентры или филиалы, где внутренние клиенты не имеют IPv4.
⏺Переходные сценарии при массовой миграции на IPv6.
⏺Обеспечение совместимости с внешними сервисами, которые не поддерживают IPv6.

Пример конфигурации на Cisco IOS:

! Создание NAT64-пула
ipv6 nat64 v6v4-pool POOL1 192.0.2.0 192.0.2.255 prefix-length 96
! Включение NAT64 на интерфейсе
interface GigabitEthernet0/1
ipv6 nat64 enable
! Включение DNS64 на Cisco IOS XE
ipv6 dns64 64:ff9b::/96

На Juniper JunOS это выглядит так:

set security nat64 pool NAT64-POOL address 192.0.2.0/24
set security nat64 interface fe-0/0/0.0
set system services dns dns64 prefix 64:ff9b::/96

И еще советы:
➖Проверяйте, что префикс NAT64 корректно согласован с DNS64.
➖Не все приложения корректно работают через NAT64 (например, некоторые старые FTP-клиенты).
➖Мониторьте нагрузку на NAT64-шлюз, он становится точкой концентрации трафика.

Используя NAT64/DNS64, можно постепенно убирать IPv4 из инфраструктуры без потери совместимости с внешними сервисами.

TCP Tuning для высокой нагрузки

В больших сервисах стандартные сетевые настройки ядра Linux иногда становятся узким местом.

Например, при сотнях тысяч одновременных соединений сервер может «терять» пакеты SYN, а TCP-сессии застревать в TIME_WAIT. Чтобы этого избежать, настраивают несколько параметров через sysctl.

Основные параметры

1️⃣net.core.somaxconn
Определяет максимальное количество ожидающих соединений в очереди listen().

# посмотреть текущее значение
sysctl net.core.somaxconn
# увеличить до 65535
sudo sysctl -w net.core.somaxconn=65535

2️⃣ tcp_max_syn_backlog
Размер очереди незавершённых TCP-соединений (SYN). Важно при пиковых нагрузках.

sudo sysctl -w net.ipv4.tcp_max_syn_backlog=4096

3️⃣ tcp_fin_timeout
Время удержания соединений в FIN_WAIT2, которое может «засорять» сервер.

sudo sysctl -w net.ipv4.tcp_fin_timeout=15

4️⃣ tcp_tw_reuse и tcp_tw_recycle (внимание: tcp_tw_recycle устарел и опасен для NAT)
Позволяет повторно использовать TIME_WAIT-сессии для новых соединений.

sudo sysctl -w net.ipv4.tcp_tw_reuse=1

Проверка эффекта

➖Посмотреть количество TIME_WAIT-соединений:

ss -s | grep timewait

➖Нагрузить сервер с помощью ab или wrk и сравнить, сколько соединений сервер держит без потерь.

Автоматизация

Чтобы настройки сохранялись после перезагрузки, добавьте их в /etc/sysctl.conf:

net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1

и примените:

sudo sysctl -p

💬 Вопрос на собеседовании для сисадмина

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Что такое CPU isolcpus и как это влияет на производительность Linux-систем?

✅Ответ: Параметр isolcpus ядра Linux позволяет изолировать один или несколько процессоров от планировщика задач общего назначения. Это значит, что ядро не будет автоматически распределять на них обычные процессы, оставляя их “чистыми” для определённых критичных задач, например, для real-time приложений или высокопроизводительных сервисов.

Secure Copy больших файлов: rsync vs scp

При работе с десятками гигабайт через SSH обычный scp начинает тормозить.

Почему?

Потому что он копирует файл целиком, без возможности возобновления, и каждый раз создаёт новое TCP-соединение.

Rsync через SSH решает это:
⏺Передача только изменений (--partial и --inplace)
⏺Можно включить сжатие (-z)
⏺Поддерживает батчевую передачу и возобновление

Примеры:

Копирование одного большого файла с rsync:

rsync -avz --progress /local/largefile user@remote:/backup/

Если соединение обрывается, можно повторно выполнить команду — rsync продолжит с места прерывания.

Копирование каталога с контрольным мультиплексированием SSH:

Host remote
    HostName 203.0.113.10
    User admin
    ControlMaster auto
    ControlPath ~/.ssh/cm-%r@%h:%p
    ControlPersist 10m

А затем:

rsync -avz /local/dir remote:/backup/dir

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

scp с мультиплексом и сжатием:

scp -o ControlMaster=auto -o ControlPath=~/.ssh/cm-%r@%h:%p -C /local/largefile remote:/backup/

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

Sysctl для серверов с большим числом подключений

Когда сервер обслуживает сотни тысяч TCP-сессий, стандартные настройки ядра Linux могут стать узким местом.

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

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

⏺net.ipv4.ip_local_port_range — диапазон локальных портов для исходящих соединений. Увеличение диапазона помогает избежать исчерпания портов при массовых подключениях.
⏺net.ipv4.tcp_tw_reuse — разрешает повторное использование сокетов в состоянии TIME_WAIT для новых исходящих соединений.
⏺net.ipv4.tcp_tw_recycle — ускоряет очистку TIME_WAIT (не рекомендуется для NAT).
⏺net.core.netdev_max_backlog — размер очереди пакетов в драйвере сети. Увеличение помогает при пиках входящего трафика.

Измеряем эффект

➖До изменений:

ss -s | grep TIME-WAIT
cat /proc/sys/net/core/netdev_max_backlog

➖Применяем sysctl:

sudo sysctl -w net.ipv4.ip_local_port_range="1024 65535"
sudo sysctl -w net.ipv4.tcp_tw_reuse=1
sudo sysctl -w net.core.netdev_max_backlog=5000

➖После изменений: повторяем измерения TPS (запросов в секунду) и TIME_WAIT.

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

Bcachefs теперь «внешне поддерживаемая»

28 августа 2025 года Линус Торвальдс перевёл файловую систему Bcachefs в режим Externally maintained. 

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

⏺Причина — конфликты с автором проекта Кентом Оверстритом: он присылает крупные изменения в неподходящее время, нарушая процесс ядра.

Торвальдс считает, что поздние релизы должны лишь исправлять ошибки, а Оверстрит настаивает на срочном исправлении багов для сохранности данных. Bcachefs остаётся экспериментальной ФС.

Logrotate для нестандартных приложений

Стандартные сервисы вроде Nginx или syslog ротируются автоматически, а вот для нестандартных daemon или собственных приложений нужно использовать postrotate, sharedscripts и правильно обрабатывать сигнал HUP.

⏺postrotate — команды после ротации (например, сигнал процессу перечитать лог).
⏺sharedscripts — если несколько файлов ротируются, скрипт выполняется один раз.
⏺HUP — заставляет daemon перечитать файл без перезапуска.

Пример для PostgreSQL:

/var/log/postgresql/*.log {
    daily
    rotate 7
    compress
    delaycompress
    notifempty
    missingok
    sharedscripts
    postrotate
        systemctl reload postgresql > /dev/null 2>/dev/null || true
    endscript
}

Здесь логи сжимаются и хранятся неделю, пустые файлы не ротируются, а PostgreSQL после ротации продолжает писать в новый файл.

Пример для Nginx:

/var/log/nginx/*.log {
    daily
    rotate 14
    missingok
    notifempty
    sharedscripts
    postrotate
        [ -f /run/nginx.pid ] && kill -HUP `cat /run/nginx.pid`
    endscript
}

Можно добавить уведомление админа через mail или Slack.

Мониторинг открытых файлов: lsof

В Linux всё — это файл. Сюда попадают не только документы на диске, но и сокеты, устройства, пайпы.

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

В таких случаях незаменим инструмент lsof (list open files).

Несколько базовых приёмов:
⏺lsof /path/to/file — покажет, какой процесс держит файл открытым. Полезно, если удалённый лог «не освобождает» место.
⏺lsof -i :8080 — кто слушает порт 8080 или держит соединение. Отлично работает при отладке сервисов.
⏺lsof -u www-data — все открытые файлы конкретного пользователя, например, у веб-сервера.

Кроме поиска по файлам и портам, lsof помогает находить процессы с утечками дескрипторов. Иногда сервисы постепенно «съедают» лимит открытых файлов, и тогда lsof -p <PID> покажет, чем именно завален процесс.

🔥 В связке с df и du утилита позволяет быстро вычислить «невидимых пожирателей места», а при отладке сетей — вычленить подозрительные соединения.

Инструмент старый, но до сих пор один из самых надёжных для диагностики.

💬 Вопрос на собеседовании для DevOps-инженера

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Что такое Transparent Hugepage defrag и как это влияет на производительность системы?

✅Ответ: Transparent Hugepage (THP) defrag — это механизм в Linux, который пытается объединять мелкие страницы памяти в большие (HugePages) для оптимизации TLB и уменьшения накладных расходов на управление памятью.

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

Поиск «тяжёлых» файлов: ncdu

Когда на сервере заканчивается место, команды вроде du и ls -lh не всегда помогают быстро понять, что именно съедает дисковое пространство. 

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

Например, чтобы проверить логи:

ncdu /var/log

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

Это помогает находить крупные логи, временные файлы и другие объекты, которые занимают место, без необходимости писать сложные скрипты.

Плюсы ncdu:
⏺Видно, сколько реально занимает каждая папка.
⏺Можно удалять или перемещать файлы прямо в интерфейсе.
⏺Быстро ориентируетесь на серверах с ограниченным SSD.
⏺Подходит для диагностики как пользовательских, так и системных директорий.

Быстрый поиск строк в логах: ripgrep

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

Здесь помогает ripgrep (rg) — современный инструмент поиска по тексту. 

Он оптимизирован под большие объёмы данных и работает в разы быстрее.

Пример для поиска ошибок во всех логах:

rg "ERROR" /var/log

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

Если нужен контекст вокруг найденной строки:

rg -C 3 "FATAL" /var/log/postgresql

Так выводятся три строки до и после совпадения — удобно при анализе логов PostgreSQL, Nginx или системных журналов.

⏺ripgrep поддерживает регулярные выражения, можно искать сразу несколько шаблонов и фильтровать файлы по расширениям. Например:

rg -t sql "SELECT.*FROM" /var/log

Вывод ограничится только SQL-логами.

💬 Вопрос на собеседовании для сисадмина

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Как работает механизм Copy-on-Write (CoW) в Linux и зачем он нужен?

✅Ответ: Copy-on-Write (CoW) — это оптимизационный механизм, который позволяет нескольким процессам совместно использовать одну и ту же область памяти до тех пор, пока один из них не попытается ее изменить.

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

BGP PIC (Prefix Independent Convergence)

BGP PIC ускоряет failover, предустанавливая резервный next-hop. 

При падении primary hop трафик мгновенно переключается без полной перерасчётки маршрутов. Обычно обычный BGP failover занимает секунды, с PIC — миллисекунды.

Применяется в WAN и датацентрах с критическим SLA, ECMP-сценариях, L3VPN/EVPN.

Виды:

⏺Core (по префиксу) — precomputed backup next-hop в FIB, переключение мгновенное.
⏺Edge (по соседу) — резерв на уровне BGP-соседа, удобно для PE/CE.

Настройка на Cisco IOS-XR:

router bgp 65001
 address-family ipv4 unicast
  bgp bestpath pic
  network 10.0.0.0 mask 255.255.255.0

Juniper JunOS:

protocols {
 bgp {
  group IBGP {
   type internal;
   local-address 192.168.0.1;
   family inet { unicast; }
   pic;
  }
 }
}

Для проверки failover включают BFD, пингуют primary hop и отключают линк. С BGP PIC потеря пакетов минимальна, трафик идёт на backup сразу.

⚡️Особенности: резервный next-hop должен быть в FIB, потребляет RAM/CPU для precompute, на больших таблицах BGP может потребоваться tuning.