29.10.2024

Linux

Безпека

Віртуальні сервери

Як встановити та налаштувати SSH на Linux: Повний посібник з безпеки на 2025 рік

SSH є єдиною найбільш критичною точкою доступу на вашому сервері. Неправильно налаштований SSH може бути зламаний менш ніж за п’ять хвилин автоматизованими ботами, що сканують інтернет. Незалежно від того, чи керуєте ви середовищем VPS Hosting, фізичним сервером або хмарним екземпляром, правильне захищення SSH з першого дня є обов’язковим.

У цьому посібнику ви дізнаєтесь, як встановити OpenSSH, налаштувати його безпечно, реалізувати автентифікацію на основі ключів та застосувати техніки захисту виробничого рівня — все це на Linux-сервері у 2025 році.

Що таке SSH і чому це важливо?

SSH (Secure Shell) — це криптографічний мережевий протокол, який дозволяє користувачам безпечно підключатися до віддаленої системи через незахищену мережу, наприклад інтернет. Усі дані, що передаються між клієнтом і сервером, повністю зашифровані, що робить його галузевим стандартом для віддаленого управління серверами.

За замовчуванням SSH працює на порту 22 та підтримує:

Віддалений вхід на сервери та віртуальні машини
Безпечне передавання файлів через SCP та SFTP
Виконання віддалених команд та автоматизацію за допомогою скриптів
Перенаправлення портів та тунелювання для безпечної маршрутизації трафіку
Перенаправлення X11 для доступу до графічних застосунків

SSH — це ваш основний адміністративний інтерфейс. Ставтеся до нього відповідно.

Крок 1: Встановлення OpenSSH Server

Більшість сучасних дистрибутивів Linux постачаються з попередньо встановленим OpenSSH. Якщо його немає, встановіть його за допомогою відповідного менеджера пакетів для вашого дистрибутива.

Ubuntu / Debian

sudo apt update
sudo apt install openssh-server -y

CentOS / RHEL / AlmaLinux / Rocky Linux

sudo yum install openssh-server -y

Fedora

sudo dnf install openssh-server -y

Arch Linux

sudo pacman -S openssh

Після встановлення доступні як OpenSSH server (sshd), так і OpenSSH client, що дозволяє приймати вхідні з’єднання та підключатися до інших віддалених серверів.

Крок 2: Запуск та увімкнення служби SSH

Після встановлення вам потрібно запустити демон SSH (sshd) та налаштувати його для автоматичного запуску під час завантаження системи.

Запуск служби SSH

sudo systemctl start ssh

Увімкнення SSH для запуску під час завантаження

sudo systemctl enable ssh

Перевірка роботи служби

sudo systemctl status ssh

Коректний вивід покаже active (running) зеленим кольором. Якщо ви бачите помилки, перевірте системні журнали за допомогою journalctl -xe для отримання діагностичних деталей.

Крок 3: Розуміння файлу конфігурації SSH

Поведінка SSH визначається одним основним файлом конфігурації:

/etc/ssh/sshd_config

Цей файл контролює все — порт прослуховування, методи автентифікації, дозволених користувачів, обмеження входу тощо. Завжди створюйте резервну копію перед внесенням змін:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Відкрийте файл у вашому улюбленому текстовому редакторі:

sudo nano /etc/ssh/sshd_config

Після внесення будь-яких змін завжди перевіряйте синтаксис конфігурації перед перезапуском служби, щоб уникнути блокування власного доступу:

sudo sshd -t

Якщо помилок не виявлено, застосуйте зміни:

sudo systemctl restart ssh

Крок 4: Основні зміни конфігурації SSH

4.1 Зміна стандартного порту SSH

Порт 22 — це перший порт, на який націлені автоматизовані сканери та боти для брутфорсу. Зміна його на нестандартний порт значно зменшує шум у ваших журналах та знижує вразливість до опортуністичних атак.

Знайдіть цей рядок у sshd_config:

#Port 22

Розкоментуйте його та встановіть власний порт (виберіть число від 1024 до 65535, яке ще не використовується):

Port 2222

Збережіть файл, перевірте та перезапустіть SSH:

sudo sshd -t && sudo systemctl restart ssh

> Важливо: Негайно оновіть правила брандмауера після зміни порту (див. Крок 6). Невиконання цього заблокує вам доступ до сервера.

4.2 Вимкнення входу root через SSH

Дозвіл прямого входу root через SSH є однією з найпоширеніших і найнебезпечніших помилок конфігурації. Якщо зловмисник вгадає або підбере пароль root, він отримає повний, необмежений контроль над вашою системою.

Знайдіть цю директиву:

PermitRootLogin yes

Змініть її на:

PermitRootLogin no

Користувачі повинні входити за допомогою стандартного облікового запису та підвищувати привілеї за допомогою sudo за необхідності. Це створює важливий рівень аудиту — кожна привілейована дія реєструється під іменем конкретного облікового запису користувача.

4.3 Примусове використання автентифікації на основі ключів та вимкнення паролів

Автентифікація на основі паролів за своєю природою вразлива до атак брутфорсу. Пари ключів SSH — математично пов’язана комбінація публічного/приватного ключа — є незрівнянно безпечнішими.

Знайдіть та встановіть наступні директиви:

PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no

> Попередження: Вимикайте автентифікацію за паролем лише після того, як ви успішно протестували вхід на основі ключів. Вимкнення паролів без робочого ключа назавжди заблокує вам доступ.

4.4 Додаткові директиви захисту

Додайте або змініть ці налаштування у sshd_config для захищеної виробничої конфігурації:

# Restrict login to specific users (replace 'youruser' with actual usernames)
AllowUsers youruser

# Disconnect idle sessions after 5 minutes
ClientAliveInterval 300
ClientAliveCountMax 2

# Limit authentication attempts per connection
MaxAuthTries 3

# Disable empty passwords
PermitEmptyPasswords no

# Disable X11 forwarding if not needed
X11Forwarding no

# Use only modern, secure protocol version
Protocol 2

# Restrict SSH to specific network interface (optional, replace with your IP)
ListenAddress 0.0.0.0

Крок 5: Генерація та розгортання пар ключів SSH

Автентифікація за ключами SSH замінює паролі криптографічним підтвердженням особи. Ось як правильно це налаштувати.

Крок 5.1: Генерація пари ключів на вашому локальному комп’ютері

Виконайте цю команду на вашій локальній робочій станції (не на сервері):

ssh-keygen -t ed25519 -C "your_email@example.com"

> Чому Ed25519? Ed25519 — це сучасний алгоритм на основі еліптичних кривих, який є швидшим, більш безпечним і створює коротші ключі, ніж старіший алгоритм RSA. Це рекомендований вибір у 2025 році.

Якщо ваша система або інструменти вимагають RSA з міркувань сумісності, використовуйте 4096-бітний ключ:

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

Вам буде запропоновано:

Вибрати шлях до файлу (натисніть Enter, щоб прийняти стандартний ~/.ssh/id_ed25519)
Встановити необов’язкову парольну фразу (настійно рекомендується — вона шифрує ваш приватний ключ у стані спокою)

Це генерує два файли:

~/.ssh/id_ed25519 — Ваш приватний ключ. Ніколи не діліться ним. Ніколи не копіюйте його на сервер.
~/.ssh/id_ed25519.pub — Ваш публічний ключ. Саме він встановлюється на серверах.

Крок 5.2: Копіювання публічного ключа на сервер
Використовуйте ssh-copy-id для безпечного передавання вашого публічного ключа на віддалений сервер:
ssh-copy-id -p 2222 username@your_server_ip
Замініть username на ім’я вашого облікового запису на сервері, а your_server_ip — на фактичну IP-адресу.
Ця команда автоматично додає ваш публічний ключ до ~/.ssh/authorized_keys на сервері з правильними дозволами.
Ручний метод (якщо ssh-copy-id недоступний):
cat ~/.ssh/id_ed25519.pub | ssh username@your_server_ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"
Крок 5.3: Тестування входу на основі ключів
Перед вимкненням автентифікації за паролем переконайтеся, що вхід на основі ключів працює:
ssh -p 2222 username@your_server_ip
Якщо ви успішно підключилися без запиту пароля (або лише з запитом парольної фрази ключа), автентифікація на основі ключів працює правильно. Тепер ви можете безпечно вимкнути автентифікацію за паролем у sshd_config.
Крок 6: Налаштування брандмауера для SSH
Брандмауер — це ваша перша лінія захисту. Завжди налаштовуйте його так, щоб дозволяти лише той порт SSH, який ви використовуєте.
Використання UFW (Ubuntu / Debian)
# Allow your custom SSH port
sudo ufw allow 2222/tcp

# Enable the firewall
sudo ufw enable

# Verify the rules
sudo ufw status verbose
Використання firewalld (CentOS / RHEL / Fedora)
# Add the custom SSH port
sudo firewall-cmd --permanent --add-port=2222/tcp

# Remove the default port 22 (optional, after confirming new port works)
sudo firewall-cmd --permanent --remove-service=ssh

# Reload firewall rules
sudo firewall-cmd --reload
Обмеження доступу SSH за IP-адресою
Для максимальної безпеки обмежте доступ SSH лише відомими, довіреними IP-адресами:
# UFW example: allow SSH only from a specific IP
sudo ufw allow from 203.0.113.10 to any port 2222 proto tcp
Це особливо ефективно на Dedicated Servers, де ви контролюєте весь адміністративний доступ з фіксованого офісного або VPN IP-діапазону.
Крок 7: Розширені заходи безпеки
7.1 Встановлення та налаштування Fail2Ban
Fail2Ban відстежує файли журналів SSH та автоматично блокує IP-адреси, які демонструють ознаки активності брутфорсу.
# Install Fail2Ban
sudo apt install fail2ban -y   # Ubuntu/Debian
sudo yum install fail2ban -y   # CentOS/RHEL

# Create a local configuration file
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
Відредагуйте /etc/fail2ban/jail.local та налаштуйте пастку SSH:
[sshd]
enabled = true
port    = 2222
filter  = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime  = 3600
findtime = 600
Запустіть та увімкніть Fail2Ban:
sudo systemctl start fail2ban
sudo systemctl enable fail2ban
7.2 Використання файлу конфігурації SSH для управління на стороні клієнта
На вашому локальному комп’ютері створіть або відредагуйте ~/.ssh/config для спрощення підключень та застосування налаштувань безпеки:
Host myserver
    HostName your_server_ip
    User youruser
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    ServerAliveInterval 60
    ServerAliveCountMax 3
З цією конфігурацією ви можете підключитися, просто ввівши:
ssh myserver
7.3 Двофакторна автентифікація (2FA) для SSH
Для середовищ, що вимагають найвищого рівня безпеки доступу — таких як виробничі бази даних, фінансові системи або інфраструктура, що регулюється вимогами відповідності — розгляньте можливість додавання двофакторної автентифікації на основі TOTP за допомогою Google Authenticator або Authy разом із ключами SSH.
sudo apt install libpam-google-authenticator -y
google-authenticator
Потім налаштуйте PAM та sshd_config для вимоги як ключа, так і одноразового пароля. Це створює справжній потік багатофакторної автентифікації.
Крок 8: Тестування та усунення несправностей SSH
Після завершення налаштування систематично перевірте, що все працює належним чином.
Тест підключення
ssh -p 2222 -v username@your_server_ip
Прапорець -v вмикає детальний режим, виводячи докладну налагоджувальну інформацію про кожен етап підключення — безцінно для діагностики збоїв автентифікації.
Поширені проблеми та рішення




Проблема
Ймовірна причина
Рішення




Connection refused
SSH не запущено або неправильний порт
Перевірте systemctl status ssh та правила брандмауера


Permission denied (publickey)
Ключ відсутній у authorized_keys або неправильні дозволи
Перевірте наявність ~/.ssh/authorized_keys за допомогою chmod 600


Host key verification failed
Змінився відбиток сервера
Видаліть старий запис з ~/.ssh/known_hosts


Connection timed out
Брандмауер блокує порт
Перевірте правила UFW/firewalld та групи безпеки хмари


Блокування після зміни конфігурації
Неправильна конфігурація у sshd_config
Використовуйте консольний/KVM доступ для відкату змін




Діагностичні команди
# Check SSH service status
sudo systemctl status ssh

# View real-time SSH logs
sudo journalctl -u ssh -f

# Check which port SSH is listening on
sudo ss -tlnp | grep sshd

# Test configuration file syntax
sudo sshd -t
Повний довідник захищеного sshd_config
Ось готовий до використання у виробництві sshd_config, що включає всі рекомендації з безпеки з цього посібника:
# Network
Port 2222
ListenAddress 0.0.0.0
Protocol 2

# Authentication
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
MaxAuthTries 3
LoginGraceTime 30

# Session Management
ClientAliveInterval 300
ClientAliveCountMax 2
MaxSessions 5

# Access Control
AllowUsers youruser

# Features (disable what you don't need)
X11Forwarding no
AllowTcpForwarding no
GatewayPorts no
PermitUserEnvironment no

# Logging
SyslogFacility AUTH
LogLevel VERBOSE
Чому ваша хостингова інфраструктура важлива для безпеки SSH
Безпека вашої конфігурації SSH не існує ізольовано — вона значною мірою залежить від базової інфраструктури. Правильно захищена конфігурація SSH є найбільш ефективною при розгортанні на сервері, який вже забезпечує:

DDoS захист для поглинання об’ємних атак до того, як вони досягнуть вашого порту SSH
NVMe сховище для швидкого запису журналів та швидкого часу реакції Fail2Ban
Мережеві порти 1 Gbps для забезпечення стабільності з’єднання під навантаженням
KVM/консольний доступ як позасмуговий метод відновлення, якщо ви випадково заблокували собі доступ

Плани VPS Hosting від AlexHost включають все вищезазначене, з повним root-доступом та підтримкою власних конфігурацій брандмауера — що робить їх ідеальними для розгортання захищеної конфігурації SSH, описаної в цьому посібнику.
Якщо вам потрібна панель управління для керування сервером разом із SSH, ознайомтеся з VPS Control Panels для варіантів, включаючи cPanel, Plesk та DirectAdmin. Для команд, що керують кількома веб-ресурсами, Shared Web Hosting надає кероване середовище, де захист SSH здійснюється на рівні інфраструктури.
А якщо ви запускаєте веб-сервіси із захистом SSL поряд із вашим SSH-захищеним сервером, поєднання вашого налаштування з надійним рішенням SSL Certificates забезпечує наскрізне шифрування для всіх ваших публічних сервісів.
Контрольний список безпеки SSH
Використовуйте цей контрольний список перед тим, як вважати вашу конфігурацію SSH готовою до виробництва:

[ ] OpenSSH server встановлено та запущено
[ ] Стандартний порт 22 змінено на власний порт
[ ] Вхід root вимкнено (PermitRootLogin no)
[ ] Згенеровано пару ключів Ed25519 або RSA-4096
[ ] Публічний ключ розгорнуто у authorized_keys на сервері
[ ] Вхід на основі ключів успішно протестовано
[ ] Автентифікацію за паролем вимкнено
[ ] Брандмауер налаштовано для дозволу лише нового порту SSH
[ ] Fail2Ban встановлено та налаштовано
[ ] MaxAuthTries встановлено на 3 або менше
[ ] ClientAliveInterval налаштовано для завершення неактивних сесій
[ ] Синтаксис sshd_config перевірено за допомогою sudo sshd -t

[ ] Підтверджено позасмуговий консольний доступ (KVM/VNC)

Висновок

Правильне встановлення та налаштування SSH є однією з найфундаментальніших навичок в адмініструванні Linux-систем. Стандартна установка SSH є вразливістю; захищена конфігурація SSH є перевагою. Дотримуючись цього посібника, ви:

Встановили та запустили OpenSSH server
Змінили стандартний порт та вимкнули вхід root
Реалізували криптографічно стійку автентифікацію на основі ключів
Налаштували правила брандмауера для обмеження доступу
Розгорнули Fail2Ban для блокування спроб брутфорсу
Встановили повну методологію усунення несправностей

SSH, при правильному налаштуванні, стає потужним, надійним та безпечним шлюзом для віддаленого управління, конвеєрів автоматизації та зашифрованого зв’язку між системами. У поєднанні з надійною хостинговою інфраструктурою — такою як Dedicated Servers від AlexHost із DDoS-захистом на апаратному рівні — ви маєте фундамент, який справді важко зламати.

Periodically revisit your SSH configuration. Rotate your keys annually. Monitor your logs. Security is not a one-time task — it’s an ongoing practice.

Збережіть 15% на всі хостинг-послуги