bolt Valebyte VPS from $4/mo — NVMe, 60s deploy.

Get a VPS arrow_forward

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

calendar_month October 01, 2024 schedule 7 хв. читання visibility 772 переглядів
person
Valebyte Team
Управління доступом до сервера через SSH
summarize

TL;DR

  • Перейдіть на SSH-ключі замість паролів, щоб виключити ризик брутфорс-атак і фішингу.
  • Відключіть віддалений вхід для root-користувача в конфігураційному файлі sshd.
  • Обов'язково захищайте приватний ключ парольною фразою (passphrase) для локальної безпеки.
  • Змініть стандартний порт SSH і використовуйте засоби моніторингу для захисту від сканерів.

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

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

Чому SSH — наш головний інструмент?

A secure digital lock with an SSH key icon in the keyhole, surrounded by server network lines and code, all within a shield emblem, representing secure server access.

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

  • Конфіденційність: Весь трафік між клієнтом і сервером шифрується, захищаючи дані від перехоплення.
  • Цілісність: SSH гарантує, що передані дані не були змінені в дорозі.
  • Автентифікація: Сервер перевіряє справжність клієнта, а клієнт може перевірити справжність сервера, запобігаючи атакам типу "людина посередині".
Однак, як і будь-який потужний інструмент, SSH вимагає грамотного налаштування. Без належної уваги до деталей, навіть найнадійніші механізми можуть стати вразливими.

Основа безпеки: SSH-ключі замість паролів

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

  • Приватний ключ (Private Key): Зберігається строго на вашому локальному комп'ютері і НІКОЛИ не покидає його. Він повинен бути захищений парольною фразою (passphrase).
  • Публічний ключ (Public Key): Розміщується на сервері, до якого ви хочете отримати доступ. Його можна вільно поширювати.
При підключенні клієнт використовує приватний ключ для створення криптографічного підпису, який сервер перевіряє за допомогою відповідного публічного ключа. Це набагато надійніше, ніж передача пароля по мережі.

Генерація SSH-ключів

Для створення пари ключів використовуйте команду ssh-keygen. Ми рекомендуємо використовувати алгоритм Ed25519 як більш сучасний і ефективний, але RSA з довжиною ключа 4096 біт також є хорошим вибором.


ssh-keygen -t ed25519 -C "ваша_почта@example.com"

В процесі генерації вам буде запропоновано зберегти ключ в певному файлі (за замовчуванням ~/.ssh/id_ed25519) і ввести парольну фразу. Обов'язково використовуйте надійну парольну фразу! Це додатковий рівень захисту вашого приватного ключа на випадок, якщо хтось отримає до нього доступ.

Після генерації у вас з'явиться два файли в директорії ~/.ssh/:

  • id_ed25519 (ваш приватний ключ)
  • id_ed25519.pub (ваш публічний ключ)

Розміщення публічного ключа на сервері

Найпростіший і безпечний спосіб додати ваш публічний ключ на сервер — це використовувати утиліту ssh-copy-id:


ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your_server_ip

Ця команда скопіює ваш публічний ключ на віддалений сервер в файл ~/.ssh/authorized_keys користувача user і автоматично встановить правильні права доступу. Якщо ssh-copy-id недоступна або ви віддаєте перевагу ручному методу, ось як це зробити:

  1. Скопіюйте вміст вашого публічного ключа:
    
    cat ~/.ssh/id_ed25519.pub
            
  2. Підключіться до серверу по SSH (якщо це перше підключення, можливо, доведеться використовувати пароль).
  3. Створіть директорію .ssh, якщо її немає, і встановіть правильні права:
    
    mkdir -p ~/.ssh
    chmod 700 ~/.ssh
            
  4. Додайте ваш публічний ключ в файл authorized_keys:
    
    echo "СОДЕРЖИМОЕ_ВАШЕГО_ПУБЛИЧНОГО_КЛЮЧА" >> ~/.ssh/authorized_keys
    chmod 600 ~/.ssh/authorized_keys
            

    Важливо: Замініть "СОДЕРЖИМОЕ_ВАШЕГО_ПУБЛИЧНОГО_КЛЮЧА" на вивід команди cat ~/.ssh/id_ed25519.pub. Переконайтеся, що права доступу для ~/.ssh встановлені в 700, а для ~/.ssh/authorized_keys — в 600. Неправильні права доступу можуть перешкодити автентифікації.

Управління кількома SSH-ключами і хостами через ~/.ssh/config

Для системних адміністраторів, що працюють з десятками, а то і сотнями серверів, ручне вказання ключів і користувачів для кожного підключення швидко стає стомлюючим. Тут на допомогу приходить файл конфігурації SSH-клієнта ~/.ssh/config.

Приклад файлу ~/.ssh/config:


Host valeserver-dev
    HostName 192.168.1.100
    User devuser
    IdentityFile ~/.ssh/id_ed25519_dev
    Port 2222
    # StrictHostKeyChecking no # Не рекомендуется для продакшена!

Host valeserver-prod
    HostName prod.valebyte.com
    User admin
    IdentityFile ~/.ssh/id_rsa_prod
    ForwardAgent yes # Подробнее об этом ниже

Host *
    User defaultuser
    Port 22
    ServerAliveInterval 60
    AddKeysToAgent yes
    IdentitiesOnly yes

Тепер ви можете просто набрати ssh valeserver-dev або ssh valeserver-prod, і SSH-клієнт автоматично підставить всі необхідні параметри. Директива Host * застосовує налаштування за замовчуванням для всіх хостів, якщо вони не переопределені більш специфічними правилами.

Потрібен надійний сервер для безпечного SSH?

Захистіть свій SSH-доступ за допомогою наших надійних VPS. Отримайте повний контроль над дозволами користувачів. — from €4.49/mo.

Вибрати VPS-план →
rocket_launch Quick pick

Looking for a server that just works?

Valebyte VPS — NVMe, 24/7 support, deploy in 60 seconds.

View VPS plans arrow_forward

Посилюємо налаштування SSH-сервера (sshd_config)

Після того, як ви успішно налаштували доступ по ключам, прийшов час затягнути гайки на стороні сервера. Основний конфігураційний файл SSH-демона — це /etc/ssh/sshd_config. Завжди робіть резервну копію цього файлу перед внесенням змін!

Вимкнення доступу за паролем

Це, мабуть, найважливіший крок для підвищення безпеки. Вимкніть парольну автентифікацію повністю:


# /etc/ssh/sshd_config
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no # Вимкніть, якщо не використовуєте PAM для автентифікації

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

Забороняємо вхід для root-користувача

Прямий вхід під root — це величезна діра в безпеці. Якщо зловмисник підбере пароль або ключ для root, він отримає повний контроль над сервером. Завжди входьте під звичайним користувачем, а потім використовуйте sudo для виконання адміністративних завдань.


# /etc/ssh/sshd_config
PermitRootLogin no

Якщо вам дійсно потрібно дозволити root-доступ за ключами, можна використовувати PermitRootLogin prohibit-password. Але ми наполегливо рекомендуємо PermitRootLogin no.

Змінюємо стандартний порт SSH

Стандартний порт SSH (22) є ціллю постійних сканувань та атак. Зміна його на нестандартний порт (наприклад, 2222, 22222 або будь-який інший вільний порт >1024) — це не панацея, але значно знижує обсяг "шуму" в логах і відсікає автоматизовані боти, які сканують тільки стандартні порти.


# /etc/ssh/sshd_config
Port 2222

Не забудьте оновити правила файрвола (ufw, firewalld, iptables), щоб дозволити вхідні з'єднання на новому порту, і перезапустити sshd. І, звичайно, оновіть ваш ~/.ssh/config!

Обмежуємо доступ за користувачами та групами

Якщо на сервері працює кілька користувачів, ви можете явно вказати, кому дозволено SSH-доступ.


# /etc/ssh/sshd_config
AllowUsers user1 user2
AllowGroups sysadmins

Використовуйте AllowUsers для перерахування конкретних користувачів або AllowGroups для груп. Також існують директиви DenyUsers та DenyGroups. Будьте уважні: при використанні AllowUsers або AllowGroups всі, хто не перерахований, автоматично позбавляються доступу.

Перезапуск служби SSH

Після будь-яких змін в /etc/ssh/sshd_config завжди необхідно перезапустити службу SSH, щоб нові налаштування вступили в силу:


sudo systemctl reload sshd # Или restart

Важлива порада: Перш ніж закрити поточну SSH-сесію після зміни sshd_config, відкрийте нову сесію в іншому терміналі і переконайтеся, що ви можете підключитися з новими налаштуваннями. Якщо щось піде не так, у вас залишиться активна сесія для відкату змін. Це врятує вас від блокування доступу до власного сервера!

Зручність та безпека: SSH-агент

Введення парольної фрази для кожного ключа при кожному підключенні може бути виснажливим. SSH-агент (ssh-agent) вирішує цю проблему. Він запускається як фоновий процес, зберігає розшифровані приватні ключі в пам'яті і надає їх SSH-клієнту за запитом, позбавляючи вас від багаторазового введення парольної фрази.

Як це працює:

  1. Запустіть ssh-agent (зазвичай він запускається автоматично при старті графічної середовища або через команди на зразок eval "$(ssh-agent -s)").
  2. Додайте ваші приватні ключі в агент:
    
    ssh-add ~/.ssh/id_ed25519
    ssh-add ~/.ssh/id_rsa_prod # Якщо у вас кілька ключів
            

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

  3. Тепер ви можете підключатися до серверів, не вводячи парольну фразу, поки агент активний.

Директива ForwardAgent yes в ~/.ssh/config дозволяє "перенаправляти" SSH-агент, щоб ви могли використовувати ключі з вашої локальної машини для аутентифікації з сервера на інший сервер (SSH-стрибки), не копіюючи приватні ключі на проміжний сервер. Це дуже зручно і безпечно.

Додаткові заходи безпеки

  • Fail2Ban: Встановіть і налаштуйте Fail2Ban. Ця утиліта автоматично банить IP-адреси, з яких відбуваються численні невдалі спроби входу по SSH, ефективно захищаючи від брутфорс-атак.
  • Моніторинг логів: Регулярно переглядайте логи SSH-доступу (/var/log/auth.log або /var/log/secure) на предмет підозрілої активності.
  • Оновлення: Завжди тримайте SSH-сервер і клієнт в актуальному стані, встановлюючи оновлення безпеки.
  • Багатофакторна аутентифікація (MFA/2FA): Для максимального захисту розгляньте можливість інтеграції MFA з SSH, наприклад, через PAM-модулі і Google Authenticator. Це додасть ще один шар безпеки поверх ключів.
rocket_launch Quick pick

Looking for a server that just works?

Valebyte VPS — NVMe, 24/7 support, deploy in 60 seconds.

View VPS plans arrow_forward

Висновки

Правильне управління доступом до сервера через SSH — це не просто рекомендація, а критично важливий елемент будь-якої серйозної стратегії кібербезпеки. Відмова від паролів на користь SSH-ключів, ретельне налаштування sshd_config з відключенням root-доступу і зміною стандартного порту, а також використання SSH-агента і додаткових інструментів на зразок Fail2Ban, дозволяють створити надійний і зручний контур безпеки.

Пам'ятайте, що безпека — це безперервний процес. Регулярно переглядайте свої налаштування, стежте за оновленнями і будьте пильні. Наші сервери — це наша відповідальність, і з Valebyte ви завжди можете розраховувати на інструменти і знання, які допоможуть вам тримати їх під надійним контролем. Удачі у вашій роботі, колеги!

Масштабуйте свою інфраструктуру з безпечним SSH-доступом

Наші хмарні інстанси пропонують гнучкість і продуктивність, необхідні для вашого безпечного середовища SSH. Почніть сьогодні.

Почати роботу з хмарою →
support_agent
Valebyte Support
Usually replies within minutes
Hi there!
Send us a message and we'll reply as soon as possible.