Настройка SSH в Alt Linux

SSH позволяет управлять компьютером с Alt Linux по сети и передавать файлы через SFTP. Ниже — безопасная схема: сначала проверить службу и сеть, затем подключить вход по ключу и только после успешного теста ограничить вход по паролю.

Настройка SSH в Alt Linux: короткий и прямой ответ

Настройка SSH в Alt Linux сводится к установке серверного пакета OpenSSH, запуску службы sshd и проверке подключения с другого устройства. Для безопасного постоянного доступа создайте ключи SSH на клиенте, добавьте публичный ключ пользователю на компьютере с Alt Linux и лишь затем отключайте парольный вход.

SSH — это зашифрованный протокол удалённого входа в систему. По умолчанию он использует порт 22, но сам факт открытого порта ещё не означает, что подключение доступно: служба должна работать, а сетевой экран и маршрутизатор не должны блокировать трафик. Для локальной сети обычно достаточно адреса вида 192.168.x.x; для доступа из интернета потребуется отдельная и более рискованная настройка маршрутизатора.

Основные команды выполняют в терминале от имени администратора через su - либо с sudo, если оно настроено. Не закрывайте текущее локальное окно терминала, пока не проверите новое SSH-подключение: это сохранит возможность исправить ошибку в конфигурации. Для одной домашней машины достаточно обычного пользователя; удалённый вход под root лучше не включать.

Почему возникает проблема или зачем нужна эта настройка

Alt Linux SSH настройка нужна, когда к компьютеру требуется обращаться без монитора: запускать команды, обновлять систему, копировать документы или обслуживать домашний сервер. SFTP работает поверх SSH и даёт передачу файлов в том же защищённом соединении, без отдельного FTP-сервера.

Частая причина ошибки «Connection refused» — сервер SSH не установлен, отключён или не слушает нужный адрес. Если клиент долго ждёт и сообщает о тайм-ауте, чаще мешают сетевой экран, неверный IP-адрес, изоляция устройств в гостевой Wi‑Fi-сети либо правило маршрутизатора. Сообщение о неверном пароле или ключе означает, что сеть и служба уже доступны, поэтому проверять нужно учётную запись, ключ и параметры входа.

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

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

Что проверить и подготовить перед основными действиями

Перед началом убедитесь, что у вас есть физический доступ к компьютеру с Alt Linux или активная локальная консоль. Запишите его имя пользователя и текущий IP-адрес: выполнить можно ip -br address. Ищите строку активного интерфейса с адресом inet; адрес 127.0.0.1 годится только для проверки на самом компьютере.

Проверьте наличие клиента и сервера: ssh -V покажет версию клиента, а rpm -q openssh-server сообщит, установлен ли серверный пакет. Если пакет отсутствует, обновите сведения о репозиториях и установите его командой apt-get update и затем apt-get install openssh-server. Во время обновления или установки не выключайте компьютер и не прерывайте питание.

Подготовьте второе устройство в той же сети — другой ПК с Linux, macOS или Windows 10/11. В актуальных Windows клиент OpenSSH можно добавить в разделе «Параметры» → «Система» → «Дополнительные компоненты» → «Просмотреть компоненты»; после установки команда ssh работает в PowerShell. Подключение из другой подсети может требовать правил сети, поэтому первый тест всегда делайте внутри одной локальной сети.

Создайте резервную копию конфигурации до изменения: cp /etc/openssh/sshd_config /etc/openssh/sshd_config.bak. Команда не меняет работающую настройку и позволяет вручную вернуть файл из локальной консоли. Не копируйте в статью, переписку или облако закрытый файл ключа ~/.ssh/id_ed25519: он должен оставаться только на устройстве владельца.

Если вход в систему зависит от правильных часов, проверьте часовой пояс и состояние службы времени до диагностики сертификатов и ключей. Отдельная настройка синхронизации времени linux помогает исключить ошибку времени, которая иногда проявляется при работе с защищёнными сетевыми сервисами.

Пошаговое решение для актуальных версий системы или устройства

Для актуальных выпусков Alt Linux с systemd включите сервер командой systemctl enable --now sshd. Затем проверьте состояние: systemctl status sshd. В результате должно быть active (running); клавишей q можно выйти из просмотра. Для проверки настроек до перезапуска применяйте sshd -t: отсутствие вывода обычно означает, что синтаксических ошибок не найдено.

1. Узнайте IP-адрес сервера и с другого компьютера выполните ssh имя_пользователя@IP_адрес. При первом контакте клиент попросит подтвердить отпечаток ключа сервера. Сверяйте его только с отпечатком, полученным из доверенного источника или с локальной консоли; не соглашайтесь автоматически в незнакомой сети.
2. На клиентском устройстве создайте современную пару ключей: ssh-keygen -t ed25519. Можно задать понятное имя файла и надёжную парольную фразу для закрытого ключа. На сервере создайте каталог и файл для публичного ключа: mkdir -p ~/.ssh, затем chmod 700 ~/.ssh; вставьте содержимое файла с расширением .pub в ~/.ssh/authorized_keys одной строкой и выполните chmod 600 ~/.ssh/authorized_keys.
3. Проверьте вход по ключу в новом окне: ssh -i ~/.ssh/id_ed25519 имя_пользователя@IP_адрес. Если ключ назван стандартно и лежит в ~/.ssh, параметр -i обычно не нужен. Права ~/.ssh критичны: при слишком открытом доступе сервер вправе отказаться использовать ключ.
4. Только после успешного входа откройте /etc/openssh/sshd_config в привычном текстовом редакторе от администратора. Добавьте или измените параметры PubkeyAuthentication yes, PasswordAuthentication no и PermitRootLogin no. Убедитесь, что одинаковая директива не задана ниже повторно с противоположным значением; действующее значение зависит от итоговой конфигурации.
5. Выполните sshd -t, затем systemctl restart sshd и заново подключитесь во втором окне. Если нужен файловый доступ, в программе-клиенте выбирайте протокол SFTP, адрес сервера, имя пользователя и тот же ключ, а не FTP.

Не меняйте порт 22 только ради «маскировки»: это не заменяет ключи, обновления и ограничения доступа. Если в системе включён firewalld, сначала посмотрите активную зону и правила командой firewall-cmd --get-active-zones, а затем разрешайте SSH только в той зоне, которой принадлежит сетевой интерфейс. Перед удалённым изменением правила убедитесь, что локальная консоль доступна.

Типичные ошибки, безопасный откат и проверка результата

Если после правки подключение перестало работать, не перезагружайте компьютер сразу. Откройте локальную консоль, проверьте конфигурацию через sshd -t, посмотрите состояние systemctl status sshd и последние сообщения службы командой journalctl -u sshd -b. Эти действия только читают состояние и не удаляют данные.

Ошибка «Permission denied (publickey)» обычно связана с тем, что в authorized_keys попал не публичный ключ, выбрана другая учётная запись или нарушены права ~/.ssh. На сервере проверьте владельца файлов командой ls -ld ~/.ssh ~/.ssh/authorized_keys: каталог и файл должны принадлежать подключаемому пользователю. Не используйте chmod 777 — такие разрешения ухудшают защиту и могут привести к отказу SSH принимать ключ.

При необходимости безопасный откат выглядит так: из локальной консоли восстановите сохранённый файл командой cp /etc/openssh/sshd_config.bak /etc/openssh/sshd_config, затем запустите sshd -t и systemctl restart sshd. Это вернёт состояние на момент резервной копии, но затрёт все изменения, сделанные в конфигурации после неё. Если резервной копии нет или на машине настроены корпоративные политики, остановитесь и обратитесь к системному администратору.

Проверяйте результат тремя способами: systemctl is-active sshd должен вывести active; ss -tln должен показывать слушающий SSH-порт; команда ssh имя_пользователя@IP_адрес с другого устройства должна запросить ключ или пароль в соответствии с выбранным правилом. Для диагностики клиента добавьте -v: ssh -v имя_пользователя@IP_адрес; вывод подскажет этап сбоя, но его не стоит публиковать без просмотра, поскольку в нём могут быть имена узлов и пути.

FAQ