Блог компанії 3v-Hosting
Налаштування доступу до сервера за SSH ключем
6 хв.
У сучасній цифровій інфраструктурі безпечний і автоматизований доступ до сервера необхідний системним адміністраторам, розробникам та інженерам DevOps. Аутентифікація на основі ключів SSH є найпоширенішим і найнадійнішим способом. SSH-ключі підвищують безпеку, усуваючи необхідність входу за паролем, і дають змогу спростити автоматизацію, особливо під час керування кількома серверами або інтеграції конвеєрів CI/CD. У цій статті ми детально розглянемо налаштування доступу до сервера за допомогою ключів SSH і розглянемо його з практичної та адміністративної точок зору.
Що таке SSH та аутентифікації на основі ключів
SSH, або Secure Shell, - це протокол, що забезпечує безпечний віддалений вхід у систему і виконання команд на віддаленому сервері. За замовчуванням SSH використовує аутентифікацію за паролем, але цей метод схильний до атак перебору і витоку облікових даних. Аутентифікація на основі ключів SSH - очевидний вибір: безпечніший і зручніший.
Ключі SSH складаються з пар: закритого ключа, який залишається на клієнтській машині і має бути захищений, і відкритого ключа, який розміщується на сервері в спеціальному файлі. Коли клієнт намагається підключитися до сервера, сервер перевіряє, чи існує відповідний відкритий ключ, і перевіряє клієнта за закритим ключем. Якщо все збігається, доступ надається.
Управління відкритими ключами простіше і безпечніше, ніж робота з декількома користувацькими паролями, особливо під час автоматизації управління доступом у розподіленій інфраструктурі.
Генерація ключів SSH
Перш ніж налаштовувати сервер для доступу за ключем SSH, необхідно згенерувати пару ключів. Зазвичай це робиться на клієнтській машині за допомогою інструменту ssh-keygen, який за замовчуванням доступний у всіх основних Unix-подібних системах.
ssh-keygen -t rsa -b 4096 -C «your_email@example.com»
Ця команда генерує 4096-бітну пару ключів RSA з необов'язковим коментарем для ідентифікації. Процес запитує розташування файлу та кодову фразу:
Розташування: За замовчуванням ключ зберігається в ~/.ssh/id_rsa (приватний) і ~/.ssh/id_rsa.pub (публічний).
Ключова фраза: Необов'язкова, але настійно рекомендується для додаткової безпеки. З її допомогою закритий ключ шифрується локально.
Крім RSA, можна використовувати інші алгоритми, наприклад ED25519 або ECDSA, для підвищення продуктивності або посилення криптографічних властивостей. Наприклад, ED25519 пропонує коротші ключі з надійним захистом і все частіше використовується для сучасних розгортань.
Копіювання відкритого ключа на сервер
Після того як пару ключів згенеровано, відкритий ключ необхідно скопіювати на цільовий сервер. Це можна зробити вручну або за допомогою засобів автоматизації. Найпростіше це зробити за допомогою ssh-copy-id:
ssh-copy-id -i ~/.ssh/id_rsa.pub user@remote_host
Ця команда додає відкритий ключ у файл ~/.ssh/authorized_keys зазначеного користувача на сервері. Вона також забезпечує правильні права доступу до каталогу .ssh і файлу authorized_keys - обидва ці параметри важливі для успішної аутентифікації.
Як альтернативу можна скопіювати відкритий ключ вручну:
cat ~/.ssh/id_rsa.pub | ssh user@remote_host «mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys»
З точки зору безпеки дуже важливо, щоб каталог ~/.ssh мав права 700, а authorized_keys було встановлено на 600. В іншому випадку OpenSSH може відмовитися використовувати ключ для аутентифікації.
Вимкнення перевірки автентичності пароля (необов'язково, але рекомендується)
Після того як доступ за SSH-ключами запрацював, вважається гарною практикою повністю вимкнути аутентифікацію за паролем, тим самим мінімізувавши поверхню атаки на сервер. Це налаштовується в конфігураційному файлі демона SSH:
sudo nano /etc/ssh/sshd_config
Знайдіть або додайте такі рядки:
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
Після внесення змін перезапустіть службу SSH:
sudo systemctl restart sshd
Перед перезапуском служби SSH настійно рекомендується протестувати доступ на основі ключів в окремому терміналі, особливо під час роботи з віддаленими серверами, щоб уникнути блокування через неправильну конфігурацію.
Інші корисні статті в нашому Блозі:
- Передача файлів за допомогою SSH в Linux
- Короткий посібник з базового налаштування SSH на вашому сервері Debian
- Команда Linux scp і приклади її використання
- Як використовувати Rsync для синхронізації локальних і віддалених каталогів
Керування кількома ключами та користувачами
У середовищах, де кільком користувачам потрібен доступ до одного сервера або де системи автоматизації (наприклад, Ansible або CI/CD runners) вимагають окремого доступу, важливо ретельно керувати відкритими ключами.
Кожен відкритий ключ має бути унікально ідентифікованим і може бути доданий до файлу authorized_keys разом із коментарем:
ssh-rsa AAAAB3Nza... user1@laptop
ssh-ed25519 AAAAC3Nza... deploy-bot@ci
Для спрощення управління інструменти управління конфігурацією, як-от Ansible, Puppet або Chef, можуть автоматично розподіляти та керувати ключами SSH на кількох вузлах. Крім того, такі інструменти, як HashiCorp Vault або AWS Secrets Manager, забезпечують безпечне зберігання і ротацію ключів.
У середовищах зі спільним доступом доцільно підтримувати політику закінчення терміну дії ключів SSH і регулярного аудиту. Ключі, які більше не потрібні, слід видаляти з authorized_keys, щоб уникнути неактуального доступу.
Використання конфігурації SSH для спрощення доступу
У разі частого звернення до кількох серверів файл ~/.ssh/config на клієнтській машині допомагає спростити і керувати опціями SSH. Типовий запис може мати такий вигляд:
Host web-server
HostName 192.168.1.100
User ubuntu
IdentityFile ~/.ssh/id_rsa
Це дає змогу підключатися за допомогою веб-сервера ssh замість того, щоб щоразу вказувати повні параметри. Крім того, ви можете вказати номери портів, хости, що стрибають, та інші корисні опції.
Наприклад, щоб підключитися через бастіонний хост (jump host):
Host internal-server
HostName 10.0.0.2
User dev
IdentityFile ~/.ssh/dev_key
ProxyJump bastion-host
Найкращі практики безпеки
Незважаючи на притаманну SSH-ключам безпеку, слід дотримуватися кількох найкращих практик:
- Використовуйте надійну парольну фразу для закритих ключів, особливо якщо вони зберігаються на ноутбуках або в загальних системах.
- Уникайте входу в систему з правами root: Дозволяйте аутентифікацію тільки звичайним користувачам, а потім підвищуйте привілеї за допомогою sudo.
- Контролюйте доступ до SSH за допомогою файлів журналів (/var/log/auth.log) або таких інструментів безпеки, як Fail2Ban, які блокують IP-адреси після кількох невдалих спроб.
- Обмежте діапазони IP-адрес, з яких дозволено доступ до SSH, за допомогою правил брандмауера або sshd_config з параметрами AllowUsers або Match Address.
- Розгляньте можливість використання апаратних модулів безпеки (HSM) або YubiKeys для зберігання закритих ключів, особливо в середовищах із високим рівнем безпеки.
У хмарних середовищах такі провайдери, як AWS, Google Cloud і Azure, пропонують власні механізми введення ключів і управління їхнім життєвим циклом, які інтегруються з метаданими екземпляра або політиками на основі ідентифікації. Навіть у самокерованому хостингу деякі платформи дають змогу вводити SSH-ключі під час створення ВМ, що ідеально підходить для ефемерної інфраструктури.
Висновок
Налаштування доступу до сервера за допомогою аутентифікації за SSH-ключами - одна з основоположних навичок у системному адмініструванні та хмарних обчисленнях. Воно підвищує безпеку, дає змогу автоматизувати і спрощує управління в різних середовищах. Зрозумійте, як генерувати, встановлювати та керувати ключами SSH для створення більш надійних і безпечних інфраструктур.
У поєднанні з іншими методами забезпечення безпеки, як-от двофакторна автентифікація, обмеження доступу до IP-адрес і автоматична ініціалізація, доступ до SSH-ключів стає основним компонентом безпечної системи. Управління персональним VPS або цілим парком корпоративних серверів вимагає майстерності в налаштуванні ключів SSH для досягнення операційної досконалості в сучасному обчислювальному ландшафті.
