Как настроить SSH на Linux — клиент и сервер

Что такое SSH

SSH (Secure Shell) — безопасный протокол удалённого доступа к командной строке Linux. Он позволяет выполнять команды, управлять сервисами, переносить файлы и туннелировать трафик между устройствами по локальной сети и через интернет. SSH не даёт удалённого доступа к графическому рабочему столу (для этого используются RDP/VNC), но в сочетании с X11/переадресацией портов можно запускать отдельные графические приложения.

Определение: SSH — защищённый канал для удалённого выполнения команд и управления системой через терминал.

Важно: для работы SSH на целевом компьютере нужен SSH-сервер (чаще всего openssh-server). На клиенте должен быть SSH-клиент (часто уже установлен).

Кому это нужно и зачем

• Системным администраторам — для управления серверами и выполнения обновлений
• Девопс-инженерам — для доступа к CI/CD-агентам, контейнерам и облачным машинам
• Разработчикам — для отладки на удалённых средах
• Пользователям — чтобы управлять медиасерверами и домашними устройствами

Установка SSH на клиенте

В большинстве случаев дополнительных действий не требуется:

• На Linux SSH-клиент обычно встроен в терминал (ssh)
• На macOS SSH предустановлен в Терминале
• На Windows 10/11 можно использовать PowerShell (встроенный OpenSSH-клиент) или PuTTY

Мобильные клиенты:

• iOS: iTerminal — платное приложение (пример $4.99) — установка через App Store
• Android: JuiceSSH — бесплатная версия доступна в Google Play

Если SSH отсутствует на Linux-клиенте, установите его командой:

sudo apt update && sudo apt upgrade
sudo apt install openssh-client

Если вы раньше работали в Windows с PuTTY и хотите иметь его на Linux:

sudo apt install putty

После установки клиента для подключения вам понадобится IP-адрес или имя хоста и учётные данные.

Установка и базовая настройка SSH на сервере

Чтобы сервер принимал подключения по SSH, установите пакет OpenSSH Server и включите сервис:

sudo apt update
sudo apt install openssh-server
sudo systemctl enable --now ssh
sudo systemctl status ssh

Ожидаемый статус: “active (running)”.

Если используется UFW (брандмауэр Ubuntu), разрешите SSH:

sudo ufw allow ssh
sudo ufw enable   # если ещё не включён
sudo ufw status

Альтернативно можно явно указать порт:

sudo ufw allow 2222/tcp

Где 2222 — пример нестандартного порта.

Если сервер находится за маршрутизатором, убедитесь, что порт 22 (или ваш выбранный порт) проброшен на локальный IP сервера (port forwarding).

Определение IP-адреса

Локальный IP (в сети):

ip address
# или для старых систем
ifconfig

Публичный IP: посетите сайт https://whatismyip.org или выполните на сервере:

curl ifconfig.me

Выбор адреса:

• Если клиент в той же локальной сети — используйте локальный IP
• Если подключаетесь через интернет — используйте публичный IP и настройте перенаправление портов

Как подключиться по SSH

Базовая команда для подключения из терминала:

ssh username@REMOTE.IP.ADDRESS

Пример:

ssh alice@192.168.1.42

Если используется нестандартный порт, добавьте параметр -p:

ssh -p 2222 alice@203.0.113.5

В PuTTY укажите Host Name (или IP), выберите тип соединения SSH и нажмите Open. При первом подключении SSH покажет отпечаток ключа сервера — подтвердите, если вы доверяете хосту.

SSH-ключи — рекомендуемый способ аутентификации

Ключевая практика: используйте пару ключей (приватный/публичный) вместо пароля. Это повышает безопасность и позволяет автоматизировать доступ.

Генерация ключей на клиенте:

ssh-keygen -t ed25519 -C "your_email@example.com"
# или для совместимости
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

По умолчанию ключи сохраняются в ~/.ssh/id_ed25519 и ~/.ssh/id_ed25519.pub. Защитите приватный ключ надёжной passphrase.

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

ssh-copy-id -i ~/.ssh/id_ed25519.pub username@REMOTE.IP.ADDRESS

Если ssh-copy-id недоступна, можно добавить ключ вручную:

cat ~/.ssh/id_ed25519.pub | ssh username@REMOTE.IP.ADDRESS "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"

Использование ssh-agent для хранения passphrase (локально):

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Пример конфигурации клиента ~/.ssh/config для удобных алиасов:

Host my-server
    HostName 203.0.113.5
    User alice
    Port 2222
    IdentityFile ~/.ssh/id_ed25519

После этого достаточно ssh my-server.

Базовое ужесточение безопасности SSH (hardening)

Рекомендуемые пункты:

• Отключите вход root по паролю: в /etc/ssh/sshd_config установите PermitRootLogin prohibit-password или no
• Отключите аутентификацию по паролю (PasswordAuthentication no) после настройки ключей
• Используйте ключи ED25519 или RSA 4096
• Ограничьте доступ по IP (если применимо) через брандмауэр
• Установите Fail2Ban для блокировки повторных попыток входа
• Следите за обновлениями пакетов и ядра

Пример безопасных строк в /etc/ssh/sshd_config:

Port 2222
PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
AllowUsers alice bob

После изменений перезапустите сервис:

sudo systemctl restart ssh

Транспортировка файлов: SCP и SFTP

Копирование файла на сервер:

scp /path/to/local.file username@REMOTE.IP.ADDRESS:/remote/path/

Интерактивный перенос и работа с файлами через SFTP:

sftp username@REMOTE.IP.ADDRESS
sftp> put local.file
sftp> get remote.file

Тонкая диагностика и устранение неполадок

Если не удаётся подключиться, используйте пошаговую диагностику.

1. Повышенная детализация клиента:

ssh -vvv username@REMOTE.IP.ADDRESS

2. На сервере проверьте статус и прослушиваемые порты:

sudo systemctl status ssh
ss -tlnp | grep ssh
# или
sudo netstat -tlnp | grep ssh

3. Просмотр логов авторизации:

sudo tail -n 200 /var/log/auth.log
# или для систем с journalctl
sudo journalctl -u ssh --since "1 hour ago"

4. Типичные ошибки и решения:

• Connection refused — сервис SSH не запущен или порт не прослушивается. Проверьте systemctl и ufw.
• No route to host / Network is unreachable — сетевые проблемы или неправильно указан IP/маршрут.
• Permission denied (publickey) — ключи не скопированы, права на ~/.ssh/authorized_keys неверны (должны быть 600), или PasswordAuthentication выключён.
• Host key verification failed — отпечаток ключа сервера изменился; проверьте возможную замену сервера (man-in-the-middle) и удалите запись из ~/.ssh/known_hosts, если уверены.

Разбор сценариев: когда SSH не подойдёт

• Нужен графический рабочий стол целиком — используйте RDP/VNC или xRDP
• Передача больших файлов с синхронизацией — rsync поверх SSH лучше, но для сетевого диска может потребоваться NFS/SMB
• Ограничение политикой компании — используйте VPN плюс SSH или согласуйте с сетью безопасности

Рекомендации по сети: NAT, порт-форвардинг и динамический DNS

Если сервер в домашней сети за роутером:

• Настройте проброс порта 22 (или выбранного) на локальный IP сервера
• Для стабильного доступа используйте статический локальный IP или DHCP reservation
• Для внешнего доступа с переменным публичным IP используйте DDNS (динамический DNS) сервис

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

Полезные команды и «шпаргалка» (cheat sheet)

• Подключение: ssh user@host
• Подключение с портом: ssh -p 2222 user@host
• Копирование файла: scp file user@host:/path/
• Быстрая проверка порта: nc -zv host 22
• Список слушающих портов: ss -tlnp
• Проверка логов: sudo tail -f /var/log/auth.log

Чек‑листы по ролям

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

• Установлен openssh-server
• Сервис ssh включён и работает
• Настроен UFW/iptables и разрешён SSH-порт
• Ключи пользователей добавлены в authorized_keys
• Отключён вход root по паролю
• Fail2Ban или аналог установлен
• Регулярные обновления настроены (apt upgrade)

Разработчик (подключается к серверу):

• Сгенерирован SSH-ключ и сохранён приватный ключ
• Публичный ключ передан администратору/установлен на сервере
• Добавлен в ssh-agent при необходимости
• Настроен ~/.ssh/config для удобства

Служба поддержки (помощь пользователям):

• Уточнить IP/порт и логин пользователя
• Проверить доступность сервера по ping/портам
• Собрать вывод ssh -vvv и логи с сервера

Мероприятия по безопасности и мониторингу

• Включите аудит логов (fail2ban, logwatch)
• Ограничьте список пользователей через AllowUsers/AllowGroups
• Периодически проверяйте файлы known_hosts на неожиданные изменения
• Используйте двухфакторную аутентификацию для ключей (например, hardware tokens) где возможно

Диагностическое дерево (Mermaid)

flowchart TD
    A[Проблема: не подключаюсь по SSH] --> B{Ответ от сервера?}
    B -->|Нет| C[Проверьте сеть, ping, маршруты]
    B -->|Да| D{Сервер откликается на порт?}
    D -->|Нет| E[Проверьте firewall/port forwarding]
    D -->|Да| F{Аутентификация проваливается?}
    F -->|Да| G[Проверьте ключи, права файлов, /var/log/auth.log]
    F -->|Нет| H[Проверьте known_hosts и отпечаток ключа]
    C --> I[Проверьте DNS/маршрутизатор]
    E --> I
    G --> J[Переустановите ключи или включите пароли временно]
    H --> K[Обновите запись known_hosts или подтвердите изменение]

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

• Сервер принимает SSH-подключения с клиента по указанному порту
• Аутентификация проходит с помощью SSH-ключа без ошибок
• Доступ для root заблокирован (если это требование безопасности)
• Брандмауэр пропускает только нужные порты
• Логи не содержат повторяющихся попыток взлома (после настройки Fail2Ban)

Часто задаваемые вопросы

Нужно ли менять порт по умолчанию 22?

Изменение порта (security by obscurity) иногда уменьшает фоновые сканирования, но не заменяет реальные меры безопасности (ключи, Fail2Ban). Это вспомогательная мера.

Как восстановить доступ, если потерял приватный ключ?

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

Можно ли передавать графические приложения по SSH?

Да — с помощью X11 forwarding (ssh -X) или через VNC/tunneling, но для полного рабочего стола лучше использовать специализированные решения.

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

• SSH: защищённый протокол доступа к терминалу
• SSH-key: пара криптографических ключей (приватный/публичный)
• Authorized_keys: файл на сервере с публичными ключами пользователей
• UFW: упрощённый интерфейс для настройки iptables на Ubuntu
• Fail2Ban: инструмент для автоматического блокирования IP при множественных неудачных попытках входа

Ресурсы и следующий шаг

• Список полезных команд: используйте man ssh, man sshd_config, man ssh-keygen
• Если нужна передача GUI: настройте VNC поверх SSH туннеля
• Для автоматического развёртывания ключей рассмотрите инструменты конфигурации (Ansible, Puppet, Chef)

Завершение: корректная настройка SSH делает Linux-системы доступными и управляемыми удалённо с надлежащим уровнем безопасности. Настройте ключи и брандмауэр, документируйте доступы и проверяйте логи — это минимальный набор для безопасного использования SSH.

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