SSH Доступ: Полное техническое руководство по безопасному удалённому управлению сервером

SSH (Secure Shell) — это криптографический сетевой протокол, который устанавливает зашифрованный туннель между двумя сетевыми хостами, обеспечивая аутентифицированное выполнение команд, передачу файлов и перенаправление портов через ненадёжные сети. По умолчанию он работает на TCP-порту 22 и заменяет предшественников с открытым текстом — Telnet, rsh и FTP — протоколом, обеспечивающим конфиденциальность, целостность и взаимную аутентификацию в рамках одного рукопожатия.

Для любого администратора, управляющего VPS или выделенным сервером, SSH — это не опциональная инфраструктура, а основная плоскость управления. Каждое конфигурационное решение, принятое вами в отношении SSH, напрямую влияет на поверхность атаки вашего сервера, операционную надёжность и соответствие требованиям.

Как работает SSH: архитектура протокола

Понимание SSH на уровне протокола — это то, что отличает администраторов, которые настраивают его правильно, от тех, кто оставляет уязвимые места.

Трёхуровневая модель

SSH определяется RFC 4251–4254 и работает на трёх отдельных подуровнях, расположенных поверх TCP:

• Протокол транспортного уровня SSH — обрабатывает аутентификацию сервера, обмен ключами, согласование шифрования и настройку MAC (кода аутентификации сообщений). Именно здесь происходит криптографическое рукопожатие.
• Протокол аутентификации пользователя SSH — работает поверх транспортного уровня и обрабатывает аутентификацию клиента на сервере с использованием таких методов, как publickey, password, keyboard-interactive или gssapi-with-mic.
• Протокол соединения SSH — мультиплексирует зашифрованный туннель в логические каналы, каждый из которых несёт сеанс оболочки, подсистему SFTP, перенаправленный порт или соединение агента.

Рукопожатие в деталях

Когда вы выполняете ssh user@host, следующая последовательность выполняется до того, как вы увидите приглашение командной строки:

1. TCP-соединение устанавливается с сервером на настроенном порту.
2. Обмен версиями — клиент и сервер обмениваются строками версии протокола (SSH-2.0-OpenSSH_9.x).
3. Согласование алгоритмов (SSH_MSG_KEXINIT) — обе стороны объявляют поддерживаемые алгоритмы обмена ключами, типы ключей хоста, шифры, MAC и методы сжатия. Первый взаимно поддерживаемый вариант в каждом списке побеждает.
4. Обмен ключами (KEX) — как правило, Diffie-Hellman или Elliptic Curve Diffie-Hellman (ECDH). Обе стороны получают общий секрет без его передачи. В результате создаются сеансовые ключи.
5. Проверка ключа хоста сервера — сервер подписывает значение своим закрытым ключом хоста. Клиент проверяет эту подпись по своему файлу ~/.ssh/known_hosts. Несоответствие вызывает предупреждение и по умолчанию блокирует соединение.
6. Шифрование активировано — весь последующий трафик шифруется и защищается от изменений с использованием согласованного шифра (например, chacha20-poly1305) и MAC.
7. Аутентификация пользователя — клиент пытается пройти аутентификацию с использованием согласованного метода. При аутентификации publickey клиент подписывает запрос своим закрытым ключом; сервер выполняет проверку с использованием сохранённого открытого ключа.
8. Открытие канала — открывается канал оболочки, подсистемы SFTP или выполнения команды, и сеанс начинается.

Весь этот процесс обычно завершается менее чем за 100 миллисекунд в локальной сети.

Симметричная и асимметричная криптография в SSH

Распространённое заблуждение состоит в том, что SSH «использует шифрование с открытым ключом» для всего трафика. Это не так. Роли разграничены:

SSH и устаревшие протоколы удалённого доступа

Генерация пар ключей SSH

Пары ключей SSH являются основой безопасного и масштабируемого доступа к серверу. Аутентификация по паролю уязвима для атак методом перебора и подстановки учётных данных; аутентификация на основе ключей — нет.

Выбор правильного алгоритма ключа

Ed25519 является текущей лучшей практикой. Он использует криптографию на эллиптических кривых Curve25519, создаёт компактные 256-битные ключи, работает быстрее RSA при эквивалентном уровне безопасности и поддерживается OpenSSH 6.5+ (выпущен в 2014 году).

ssh-keygen -t ed25519 -C "admin@yourhost.example.com"

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

ssh-keygen -t rsa -b 4096 -C "admin@yourhost.example.com"

Не используйте DSA (ограничен 1024 битами, взломан) или ECDSA с кривыми NIST (опасения по поводу происхождения параметров кривых NIST). Ed25519 — однозначный выбор для новых развёртываний.

Пошаговое руководство по генерации ключей

ssh-keygen -t ed25519 -C "ops-team-key-2025"

Вам будет предложено указать:

• Расположение файла — по умолчанию ~/.ssh/id_ed25519. Примите значение по умолчанию или укажите пользовательский путь для сред с несколькими ключами.
• Парольная фраза — всегда устанавливайте её. Парольная фраза шифрует закрытый ключ в состоянии покоя с использованием AES-256-CBC (или bcrypt в более новых версиях OpenSSH). Если файл вашего закрытого ключа будет похищен, парольная фраза станет последней линией защиты.

В результате создаются два файла:

~/.ssh/id_ed25519 — закрытый ключ. Никогда не передавайте его. Права доступа должны быть 600.
~/.ssh/id_ed25519.pub — открытый ключ. Именно его вы распространяете на серверы.

Управление несколькими ключами с помощью ~/.ssh/config
При управлении несколькими серверами или учётными записями используйте файл конфигурации SSH, чтобы не указывать флаги при каждом подключении:
# ~/.ssh/config

Host prod-web
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519_prod
    Port 2222

Host staging
    HostName 203.0.113.20
    User ubuntu
    IdentityFile ~/.ssh/id_ed25519_staging
После этого ssh prod-web автоматически разворачивается в полные параметры подключения.
Развёртывание открытого ключа на сервере
Метод 1: ssh-copy-id (рекомендуется для первоначальной настройки)
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your_server_ip
Это добавляет открытый ключ в ~/.ssh/authorized_keys на удалённом хосте и автоматически устанавливает правильные права доступа.
Метод 2: Ручное развёртывание (когда ssh-copy-id недоступен)
cat ~/.ssh/id_ed25519.pub | ssh user@your_server_ip 
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && 
   cat >> ~/.ssh/authorized_keys && 
   chmod 600 ~/.ssh/authorized_keys"
Метод 3: Консоль или API облачного провайдера
Большинство облачных провайдеров и панелей управления хостингом позволяют вставлять открытые ключи во время подготовки экземпляра. Это правильный подход для автоматизированной инфраструктуры — ключ присутствует до загрузки экземпляра, что устраняет проблему курицы и яйца, когда для развёртывания ключей SSH требуется сам SSH.
Формат файла authorized_keys
Каждая строка в ~/.ssh/authorized_keys — это один открытый ключ, опционально предваряемый параметрами:
restrict,command="/usr/local/bin/backup.sh" ssh-ed25519 AAAA... backup-key
from="192.168.1.0/24" ssh-ed25519 AAAA... ops-key
Параметр restrict отключает перенаправление портов, перенаправление агента и выделение PTY для этого ключа — полезно для ключей развёртывания или учётных записей автоматизации резервного копирования, которым не должен быть предоставлен интерактивный доступ к оболочке.
Защита SSH-сервера: /etc/ssh/sshd_config
Установка OpenSSH по умолчанию функциональна, но не защищена. Следующая конфигурация представляет собой базовый уровень производственного класса. Внесите изменения в /etc/ssh/sshd_config, затем проверьте и перезагрузите:
sshd -t && systemctl reload sshd
Всегда выполняйте sshd -t перед перезагрузкой — синтаксическая ошибка в sshd_config не приведёт к сбою работающего демона, но не позволит ему перезапуститься после перезагрузки, лишив вас доступа.
Рекомендуемый блок защиты sshd_config
# /etc/ssh/sshd_config - Production hardening baseline

Port 2222
AddressFamily inet
ListenAddress 0.0.0.0

# Host keys - prefer Ed25519
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

# Cryptographic hardening
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# Authentication
PermitRootLogin no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes

# Session hardening
LoginGraceTime 30
MaxAuthTries 3
MaxSessions 5
ClientAliveInterval 300
ClientAliveCountMax 2
TCPKeepAlive no

# Disable unused features
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no
GatewayPorts no

# Restrict access
AllowUsers deploy ops-user
Banner /etc/ssh/banner.txt
Пояснения к критически важным решениям по защите
PermitRootLogin no — Вход от имени root через SSH является высокоценной целью. Используйте обычного пользователя и повышайте привилегии с помощью sudo. Если вам абсолютно необходим доступ с правами root через определённый ключ (например, для автоматизации), используйте PermitRootLogin prohibit-password, чтобы разрешить вход от имени root только по ключу, блокируя попытки входа по паролю.
AllowTcpForwarding no — Если ваш сервер не является бастионным хостом или хостом перехода, отключите перенаправление TCP. В противном случае злоумышленник с действительным сеансом SSH мог бы использовать ваш сервер в качестве прокси для доступа к ресурсам внутренней сети.
TCPKeepAlive no с ClientAliveInterval — TCPKeepAlive работает на уровне TCP и виден сетевым посредникам. ClientAliveInterval отправляет сообщения проверки активности через зашифрованный канал SSH, что является более надёжным и конфиденциальным.
LoginGraceTime 30 — Сокращает временной интервал, в течение которого неаутентифицированное соединение занимает слот сервера. Значение по умолчанию в 120 секунд является избыточным.
AllowUsers — Добавьте в белый список только те учётные записи, которым действительно необходим доступ по SSH. Это жёсткий барьер, который срабатывает до любой попытки аутентификации.
Изменение порта SSH по умолчанию
Перенос SSH с порта 22 не улучшает безопасность против целенаправленного злоумышленника — любое сканирование портов его обнаружит. Однако это позволяет устранить огромный объём автоматизированных оппортунистических атак методом перебора, которые исключительно атакуют порт 22. Это существенно снижает шум в журналах и нагрузку на сервер.
# In /etc/ssh/sshd_config
Port 2222
Перед перезагрузкой откройте новый порт в межсетевом экране:
# UFW
ufw allow 2222/tcp
ufw delete allow 22/tcp

# firewalld
firewall-cmd --permanent --add-port=2222/tcp
firewall-cmd --permanent --remove-service=ssh
firewall-cmd --reload

# iptables
iptables -A INPUT -p tcp --dport 2222 -j ACCEPT
iptables -D INPUT -p tcp --dport 22 -j ACCEPT
Если на вашем сервере работает SELinux, вам также необходимо обновить контекст порта SELinux:
semanage port -a -t ssh_port_t -p tcp 2222
Подключение к серверу
Базовое подключение
ssh user@your_server_ip
Подключение к нестандартному порту
ssh -p 2222 user@your_server_ip
Подключение с указанием конкретного ключа
ssh -i ~/.ssh/id_ed25519_prod user@your_server_ip
Подробный режим для отладки
ssh -vvv user@your_server_ip
Флаг -vvv выводит каждый шаг рукопожатия, попытки аутентификации и согласования канала. Это первый инструмент, к которому следует обратиться при неожиданном сбое подключения.
Безопасная передача файлов через SSH
SCP (Secure Copy Protocol)
SCP — это простой неинтерактивный инструмент копирования файлов. Он быстрый и широко доступный, но не поддерживает возобновление передачи и имеет ограниченную обработку ошибок.
Копирование локального файла на удалённый сервер:
scp -P 2222 /local/path/file.tar.gz user@your_server_ip:/remote/path/
Копирование удалённого файла на локальный компьютер:
scp -P 2222 user@your_server_ip:/remote/path/file.tar.gz /local/path/
Рекурсивное копирование каталога:
scp -rp -P 2222 /local/directory/ user@your_server_ip:/remote/directory/
Примечание: Проект OpenSSH объявил устаревшим устаревший протокол SCP в OpenSSH 9.0. Современный scp теперь по умолчанию использует протокол SFTP под капотом. Интерфейс команд остаётся прежним, но базовый транспорт более надёжен.
SFTP (SSH File Transfer Protocol)
SFTP — это полнофункциональная подсистема передачи файлов с поддержкой просмотра каталогов, управления правами доступа и возобновления передачи. Это правильный выбор для интерактивного управления файлами.
sftp -P 2222 user@your_server_ip
Распространённые команды SFTP в интерактивном сеансе:
sftp> ls -la                          # List remote directory
sftp> lls                             # List local directory
sftp> put localfile.txt /remote/path/ # Upload file
sftp> get /remote/file.txt ./         # Download file
sftp> mput *.log /remote/logs/        # Upload multiple files
sftp> mkdir /remote/newdir            # Create remote directory
sftp> chmod 640 /remote/file.txt      # Change remote permissions
sftp> bye                             # Exit
rsync через SSH (рекомендация для производственной среды)
Для синхронизации каталогов, инкрементного резервного копирования или больших наборов данных rsync через SSH значительно эффективнее, чем SCP или SFTP. Он передаёт только изменённые блоки, а не целые файлы.
rsync -avz --progress -e "ssh -p 2222 -i ~/.ssh/id_ed25519" 
  /local/data/ user@your_server_ip:/remote/data/
Флаг -z включает сжатие при передаче. Для уже сжатых данных (архивов, образов) опустите его — сжатие сжатых данных расходует ресурсы CPU без уменьшения размера передачи.
Перенаправление портов SSH и туннелирование
Перенаправление портов — одна из наиболее мощных и недооценённых возможностей SSH. Оно позволяет безопасно получать доступ к сервисам, которые не открыты напрямую в интернет.
Локальное перенаправление портов
Перенаправление локального порта на удалённый сервис. Пример: доступ к удалённому экземпляру MySQL (порт 3306), привязанному к localhost на сервере:
ssh -L 3307:127.0.0.1:3306 user@your_server_ip -N
Теперь mysql -h 127.0.0.1 -P 3307 на вашем локальном компьютере подключается через зашифрованный туннель к удалённому MySQL.
Удалённое перенаправление портов
Открытие локального сервиса для удалённого сервера. Полезно для тестирования вебхуков или совместного использования локального сервера разработки:
ssh -R 8080:127.0.0.1:3000 user@your_server_ip -N
Динамическое перенаправление портов (SOCKS-прокси)
Превращение SSH-соединения в SOCKS5-прокси с маршрутизацией произвольного TCP-трафика через сервер:
ssh -D 1080 user@your_server_ip -N
Настройте ваш браузер или приложение на использование SOCKS5 127.0.0.1:1080.
SSH-агент и перенаправление агента
ssh-agent хранит расшифрованные закрытые ключи в памяти, чтобы вам не приходилось повторно вводить парольную фразу при каждом подключении.
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
Перенаправление агента (ssh -A) позволяет удалённому серверу использовать ваш локальный агент для аутентификации на третьем сервере. Это полезно для архитектур с бастионными хостами, но несёт риски: пользователь root на промежуточном сервере может использовать сокет вашего перенаправленного агента. Вместо этого предпочтительнее использовать ProxyJump:
ssh -J bastion.example.com user@internal-server.example.com
ProxyJump маршрутизирует TCP-соединение через бастионный хост, не открывая ему доступ к вашему агенту.
Устранение распространённых проблем SSH
Отказ в соединении (ssh: connect to host ... port 22: Connection refused)
Систематическая диагностика:

Убедитесь, что демон SSH запущен: systemctl status sshd

• Подтвердите порт прослушивания: ss -tlnp | grep sshd
• Проверьте правила межсетевого экрана: ufw status или iptables -L -n | grep 22
• Убедитесь, что сервер доступен на сетевом уровне: ping your_server_ip
• При использовании облачного провайдера проверьте правила группы безопасности или сетевого ACL в консоли провайдера.

Отказ в доступе (publickey)

Это наиболее распространённая ошибка SSH. Пройдите по этому контрольному списку:

# On the server, check authorized_keys permissions
ls -la ~/.ssh/
stat ~/.ssh/authorized_keys

# Fix permissions if wrong
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

# Verify the public key is actually present
cat ~/.ssh/authorized_keys

# Check sshd logs for the specific rejection reason
journalctl -u sshd -n 50 --no-pager
# or
tail -50 /var/log/auth.log

Распространённые причины, помимо прав доступа:

• Файл authorized_keys содержит неправильный ключ (например, вы скопировали закрытый ключ вместо файла .pub).

StrictModes yes в sshd_config (по умолчанию) отклоняет соединения, если права доступа к домашнему каталогу слишком открыты — максимально допустимое значение chmod 755 ~.
AllowUsers или AllowGroups в sshd_config исключает подключающегося пользователя.
SELinux блокирует доступ к ~/.ssh/ — проверьте ausearch -m avc -ts recent.

Тайм-аут SSH-соединения
# In /etc/ssh/sshd_config (server side)
ClientAliveInterval 60
ClientAliveCountMax 3

# In ~/.ssh/config (client side)
Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3
ClientAliveInterval отправляет нулевой пакет через зашифрованный канал каждые 60 секунд. После ClientAliveCountMax последовательных пропущенных ответов сервер завершает соединение. Это предотвращает накопление зависших сеансов.
Ошибка проверки ключа хоста
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
Это предупреждение означает, что ключ хоста сервера больше не соответствует тому, что хранится в ~/.ssh/known_hosts. Законные причины включают переустановку сервера или переназначение IP-адреса. Злоумышленные причины включают атаку «человек посередине». Проведите расследование перед тем, как продолжить.
Если вы подтвердили, что сервер был законно переустановлен:
ssh-keygen -R your_server_ip
Затем повторно подключитесь и проверьте отпечаток нового ключа хоста по консоли сервера или панели управления провайдера, прежде чем принять его.
Многофакторная аутентификация для SSH
Аутентификация на основе ключей надёжна, но добавление второго фактора TOTP (одноразового пароля на основе времени) создаёт эшелонированную защиту. Даже если закрытый ключ и его парольная фраза скомпрометированы, злоумышленник не сможет пройти аутентификацию без токена TOTP.
Установите и настройте libpam-google-authenticator на сервере:
apt install libpam-google-authenticator
google-authenticator
Затем настройте PAM и sshd_config:
# /etc/pam.d/sshd - add this line
auth required pam_google_authenticator.so

# /etc/ssh/sshd_config
UsePAM yes
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive
При использовании AuthenticationMethods publickey,keyboard-interactive пользователь должен предоставить действительный ключ И код TOTP. Это правильная производственная конфигурация для высокоценных серверов.
Центр сертификации SSH: масштабирование управления ключами
В средах с десятками серверов и несколькими администраторами управление отдельными записями authorized_keys становится операционно неустойчивым. Сертификаты SSH решают эту проблему.
Центр сертификации SSH (CA) подписывает ключи пользователей и хостов. Серверы доверяют открытому ключу CA, а не отдельным ключам пользователей. Добавление нового администратора требует только подписания его открытого ключа — без изменений в файле authorized_keys на каком-либо сервере.
# Create a CA key pair (store the private key offline or in a secrets manager)
ssh-keygen -t ed25519 -f /etc/ssh/ca_key -C "infrastructure-ca-2025"

# Sign a user's public key, valid for 7 days, for specific principals
ssh-keygen -s /etc/ssh/ca_key 
  -I "alice-ops-cert" 
  -n alice,deploy 
  -V +7d 
  ~/.ssh/id_ed25519.pub
На каждом сервере настройте доверие к CA:
# /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/ca_key.pub
Именно так крупномасштабная инфраструктура (включая облачных провайдеров и предприятия) управляет доступом по SSH без управления ключами на каждом сервере.
Практическая матрица решений: конфигурация SSH по сценарию использования



Сценарий использования
Тип ключа
Порт
Аутентификация по паролю
Вход от имени root
Перенаправление
MFA








—
—
—
—
—
—
—








Личный VPS
Ed25519
2222+
Отключена
Запрещён
Отключено
Опционально








Производственный веб-сервер
Ed25519
Нестандартный
Отключена
Нет
Отключено
Обязательно








Бастионный хост / хост перехода
Ed25519
22 или пользовательский
Отключена
Нет
Контролируемое
Обязательно








Автоматизация CI/CD
Ed25519 (ключ развёртывания)
Нестандартный
Отключена
Нет
Отключено
Нет (только ключ)








Сервер базы данных
Ed25519
Нестандартный
Отключена
Нет
Только локальное
Обязательно








Сервер разработки
Ed25519
Стандартный или пользовательский
Опционально
Нет
Опционально
Опционально





Настройка SSH на инфраструктуре AlexHost
При подготовке VPS или выделенного сервера через AlexHost доступ по SSH настраивается по умолчанию. Первоначальный пароль root доставляется по электронной почте при подготовке, и рекомендуемым первым действием является:

Войдите в систему от имени root, создайте непривилегированного административного пользователя и добавьте ваш открытый ключ в ~/.ssh/authorized_keys этого пользователя.
Примените базовый уровень защиты sshd_config, описанный выше.
Отключите аутентификацию по паролю и вход от имени root.
Настройте межсетевой экран для ограничения доступа по SSH известными диапазонами IP-адресов там, где это операционно целесообразно.

Если вы предпочитаете графический уровень управления наряду с SSH, варианты VPS с cPanel и панелей управления VPS от AlexHost предоставляют веб-интерфейс для выполнения распространённых задач, оставляя SSH доступным для полного административного контроля.
Для сред, где необходимо защитить веб-приложения, работающие на том же сервере, сочетание защиты SSH с правильно настроенным SSL-сертификатом охватывает как административный, так и прикладной транспортные уровни.
Контрольный список технических ключевых выводов
Прежде чем считать конфигурацию SSH готовой к производственному использованию, проверьте каждый из следующих пунктов:
Управление ключами

Закрытые ключи используют Ed25519 или RSA-4096 как минимум
Все закрытые ключи защищены надёжной парольной фразой
Каталог ~/.ssh/ имеет права доступа 700; authorized_keys имеет 600

• Ключи развёртывания используют параметры restrict и command= там, где это применимо
• График ротации ключей задокументирован и соблюдается

Конфигурация сервера

PasswordAuthentication no установлен и активен
PermitRootLogin no или prohibit-password применяется
SSH работает на нестандартном порту с обновлёнными правилами межсетевого экрана
AllowUsers или AllowGroups ограничивает доступ именованными учётными записями
LoginGraceTime установлен на 30 секунд или менее
sshd -t проходит без ошибок после каждого изменения конфигурации

Криптографическая защита

KexAlgorithms исключает diffie-hellman-group1-sha1 и diffie-hellman-group14-sha1

• Ciphers исключает 3des-cbc, arcfour и blowfish-cbc
• MACs использует только варианты -etm (encrypt-then-MAC)

Операционная безопасность

• Журналы аутентификации SSH отслеживаются (/var/log/auth.log или journalctl -u sshd)
• fail2ban или аналог настроен для блокировки повторных сбоев аутентификации
• Отпечатки ключей хостов записаны и хранятся вне основного канала для проверки
• MFA включён для всех интерактивных пользовательских сеансов на производственных системах
• SSH CA используется для сред с более чем пятью серверами или тремя администраторами

Часто задаваемые вопросы

В чём разница между ключами SSH и сертификатами SSH?

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

Почему появляется Permission denied (publickey) даже при правильном ключе?

Наиболее распространёнными причинами являются неправильные права доступа к файлу ~/.ssh/ (должны быть 700) или authorized_keys (должны быть 600), домашний каталог с правами на запись для всех (блокируется StrictModes) или директива AllowUsers в sshd_config, исключающая подключающуюся учётную запись. Проверьте journalctl -u sshd на сервере для получения конкретной причины отказа.

Является ли изменение порта SSH с 22 реальной мерой безопасности?

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

Можно ли использовать SSH без статического IP-адреса на стороне клиента?

Да. Аутентификация на основе ключей не требует фиксированного IP-адреса клиента. Если вы хотите ограничить доступ по IP, используйте параметр from= в authorized_keys или правила межсетевого экрана. Для динамических IP-адресов рассмотрите использование VPN для установления стабильной сетевой идентичности перед подключением, вместо того чтобы открывать SSH для всего интернета.

Каков наиболее безопасный способ восстановить доступ по SSH при блокировке?

Получите доступ к серверу через внеполосную консоль вашего хостинг-провайдера (VNC, IPMI или KVM over IP). Оттуда смонтируйте файловую систему, исправьте проблему с sshd_config или authorized_keys и перезапустите демон SSH. На планах VPS и выделенных серверов AlexHost консоль провайдера доступна через клиентский портал и не зависит от работоспособности SSH.