Подключение к серверу по SSH: Windows, macOS и Linux

Только что заказанный сервер приходит без монитора и без клавиатуры. Единственный путь внутрь идёт через SSH, протокол Secure Shell. Эта статья проведёт вас через первое подключение с трёх операционных систем, объяснит вопрос про отпечаток ключа (который почти все новички закрывают не читая) и покажет, как передавать файлы. В конце будет та часть, которую большинство руководств опускает: что делать, если не получилось, и по каким признакам понять, что всё действительно получилось.

Все сведения проверены на Debian 13, Debian 12, Ubuntu 24.04 LTS и Ubuntu 22.04 LTS. Там, где эти четыре системы расходятся, это отмечено отдельно. Команды на сервере выполняются от root. На собственном компьютере вы, наоборот, работаете под обычной учётной записью, поэтому там перед каждой командой, меняющей систему, стоит sudo.

Что нужно перед первым подключением

Достаточно трёх вещей: IP-адрес сервера, имя пользователя и пароль или закрытый ключ. В KernelHost IP и данные доступа появляются после выдачи сервера в личном кабинете. Стандартный пользователь на свежеустановленном KVM root-сервере или выделенном сервере, как правило, root.

Четвёртым пунктом добавляется порт. По умолчанию это 22. Другое число нужно только тогда, когда вы сами его меняли или когда порт перенёс образ системы. Запомните сразу одну ловушку, которая позже сэкономит время: ssh пишет порт маленькой буквой (-p), scp большой (-P).

Во всех примерах используется 203.0.113.10. Этот адрес официально зарезервирован для документации и не существует. Замените его на IP вашего сервера.

Первое подключение в Linux и macOS

Обе системы поставляются с клиентом OpenSSH. В macOS откройте Терминал (папка «Утилиты»), в Linux любое окно терминала. Команда в обоих случаях одинаковая:

ssh root@203.0.113.10

Если SSH работает на другом порту:

ssh -p 2222 root@203.0.113.10

Если ваша система не знает команду ssh, что встречается в очень урезанных контейнерных или минимальных установках, проверить и установить её можно так:

ssh -V
sudo apt update
apt-cache policy openssh-client
sudo apt install -y openssh-client

Порядок выбран намеренно. ssh -V — это проверочная команда, а не доказательство успеха: если оболочка отвечает bash: ssh: command not found, значит пакета openssh-client нет, и вы доставляете его командой sudo apt install -y openssh-client. sudo apt update идёт перед apt-cache policy openssh-client, потому что без прочитанных списков пакетов эта команда остаётся пустой или сообщает только Installed: (none). И sudo здесь не украшение: без прав администратора apt прерывается с сообщением Could not open lock file /var/lib/apt/lists/lock.

ssh -V выводит версию в поток ошибок, а не в стандартный вывод. Это не сбой, так было всегда. В Debian 13 вы увидите OpenSSH_10.0p2, в Debian 12 OpenSSH_9.2p1, в Ubuntu 24.04 OpenSSH_9.6p1 и в Ubuntu 22.04 OpenSSH_8.9p1. Эти числа пригодятся дальше, потому что поведение scp изменилось как раз между этими версиями.

Отпечаток ключа, и почему его не стоит пропускать не глядя

При самой первой попытке подключения SSH спрашивает:

The authenticity of host '203.0.113.10 (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:qWU2Zx9mF7hLtHkQ4gRXn0aVbC3sYpJ8dKe1TmNoPU.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

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

Если вы введёте yes, отпечаток сохранится в ~/.ssh/known_hosts. С этого момента при каждом следующем подключении клиент молча проверяет, предъявляет ли сервер тот же самый ключ. Этот единственный вопрос и есть момент, в который выстраивается вся модель доверия. Дальше уже никто ни о чём не спрашивает.

По-настоящему проверить отпечаток можно только вторым, независимым путём. У KVM-сервера для этого подходит консоль в личном кабинете: там вы входите локально, вообще без сети, и выводите отпечаток.

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Вывод выглядит так:

256 SHA256:qWU2Zx9mF7hLtHkQ4gRXn0aVbC3sYpJ8dKe1TmNoPU root@server (ED25519)

Если часть после SHA256: совпадает с тем, что показывает клиент, всё в порядке. Если хотите безопасно потренироваться на этом формате, создайте себе локально одноразовый ключ:

ssh-keygen -t ed25519 -f /tmp/demo -N "" -C demo
ssh-keygen -lf /tmp/demo.pub

Два замечания из практики. Первое: у сервера обычно несколько ключей хоста (ED25519, ECDSA, RSA). Показывается, как правило, ключ ED25519, потому что современные клиенты предпочитают именно его. Если вы по ошибке сравните вывод с ssh_host_rsa_key.pub, ничего не совпадёт, хотя всё сделано верно. Второе: StrictHostKeyChecking=no полностью отключает проверку и является не решением, а отказом от защитной функции. Если вам нужна автоматизация, правильный выбор — -o StrictHostKeyChecking=accept-new: неизвестные серверы принимаются автоматически, но при изменении ключа предупреждение остаётся.

Windows: встроенный клиент OpenSSH

Начиная с Windows 10 версии 1809 Microsoft поставляет тот же клиент OpenSSH, который используют Linux и macOS. Дополнительная программа больше не нужна. Откройте PowerShell, командную строку или Windows Terminal и введите ту же команду, что и выше:

ssh root@203.0.113.10

В Windows 10 и Windows 11 клиент является дополнительным компонентом, и в большинстве установок он уже включён. Если нет, проверить и установить его можно в PowerShell с правами администратора:

Get-WindowsCapability -Online -Name OpenSSH.Client*
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

Как вариант, через «Параметры», «Система», «Дополнительные компоненты». Программы после этого лежат в C:\Windows\System32\OpenSSH\, а ваша конфигурация и известные ключи хостов в %USERPROFILE%\.ssh\, то есть обычно в C:\Users\Name\.ssh\known_hosts.

Версия для Windows отстаёт от версии для Linux. На актуальных установках Windows 11 команда ssh -V чаще всего сообщает OpenSSH_for_Windows_9.5p2. Для повседневной работы этого вполне достаточно.

Одна особенность всё же есть: права доступа Windows. Если вы положите закрытый ключ так, что его смогут читать и другие учётные записи, SSH откажется работать с сообщением Permissions for 'C:\Users\Name\.ssh\id_ed25519' are too open. Исправляется это так:

icacls "$env:USERPROFILE\.ssh\id_ed25519" /inheritance:r /grant:r "$($env:USERNAME):(R)"

Windows: PuTTY

PuTTY годами был стандартным путём под Windows и для многих им остался. Актуальна версия 0.84 от мая 2026 года. Скачивайте её исключительно со страницы автора (chiark.greenend.org.uk), а не с порталов загрузок: поддельные сборки PuTTY со встроенной кражей паролей появлялись в прошлом неоднократно.

Порядок действий: в поле Host Name (or IP address) впишите IP, в Port 22, тип соединения SSH, затем Open. Если хотите сохранить подключение, впишите заранее имя в Saved Sessions и нажмите Save. Имя пользователя PuTTY спросит только в самом окне сеанса, либо вы задаёте его в разделе Connection, Data, поле Auto-login username.

При первом подключении появляется окно PuTTY Security Alert с указанием, что ключ хоста не сохранён в кэше. Оно показывает тот же отпечаток SHA256, который выводит и OpenSSH, так что их можно сравнить один в один. Accept сохраняет ключ навсегда, Connect Once подключает только на этот раз без сохранения, Cancel отменяет.

Важное отличие от OpenSSH: у PuTTY нет файла known_hosts. Ключи попадают в реестр, в ветку HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys. Кто хочет прибраться там после переустановки своего сервера, открывает regedit и удаляет соответствующую запись. И ещё одна ловушка: PuTTY использует собственный формат ключей (.ppk). Ключ OpenSSH нужно преобразовать в PuTTYgen через Conversions, Import key, прежде чем PuTTY сможет его использовать.

Передача файлов через scp и sftp

scp копирует файлы так же, как cp, только по сети. Загрузить файл на сервер:

scp backup.tar.gz root@203.0.113.10:/root/

Скачать файл (точка в конце означает: в текущий каталог):

scp root@203.0.113.10:/var/log/syslog .

Целый каталог, и с нестандартным портом:

scp -r website root@203.0.113.10:/var/www/
scp -P 2222 backup.tar.gz root@203.0.113.10:/root/

sftp — интерактивный вариант, удобный тогда, когда сначала хочется посмотреть, что где лежит:

sftp root@203.0.113.10

Дальше вы работаете командами ls, cd, get файл, put файл на удалённой стороне и командами lls, lcd на собственном компьютере. bye завершает сеанс. Обе программы есть и под Windows, они входят в ту же самую установку. У PuTTY есть собственные аналоги, pscp и psftp, а кому нужен графический интерфейс, тот берёт WinSCP.

И вот отличие, о которое многие спотыкаются: начиная с OpenSSH 9.0 scp внутри передаёт данные уже не по старому протоколу SCP, а по SFTP. Это касается Debian 13, Debian 12 и Ubuntu 24.04. Ubuntu 22.04 с OpenSSH 8.9 использует ещё старый способ. На практике это заметно в двух местах. Шаблоны вроде *.log в удалённом пути обрабатываются иначе, а если удалённая сторона не предлагает SFTP (например, сетевое оборудование или ограниченный chroot), передача обрывается с сообщением:

subsystem request failed on channel 0
scp: Connection closed

Быстрое обходное решение — scp -O, этот ключ принудительно включает старый протокол. Чистое решение состоит в том, чтобы активировать на сервере строку Subsystem sftp /usr/lib/openssh/sftp-server в /etc/ssh/sshd_config. В Debian и Ubuntu нужный пакет openssh-sftp-server ставится как зависимость openssh-server, так что отсутствует он только в очень своеобразно собранных установках.

Предупреждение known_hosts после переустановки

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

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!      @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
Offending ED25519 key in /home/tom/.ssh/known_hosts:7
Host key for 203.0.113.10 has changed and you have requested strict checking.
Host key verification failed.

Это не ошибка, а ровно та функция, ради которой вы в первый раз ввели yes. При переустановке сервер создаёт новые ключи хоста, и старая запись больше не подходит. То же самое сообщение появляется, кстати, и тогда, когда тот же IP-адрес передали другому клиенту или когда вы запустили копию сервера.

Прежде чем удалять запись, подумайте секунду: вы действительно только что переустанавливали систему? Если да, удалите старую строку:

ssh-keygen -R 203.0.113.10

При нестандартном порте запись берётся в квадратные скобки, иначе команда ничего не найдёт:

ssh-keygen -R "[203.0.113.10]:2222"

Существует ли запись вообще, показывает ssh-keygen -F 203.0.113.10. Смотреть текстовым редактором обычно бесполезно, потому что Debian и Ubuntu по умолчанию хранят имена хостов в known_hosts в виде хеша. Искать там не получится, поэтому и нужны обе команды выше.

При следующей попытке подключения SSH снова спросит про отпечаток. Это тот самый момент, когда его стоит ещё раз сверить через консоль в личном кабинете, а не набирать yes рефлекторно. Именно этот второй шанс и есть смысл всего предупреждения.

Под Windows ssh-keygen -R работает в PowerShell точно так же. Если вы пользуетесь PuTTY, вместо этого удалите запись в реестре или подтвердите в окне WARNING - POTENTIAL SECURITY BREACH! кнопкой Accept, что новый ключ следует сохранить.

Сообщения об ошибках дословно, и что за ними стоит

Перечисленные ниже сообщения по опыту покрывают подавляющее большинство всех случаев.

• Connection refused: соединение дошло до сервера, но на порту никто не слушает. Либо служба SSH не запущена, либо она слушает другой порт. Через консоль проверьте командами systemctl status ssh и ss -tlnp, занят ли порт 22.
• Connection timed out: ответа не пришло вообще. Типично для неверного IP, выключенного сервера или файрвола, который отбрасывает пакеты вместо того, чтобы их отклонять. Проверьте IP-адрес посимвольно и правила файрвола.
• Permission denied, please try again.: имя пользователя или пароль не подходят. Самая частая причина — неверный пользователь, например root вместо ubuntu или наоборот.
• Permission denied (publickey).: сервер вообще не принимает пароли, только ключи. Во многих облачных образах так настроено по умолчанию. Либо вы прописываете свой открытый ключ, либо временно разрешаете через консоль PasswordAuthentication yes.
• Too many authentication failures: ваш агент подряд предлагает слишком много ключей, и сервер обрывает соединение раньше. Помогает ssh -o IdentitiesOnly=yes -i ~/.ssh/my_key root@203.0.113.10.
• WARNING: UNPROTECTED PRIVATE KEY FILE! вместе с Permissions 0644 for ... are too open: закрытый ключ доступен для чтения посторонним и поэтому игнорируется. В Linux и macOS помогает chmod 600 на файл ключа, в Windows команда icacls выше.
• Bad owner or permissions on ~/.ssh/config: та же причина, только для файла конфигурации. chmod 600 ~/.ssh/config.
• kex_exchange_identification: read: Connection reset by peer: соединение оборвалось посреди рукопожатия. На практике почти всегда это автоматическая блокировка после нескольких неудачных попыток, например силами fail2ban. Дождитесь окончания блокировки или снимите её через консоль командой fail2ban-client unban IP-АДРЕС.
• no matching host key type found. Their offer: ssh-rsa: сервер предлагает только RSA-ключи с подписью SHA-1. Начиная с OpenSSH 8.8 такие ключи отклоняются, и это касается всех четырёх рассматриваемых здесь систем в роли клиента. Правильный ответ — обновить старый сервер, а не ослаблять клиент.
• client_loop: send disconnect: Broken pipe: сеанс заснул, и его подчистил файрвол или маршрутизатор. Впишите в ~/.ssh/config строку ServerAliveInterval 60, тогда канал остаётся тёплым.

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

Различия между Debian 13, Debian 12, Ubuntu 24.04 и 22.04

Для самого подключения все четыре системы ведут себя одинаково. Как только вы начинаете что-то менять на сервере, они расходятся.

Активация через сокет вместо постоянной службы

Ubuntu, начиная с версии 22.10, запускает службу SSH не постоянно, а только при первом входящем подключении. Отвечает за это ssh.socket, а не ssh.service. Это относится к Ubuntu 24.04 и, на свежеустановленных системах, также к Debian 13. Debian 12 использует ещё классическую постоянную службу.

Отсюда два следствия. Во-первых, строка Port 2222 в /etc/ssh/sshd_config там вообще ничего не меняет, потому что порт слушает уже не sshd, а systemd. Порт в этом случае прописывается в дополнительный файл, который создаётся командой systemctl edit ssh.socket, со строкой ListenStream= для сброса значения по умолчанию и второй строкой ListenStream=2222. Во-вторых, systemctl reload ssh на свежеустановленных системах Debian 13 может прерваться с сообщением fatal: Cannot bind any address. В этом случае используйте systemctl restart ssh.service или полностью отключите активацию через сокет командой systemctl disable --now ssh.socket.

Алгоритмы и наследие прошлого

Debian 13 поставляется с OpenSSH 10.0 и вообще больше не знает ключей DSA, в том числе через переключатели совместимости. У кого ещё в работе древний ключ, тому стоит заранее создать новый. Совсем свежие клиенты (macOS 26.3 и новее с OpenSSH 10.1 или выше) дополнительно показывают уведомление, если сервер не предлагает постквантовый обмен ключами:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.

Это предупреждение, а не ошибка, соединение всё равно устанавливается. Оно исчезает, как только сервер становится достаточно новым. Debian 12 и Ubuntu 24.04 требование выполняют, Ubuntu 22.04 с OpenSSH 8.9 в стандартной конфигурации нет.

Пара слов о старых версиях

Debian 10 остался без поддержки с июня 2024 года, Ubuntu 20.04 с мая 2025 года. Ни та, ни другая система больше не получают обновлений безопасности для OpenSSH. Сервер, доступный по SSH из интернета, на них стоять уже не должен.

Меньше набирать с помощью ~/.ssh/config

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

mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/config
chmod 600 ~/.ssh/config

Запись в нём выглядит так:

Host web1
    HostName 203.0.113.10
    User root
    Port 2222
    ServerAliveInterval 60

После этого достаточно ssh web1, и scp файл web1:/root/ тоже работает. Тот же файл понимает и клиент под Windows, там он лежит в %USERPROFILE%\.ssh\config.

Действительно ли ваш блок срабатывает, гадать не нужно. ssh -G показывает итоговую конфигурацию, не устанавливая соединения:

ssh -G localhost

Замените localhost на своё короткое имя, и в строках hostname, user и port вы чёрным по белому увидите, что SSH сейчас использует. Опечатка в имени Host обнаруживается так за две секунды, а не через двадцать минут поисков.

Как понять, что всё действительно получилось

Появившееся приглашение командной строки ещё не доказательство. При нескольких открытых окнах не один администратор уже выполнял rm не на том сервере. Ясность вносят четыре короткие команды:

hostname
id
cat /etc/os-release
uptime

hostname должен показать имя вашего сервера, а не имя ноутбука. id показывает uid=0(root), если вы работаете под root. cat /etc/os-release называет дистрибутив и версию, например Debian GNU/Linux 13 (trixie) или Ubuntu 24.04.3 LTS. А uptime соответствует времени работы сервера, а не рабочей станции, которую выключают каждый вечер.

Самая быстрая проверка того, что вы действительно сидите по SSH, а не в локальном терминале:

echo $SSH_CONNECTION

Если появляется строка с четырьмя значениями (ваш IP, ваш исходный порт, IP сервера, целевой порт), вы вошли по SSH. Если она пустая, вы набираете команды на собственном компьютере. Сеанс завершается командой exit или сочетанием клавиш Ctrl и D.

Что дальше

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

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