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, створіть адміністративного користувача без прав 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 використовується для середовищ з більш ніж п’ятьма серверами або трьома адміністраторами

FAQ

У чому різниця між ключами 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.