Настройка SSH с аутентификацией по публичному ключу на Debian Etch

Предварительные замечания

SSH (Secure Shell) — протокол для защищённого удалённого доступа к Unix-подобным системам. Одной строкой: SSH обеспечивает шифрованный канал между клиентом и сервером.

Важно: инструкции подходят для Debian Etch и похожих систем. На других дистрибутивах могут быть небольшие отличия (пути, имена пакетов, init-сценарии). Всегда имейте физический доступ или альтернативный доступ к серверу перед отключением паролей.

Установка SSH на сервере

Сначала установите SSH-сервер на машине, к которой будете подключаться. Требуются права root:

apt-get install ssh

На более новых Debian-подобных системах пакет может называться openssh-server.

Подготовка на клиентской (рабочей) машине

На рабочем компьютере выполняются генерация ключа и подключение. Убедитесь, что у вас установлен SSH-клиент и вы можете выполнить команды от обычного пользователя (не постоянно под root).

Установка клиента (если нужно):

apt-get install openssh-client

Создайте каталог ~/.ssh и задайте безопасные права:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
cd ~/.ssh

Сгенерируйте пару ключей (публичный и приватный). При запросе passphrase — лучше задать её, чтобы приватный ключ был зашифрован:

ssh-keygen -t rsa -C "A comment... usually an email is enough here..."

Ключи по умолчанию: приватный — ~/.ssh/id_rsa, публичный — ~/.ssh/id_rsa.pub.

Копирование публичного ключа на сервер

Скопируйте публичный ключ на удалённый сервер. Используйте учётную запись непользователя root (remoteuser):

scp -p id_rsa.pub remoteuser@remotehost:

Войдите на сервер и поместите ключ в ~/.ssh/authorized_keys с корректными правами:

ssh remoteuser@remotehost
mkdir -p ~/.ssh
chmod 700 ~/.ssh
cat id_rsa.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
mv id_rsa.pub ~/.ssh
logout

На клиенте удалите временный публичный файл, чтобы не запутаться:

rm id_rsa.pub

Повторно подключитесь по SSH:

ssh remoteuser@remotehost

Если всё правильно настроено, SSH запросит passphrase от приватного ключа (если вы его задали) и выполнит вход без пароля учётной записи.

Отключение аутентификации по паролю

Отключать пароли безопасно только после проверки, что вход по ключам уже работает. Для этого потребуется физический доступ к серверу (или альтернативный доступ), так как SSH будет перезапущен.

Выполните на сервере от root:

cd /etc/ssh
cp sshd_config sshd_config.orig
nano sshd_config

Найдите и измените (или раскомментируйте) следующие строки:

PermitRootLogin     no
PasswordAuthentication  no
UsePAM          no

Сохраните файл (Ctrl+O в nano) и перезапустите SSH-сервис:

/etc/init.d/ssh restart

Важно: после этого вход по паролю будет полностью запрещён — только ключи.

Рекомендации по безопасности и жёсткая конфигурация

• Отключите вход под root: PermitRootLogin no (уже сделано выше). Это предотвращает прямые атаки на root.
• Разрешите вход только определённым пользователям: добавьте AllowUsers user1 user2 в /etc/ssh/sshd_config.
• Перенесите SSH на нестандартный порт (например, Port 2222) — это не обеспечивает безопасность, но уменьшает «шум» в логах.
• Используйте Fail2Ban или аналог для блокировки попыток грубой силы.
• Храните приватный ключ в защищённом месте и делайте резервные копии зашифрованных ключей.
• Обновляйте пакет openssh-server и систему безопасности регулярно.

Тестирование и отладка

Если вход не работает, используйте подробный вывод клиента и проверяйте логи на сервере:

ssh -v remoteuser@remotehost

На сервере проверьте /var/log/auth.log (или /var/log/secure на некоторых системах) на предмет ошибок аутентификации.

Частые причины сбоев:

• Неправильные права на ~/.ssh (должно быть 700) или на authorized_keys (600).
• Публичный ключ записан в неправильном формате/с лишними переносами строки.
• SELinux/AppArmor блокирует доступ (на системах с этими механизмами).
• На сервере включён принудительный deny в конфигурации SSH.

Когда этот подход может не подойти

• Если у вас нет возможности безопасно хранить приватный ключ (например, общий терминал) — тогда ключи не дают преимущества.
• В средах, где требуется централизованное управление ключами (LDAP, Kerberos), ручное размещение authorized_keys неудобно.
• Если требуется многофакторная аутентификация, ключи можно дополнять, но не заменяют её.

Альтернативные подходы

• Управление ключами через централизованные решения (Salt, Ansible, LDAP, FreeIPA).
• Использование аппаратных токенов/смарт-карт (например, YubiKey) для хранения приватных ключей.
• Развертывание одноразовых паролей (OTP) или двухфакторной аутентификации поверх SSH.

Пошаговая методология для развёртывания в организации

1. Подготовка: инвентаризация серверов и пользователей.
2. Генерация ключей пользователями и валидация (получить публичные ключи).
3. Автоматизированное размещение ключей (Ansible/SSH-ACL) и правок конфигурации.
4. Тестирование доступа с контроля (ssh -v, логи).
5. Переключение в режим без паролей и мониторинг.
6. Обратный план (физический доступ/консоль) на случай проблем.

Рольовые чек-листы

Администратор сервера:

• Сделать резервную копию /etc/ssh/sshd_config.
• Настроить права для ~/.ssh и authorized_keys.
• Убедиться в работоспособности входа по ключу.
• Перезапустить сервис и мониторить логи.

Пользователь (клиент):

• Сгенерировать ключ и хранить приватный ключ защищённо.
• Передать публичный ключ администратору.
• Проверить вход и задать passphrase для приватного ключа.

Простая матрица рисков и смягчения

• Риск: Потеря приватного ключа → Смягчение: иметь резервную копию, использовать зашифрованный ключ и хранение на аппаратном токене.
• Риск: Блокировка доступа после отключения паролей → Смягчение: иметь локальный (консольный) доступ или временный root-аккаунт.
• Риск: Утечка публичного ключа → Смягчение: публичный ключ сам по себе не даёт доступа без приватного ключа, но управляйте списком доверенных ключей.

Краткий глоссарий

• SSH: защищённый протокол удалённого доступа.
• Публичный ключ: открытая часть пары ключей, размещается на сервере.
• Приватный ключ: секретная часть, хранится на клиенте.
• authorized_keys: файл на сервере со списком доверенных публичных ключей.

Критерии приёмки

• Пользователь может подключиться по SSH без ввода пароля учётной записи сервера.
• При перезапуске SSH служба запускается без ошибок, в логах нет отказов в аутентификации.
• Права на ~/.ssh и authorized_keys установлены корректно (700 и 600).

Короткая памятка команд (cheat sheet)

# на клиенте
ssh-keygen -t rsa
scp -p ~/.ssh/id_rsa.pub remoteuser@remotehost:
ssh remoteuser@remotehost
rm ~/.ssh/id_rsa.pub
ssh -v remoteuser@remotehost

# на сервере
mkdir -p ~/.ssh && chmod 700 ~/.ssh
cat id_rsa.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
/etc/init.d/ssh restart

Полезные ссылки

http://www.openssh.org http://en.wikipedia.org/wiki/Secure_Shell

Итог

Аутентификация по публичному ключу — простой и надёжный способ обеспечить безопасный доступ по SSH. Главное — корректно настроить права, убедиться в работоспособности ключей и иметь план восстановления доступа перед отключением паролей.

Важно: не отключайте PasswordAuthentication, пока вы не убедились, что вход по ключу стабилен и у вас есть резервный способ доступа к серверу.