SSH-доступ до серверів безпосередньо з інтернету — поширена практика, яка робить кожен хост мішенню. Для команди з 20 інженерів, що керує 50 серверами, це 50 відкритих портів — величезна поверхня атаки. Bastion host (jump server) зводить її до одного публічного IP. Ми налаштовуємо такий вузол з IP-вайтлістом, обов'язковою MFA та повним логуванням усіх сесій. Результат — доступ для розробників прозорий, а безпека на рівні корпоративних стандартів.
Чому bastion host, а не VPN або прямий SSH?
Прямий SSH до кожного сервера множить поверхню атаки: кожен хост — окрема ціль. Для 50 серверів це 50 IP-адрес, які потрібно захищати. VPN (OpenVPN, WireGuard) дає єдиний вхід, але додає складність управління сертифікатами та клієнтами. Bastion — золота середина: один публічний IP, мінімум рухомих частин, максимальна прозорість для розробників. ProxyJump у ~/.ssh/config робить роботу з bastion непомітною.
Як працює ProxyJump?
Сучасний спосіб роботи з bastion — ProxyJump у ~/.ssh/config. Жодного agent forwarding (вразливо), жодного копіювання ключів на bastion:
# ~/.ssh/config
Host bastion.corp.example.com
User ec2-user
IdentityFile ~/.ssh/corp-key.pem
ServerAliveInterval 30
Host 10.0.*.*
ProxyJump bastion.corp.example.com
User ubuntu
IdentityFile ~/.ssh/corp-key.pem
Host prod-db-01
Hostname 10.0.2.50
ProxyJump bastion.corp.example.com
User ubuntu
Після цього ssh prod-db-01 прозоро з'єднується через bastion. Ключ користувача ніколи не залишає його машину — SSH-агент форвардить лише конкретне підписання, а не сам ключ.
Які налаштування захищають bastion?
Bastion — це ціль. Його потрібно максимально закрити. Рекомендовані налаштування sshd_config:
| Параметр | Значення | Навіщо |
|---|---|---|
Port |
22 (або нестандартний) | Для скритності — нестандартний порт знижує шум від ботів |
PermitRootLogin |
no | Заборона прямого root-доступу |
PasswordAuthentication |
no | Тільки ключі |
PubkeyAuthentication |
yes | Обов'язково |
AllowGroups |
ssh-users | Обмеження за групами |
LogLevel |
VERBOSE | Детальне логування |
MaxAuthTries |
3 | Обмеження спроб входу |
ClientAliveInterval |
300 | Перевірка активності |
ClientAliveCountMax |
2 | Відключення неактивних сесій |
Firewall: вхідний SSH тільки з діапазонів IP офісу або VPN. В AWS це Security Group з дозволом порту 22 тільки з корпоративних IP-адрес. Egress — тільки на внутрішні підмережі продакшну.
# AWS Security Group через awscli
aws ec2 authorize-security-group-ingress \
--group-id sg-bastion-id \
--protocol tcp --port 22 \
--cidr 203.0.113.0/24 # корпоративний IP
# Заборона всього іншого вхідного
aws ec2 revoke-security-group-ingress \
--group-id sg-bastion-id \
--protocol tcp --port 22 \
--cidr 0.0.0.0/0
Як додати MFA на bastion?
MFA через PAM-модуль google-authenticator:
apt install libpam-google-authenticator
# /etc/pam.d/sshd — додати на початок
auth required pam_google_authenticator.so nullok
# /etc/ssh/sshd_config
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactiveКористувач проходить два фактори: публічний ключ + TOTP. nullok дозволяє користувачам без налаштованого TOTP поки логінитися — прибирається після повного rollout.
Порівняння методів SSH-доступу
| Метод | Безпека | Складність | Зручність для користувачів | Аудит |
|---|---|---|---|---|
| Прямий SSH до кожного сервера | Низька (багато точок входу) | Низька | Висока | Ні |
| OpenVPN + SSH | Висока (шифрування тунелю) | Середня | Середня (потрібен VPN-клієнт) | Ні |
| Agent forwarding | Середня (ключ на bastion) | Низька | Висока | Ні |
| Bastion + ProxyJump | Висока (ключ не залишає клієнт) | Низька | Висока (прозоро) | Так (логи sshd) |
Що входить у роботу з налаштування bastion
- Аналіз поточної схеми доступу та проектування архітектури bastion host під вашу інфраструктуру (AWS/GCP/Yandex Cloud).
- Налаштування hardened sshd_config з рекомендаціями CIS.
- Інтеграція MFA (Google Authenticator, Duo Security).
- Централізоване логування (Loki, ELK) з retention-політиками.
- Шаблони Ansible/Terraform для автоматизації розгортання.
- Документація (runbook, схема доступу).
- Навчання команди (як додати нових користувачів, як працювати з ProxyJump).
Типові помилки при налаштуванні bastion
- Використання agent forwarding замість ProxyJump — ключ опиняється на bastion. - Слабкий пароль або незакриті парольні доступи. - Відсутність логування — неможливо розслідувати інциденти. - Ігнорування MFA для адміністраторів.Терміни та етапи впровадження
| Етап | Тривалість | Результат |
|---|---|---|
| Аналітика та проектування | 1 день | Схема доступу, вибір IP-діапазонів |
| Розгортання bastion (AWS/GCP) | 1 день | Робочий bastion з IP-вайтлістом та hardened sshd |
| Налаштування MFA та ProxyJump | 1–2 дні | Користувачі підключаються з двофакторкою |
| Централізоване логування | 1 день | Логи сесій відправляються в центральну систему |
| Автоматизація (Ansible/Terraform) | 1–2 дні | Повторюване розгортання |
Базовий bastion на AWS/GCP з IP-вайтлістингом, hardened sshd, ProxyJump-конфігами для команди налаштовується за 1 день. З MFA, централізованим логуванням та ansible-автоматизацією — 2–3 дні.
Чому варто звернутися до нас?
Ми впровадили bastion host для 20+ клієнтів — від стартапів до великих e-commerce проєктів. Використовуємо лише перевірені патерни: ProxyJump замість agent forwarding, Google Authenticator PAM для MFA, RSYSLOG для централізованого збору логів. Гарантуємо, що ключі користувачів ніколи не з'являться на bastion, а всі сесії будуть записані. Отримайте консультацію щодо вашого проєкту — ми оцінимо поточну схему доступу та запропонуємо оптимізоване рішення.
