SSH с публичным ключом на Debian Etch

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

Это мини-руководство объясняет, как настроить SSH-сервер на Debian Etch с авторизацией по публичным ключам (и по желанию — с отключёнными входами по паролю). Debian Etch — устаревшая версия Debian; многие шаги применимы к современным Debian-подобным системам, но пакеты и пути конфигурации могут отличаться.

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

Краткая терминология

Публичный ключ: файл, который копируют на сервер (обычно в ~/.ssh/authorized_keys). Короткое определение.
Приватный ключ: файл, который должен оставаться только у клиента. Гарантирует доступ при корректном пароле-ключе.

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

Войдите на сервер как root (или используйте sudo) и установите пакет SSH:

apt-get install ssh

Примечание: в современных системах пакет называется openssh-server.

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

На клиентской машине установите SSH-клиент (если отсутствует):

apt-get install openssh-client

Переключитесь на обычного пользователя (не root) и выполните:

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

Сгенерируйте пару ключей (рекомендуется RSA или ED25519; ED25519 более современный и компактный):

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

Или для ED25519:

ssh-keygen -t ed25519 -C "your-email@example.com"

Совет: используйте длинную фразу-пароль (passphrase) для приватного ключа.

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

Есть несколько способов. Покажем ручной метод и более удобный (ssh-copy-id).

Ручной метод (через scp):

scp -p id_rsa.pub remoteuser@remotehost:

Затем на сервере (не как root):

ssh remoteuser@remotehost
mkdir ~/.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 remoteuser@remotehost

Если всё сделано верно, система запросит passphrase к приватному ключу.

Альтернатива (удобно):

ssh-copy-id remoteuser@remotehost

ssh-copy-id автоматически создаёт ~/.ssh и добавить ключ в authorized_keys.

Отключение входа по паролю

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

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

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

PermitRootLogin no
PasswordAuthentication  no
UsePAM  no

Сохраните и перезапустите службу SSH:

/etc/init.d/ssh restart

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

Контрольный список для администратора

Есть рабочий приватный ключ у пользователя.
Публичный ключ прописан в ~/.ssh/authorized_keys на сервере.
Права доступа: ~/.ssh = 700, authorized_keys = 600.
Перезапуск sshd после изменения конфигурации.
Резервный доступ (консоль/локальный логин) на случай проблем.

Контрольный список для пользователя

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

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

Удалённый вход по SSH возможен с использованием приватного ключа.
В случае отключённой аутентификации по паролю попытка входа по паролю отклоняется.
Права доступа к файлам ~/.ssh корректны.

Устранение неполадок

Если ssh запрашивает пароль, а не использует ключ:
- Проверьте, что имя пользователя и хост верны.
- Убедитесь, что приватный ключ читается клиентом: ssh -v remoteuser@remotehost покажет, какие ключи пробует клиент.
- Проверьте права доступа на сервере: ~/.ssh должно быть 700, ~/.ssh/authorized_keys — 600.
- Убедитесь, что в /etc/ssh/sshd_config не запрещены нужные методы аутентификации.
Если после перезапуска sshd вы потеряли доступ:
- Используйте физический доступ или консоль провайдера для восстановления.
- Восстановите файл /etc/ssh/sshd_config из sshd_config.orig и перезапустите sshd.

Когда это может не сработать

Если сервер использует централизованную аутентификацию (например, LDAP/AD) с иными настройками.
Если на сервере есть процессы, меняющие права на домашние каталоги или ssh-конфигурации.
Если сеть блокирует SSH-порт или применяются промежуточные прокси/бастион.

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

Использовать ssh-copy-id для автоматического копирования public key.
Применять управление конфигурацией (Ansible/Chef/Puppet) для массовой установки ключей.
Использовать одноразовые токены/SSH-сертификаты и CA для крупной инфраструктуры.

Мини-методология (быстрая процедура)

Установить openssh-server на сервере.
На клиенте сгенерировать ключи (ssh-keygen).
Передать публичный ключ на сервер (ssh-copy-id или scp).
Проверить вход по ключу.
Отключить PasswordAuthentication и перезапустить sshd.
Контролировать логи и доступность сервиса.

Пример диагностики с выводом (используйте подробный режим)

ssh -vvv remoteuser@remotehost

Анализируйте строки, где клиент пытает ключи и где сервер их отклоняет.

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

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

Итог

Настройка SSH с аутентификацией по публичному ключу повышает безопасность удалённого доступа. Всегда проверяйте работу входа по ключу прежде чем отключать пароли и держите резервный канал доступа. Следуйте контрольным спискам и рекомендациям по безопасности.

Важно: если вы используете Debian Etch в продакшене, подумайте об обновлении системы до поддерживаемой версии Debian.