SSH из командной строки: подключение к серверу из cmd, PowerShell и терминала

Чтобы подключиться к серверу по SSH из командной строки, достаточно одной команды ssh пользователь@адрес — она одинаково работает в cmd и PowerShell (Windows 10 и 11), в терминале Linux и macOS. Если сервер слушает не 22-й порт, добавляется ключ -p: ssh -p 2222 пользователь@адрес. Ниже — вход по паролю, настройка входа по ключу (ssh-keygen, ssh-copy-id), короткий псевдоним в ~/.ssh/config и разбор ошибок по тексту сообщения.

Вывод команд в статье получен 24.09.2026 (проверка прав и входа по ключу — повторно 25.09.2026) на стенде из двух машин: клиент и сервер на Ubuntu 24.04 с OpenSSH 9.6p1, адрес сервера 203.0.113.10 (учебный диапазон, для реального сервера подставляется свой). В Windows клиент тот же OpenSSH, но его версия и отдельные сообщения могут отличаться.

Клиент и сервер: кто что делает

SSH устроен по клиент-серверной модели: на вашем компьютере работает клиент (программа ssh), на удаленной машине — сервер (служба sshd), которая принимает подключения, проверяет пользователя и запускает для него командную оболочку. Четыре понятия, которые чаще всего путают:

Что	Где живет	Зачем
Клиент ssh	Ваш компьютер	Устанавливает соединение, запрашивает пароль или использует ключ
Сервер sshd	Удаленная машина	Слушает порт (обычно 22), проверяет вход
Хост-ключ сервера	Сервер, отпечаток — у вас в known_hosts	Доказывает клиенту, что это тот же сервер, а не подмена
Ключ пользователя	Приватный — у вас, публичный — на сервере в authorized_keys	Доказывает серверу, что входите именно вы

Хост-ключ и ключ пользователя — разные пары ключей с противоположными ролями: по первому клиент убеждается, что перед ним нужный сервер, по второму сервер убеждается, что входите вы. Подробнее о самом протоколе, этапах соединения и защите сервера — в статье Протокол SSH: как работает, порт 22 и защита сервера; здесь — практика подключения со стороны клиента.

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

От хостинга или администратора нужны четыре вещи: IP-адрес или доменное имя сервера, логин, порт (если не 22) и способ входа — пароль или разрешение добавить свой ключ. Со стороны сервера должна работать служба SSH и быть открыт порт. Проверить это можно в веб-консоли провайдера (она работает без SSH):

sudo ss -tlnp | grep ':22 '
sudo ufw status

Первая команда показывает, слушает ли кто-то 22-й порт. Имя службы зависит от дистрибутива: в Ubuntu и Debian это ssh (systemctl status ssh), в RHEL, Fedora и их производных — sshd. Если фаервол ufw включен и 22-й порт в нем не разрешен, откройте только его: sudo ufw allow 22/tcp. Отключать фаервол целиком (ufw disable) для подключения не нужно — это снимает защиту со всех остальных портов.

Шаг 1. Проверить клиент ssh

В Linux и macOS клиент уже есть. В Windows 10 и 11 клиент OpenSSH обычно установлен как дополнительный компонент. Проверка одинакова для cmd, PowerShell и терминала:

ssh -V

Если в Windows команда не найдена, клиент ставится через «Параметры» -> «Дополнительные компоненты» -> «Клиент OpenSSH» или из PowerShell, запущенного от имени администратора:

Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH.Client*'
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

PuTTY для подключения больше не обязателен: он нужен, если хочется графический интерфейс с сохраненными профилями. Учтите, что PuTTY хранит ключи в своем формате .ppk; чтобы использовать ключ OpenSSH, его конвертируют в PuTTYgen.

Шаг 2. Подключиться по паролю

Минимальная команда и ее вариант с портом:

ssh exampleuser@203.0.113.10
ssh -p 2222 exampleuser@203.0.113.10

При первом подключении клиент не знает хост-ключ сервера и спрашивает, доверять ли ему. Реальный вывод со стенда:

The authenticity of host '203.0.113.10 (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:DUaa9m8elCwBzfRctnVsePOhZEU0aLXC60f6R2aZcOY.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '203.0.113.10' (ED25519) to the list of known hosts.
exampleuser@203.0.113.10's password:
exampleuser@server:~$ whoami; hostname
exampleuser
server

Отвечать yes вслепую — слабое место: именно на этом шаге можно не заметить подмену сервера. Надежнее сравнить отпечаток: в консоли провайдера выполнить ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub. На стенде команда вернула SHA256:DUaa9m8elCwBzfRctnVsePOhZEU0aLXC60f6R2aZcOY — то же значение, что в вопросе клиента, значит, подключение идет к нужной машине.

Пароль при вводе не отображается совсем, даже звездочками — это нормально. Приглашение exampleuser@server:~$ означает, что дальнейшие команды выполняются на сервере. Выход — exit или Ctrl+D.

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

ssh exampleuser@203.0.113.10 "uname -srm"

Linux 6.8.0-117-generic aarch64

Шаг 3. Настроить вход по ключу

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

Создать ключ. Команда одинакова в cmd, PowerShell и терминале:

ssh-keygen -t ed25519 -C "student@laptop"

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/student/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/student/.ssh/id_ed25519
Your public key has been saved in /home/student/.ssh/id_ed25519.pub

Вывод сокращен: дальше клиент печатает отпечаток ключа и картинку randomart. На вопрос о пути достаточно нажать Enter. Если ключ id_ed25519 у вас уже есть, ssh-keygen спросит Overwrite (y/n)? — отвечайте n: перезапись уничтожит старый приватный ключ, и вы потеряете вход на все серверы, где лежит его публичная часть. Второй ключ создают под другим именем: ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_work. В Windows ключи по умолчанию лягут в C:\Users\<имя>\.ssh\. Passphrase (фразу-пароль к ключу) стоит задать: без нее украденный с ноутбука файл id_ed25519 сразу дает доступ к серверу. Файл .pub — публичный, его можно передавать; файл без расширения — приватный, его не отправляют никому.

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

Точка 1. Добавить публичный ключ. В Linux и macOS это делает ssh-copy-id: утилита один раз спросит пароль сервера и допишет ключ в ~/.ssh/authorized_keys нужного пользователя.

ssh-copy-id -i ~/.ssh/id_ed25519.pub exampleuser@203.0.113.10

/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
exampleuser@203.0.113.10's password:

Number of key(s) added: 1

Вывод сокращен до значимых строк. ssh-copy-id сам не добавляет ключ повторно, если он уже есть на сервере.

В Windows-сборку OpenSSH утилита ssh-copy-id не входит, поэтому ключ передают по SSH вручную. Команда для cmd, если сервер на Linux:

type %USERPROFILE%\.ssh\id_ed25519.pub | ssh exampleuser@203.0.113.10 "umask 077; mkdir -p ~/.ssh && touch ~/.ssh/authorized_keys && t=$(mktemp) && cat > $t && (grep -qxFf $t ~/.ssh/authorized_keys || (tail -c1 ~/.ssh/authorized_keys | grep -q . && echo; cat $t) >> ~/.ssh/authorized_keys); rm -f $t"

Откат: команда только дописывает одну строку в конец authorized_keys и ничего не удаляет. Чтобы отменить, удалите эту строку (она заканчивается комментарием ключа, в примере student@laptop) в редакторе на сервере, например nano ~/.ssh/authorized_keys, из уже открытой сессии.

Что делает удаленная часть в кавычках. Если ~/.ssh или authorized_keys еще нет, она их создает, и благодаря umask 077 новые объекты получают права только для владельца. Права уже существующих каталога и файла umask не меняет, поэтому точка 2 обязательна. Ключ сначала сохраняется во временный файл, и grep -qxFf проверяет, нет ли в authorized_keys точно такой же строки: ключ дописывается, только если ее нет. Без этой проверки каждый повтор команды добавлял бы тот же ключ еще раз — на стенде вариант с простым cat >> после двух запусков оставил в файле две одинаковые строки.

Фрагмент с tail -c1 нужен, если файл уже есть и не заканчивается переводом строки (например, его правили вручную): простой cat >> ~/.ssh/authorized_keys склеил бы новый ключ с последней строкой в одну, и сломался бы уже работавший ключ — например, ключ другого администратора. Команда сначала добавляет недостающий перевод строки.

Точка 2. Проверить владельца и права. Вход по паролю еще работает, поэтому проверка делается им же:

ssh exampleuser@203.0.113.10 "ls -ld ~/.ssh; ls -l ~/.ssh/authorized_keys"

Ожидаемый результат — владелец ваш логин, у каталога права drwx------, у файла -rw-------. Так выглядел вывод на стенде после передачи ключа на чистый сервер:

drwx------ 2 exampleuser exampleuser 4096 Sep 25 06:03 /home/exampleuser/.ssh
-rw------- 1 exampleuser exampleuser 96 Sep 25 06:03 /home/exampleuser/.ssh/authorized_keys

А так — если ~/.ssh и authorized_keys существовали заранее со слишком открытыми правами (на стенде их создали с правами 777 и 666, и та же команда передачи ключа их не исправила):

drwxrwxrwx 2 exampleuser exampleuser 4096 Sep 25 06:03 /home/exampleuser/.ssh
-rw-rw-rw- 1 exampleuser exampleuser 129 Sep 25 06:03 /home/exampleuser/.ssh/authorized_keys

С такими правами sshd при StrictModes yes (это значение по умолчанию) ключ не примет. Для своей учетной записи на Linux права исправляются так:

ssh exampleuser@203.0.113.10 "chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"

Если владелец в выводе не вы (например, каталог создавали через sudo и он принадлежит root), chmod от вашего имени не поможет: владельца исправляет администратор командой sudo chown -R exampleuser: /home/exampleuser/.ssh.

Точка 3. Проверить вход по ключу в новом окне. Откройте второе окно терминала, первое не закрывайте:

ssh -o PreferredAuthentications=publickey exampleuser@203.0.113.10 whoami

Опция -o PreferredAuthentications=publickey запрещает клиенту переходить к паролю: если ключ не принят, будет ошибка, а не запрос пароля, который легко принять за успешный вход. При успехе клиент локально спрашивает passphrase ключа, а пароль сервера не нужен:

Enter passphrase for key '/home/student/.ssh/id_ed25519':
exampleuser

На стенде с правами 777 и 666 из точки 2 та же команда вернула exampleuser@203.0.113.10: Permission denied (publickey,password)., а в журнале sshd появилась строка Authentication refused: bad ownership or modes for file /home/exampleuser/.ssh/authorized_keys. После chmod из точки 2 вход прошел.

Чтобы не вводить passphrase при каждом подключении, ключ загружают в агент: ssh-add спросит фразу один раз за сеанс. В Linux и macOS агент обычно уже запущен; в Windows служба ssh-agent по умолчанию отключена, ее включает администратор в PowerShell: Get-Service ssh-agent | Set-Service -StartupType Automatic, затем Start-Service ssh-agent.

Когда отключать вход по паролю. Только после того, как точка 3 прошла успешно в новом окне, а первая сессия осталась открытой: иначе ошибка в настройке оставит вас без доступа, кроме консоли провайдера. Порядок отключения паролей и откат описаны в статье про протокол SSH по ссылке выше.

Шаг 4. Короткий псевдоним в ~/.ssh/config

Чтобы не набирать адрес, логин, порт и путь к ключу каждый раз, их записывают в файл ~/.ssh/config (в Windows — %USERPROFILE%\.ssh\config):

Host myserver
    HostName 203.0.113.10
    User exampleuser
    Port 2222
    IdentityFile ~/.ssh/id_ed25519

После этого подключение сокращается до ssh myserver. Проверить, какие параметры клиент реально применит, можно без подключения — командой ssh -G myserver:

user exampleuser
hostname 203.0.113.10
port 2222
identityfile ~/.ssh/id_ed25519

Если не получилось: диагностика по тексту ошибки

Первое, что стоит сделать при любой ошибке, — повторить команду с -v: клиент покажет, на каком этапе остановился (соединение, проверка хоста или вход). Все сообщения ниже получены на стенде.

Сообщение	Что это значит	Что делать
Could not resolve hostname	Имя сервера не найдено в DNS	Проверить опечатку в имени или подключиться по IP
Connection timed out	Ответа нет: неверный адрес или пакеты отбрасывает фаервол	Сверить IP, проверить фаервол и правила сети у провайдера
No route to host	Узел недоступен в сети	Проверить адрес и что сервер включен
Connection refused	Узел ответил, но на этом порту никто не слушает	Проверить порт (-p) и работает ли служба SSH
Permission denied (publickey,password)	Соединение есть, вход отклонен	Проверить логин, пароль, какой ключ предлагается (-v)
REMOTE HOST IDENTIFICATION HAS CHANGED	Хост-ключ сервера не совпал с сохраненным	Выяснить причину, только потом удалять старую запись
UNPROTECTED PRIVATE KEY FILE	Приватный ключ читают другие пользователи	Оставить права только владельцу

Смена хост-ключа. Клиент отказывается подключаться и подсказывает команду очистки:

@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
Host key for 203.0.113.10 has changed and you have requested strict checking.
Host key verification failed.

Так бывает после переустановки ОС на сервере, но так же выглядит и перехват соединения. Сначала сверьте новый отпечаток через консоль провайдера (как в шаге 2), и только если он совпадает, удалите старую запись: ssh-keygen -R 203.0.113.10. Следующее подключение снова задаст вопрос о новом ключе.

Ключ не принимается. Частая причина — владелец или права на стороне сервера: проверка и исправление описаны в точке 2 шага 3, а причину отказа sshd пишет в журнал строкой Authentication refused: bad ownership or modes. Та же ошибка бывает, если запись разрешена группе или всем для самого домашнего каталога: его права проверяют командой ls -ld ~. Журнал в Ubuntu смотрят командой sudo journalctl -u ssh.

Обратная ситуация — слишком открытый приватный ключ у клиента. На стенде при правах 644 клиент вывел Permissions 0644 for '/home/student/.ssh/id_ed25519' are too open и не стал использовать ключ. В Linux и macOS помогает chmod 600 ~/.ssh/id_ed25519; в Windows та же проверка идет по правам доступа NTFS — у файла ключа не должно быть доступа для других пользователей.

Выводы

• Подключение из cmd, PowerShell и терминала Linux/macOS делается одной командой ssh пользователь@адрес, нестандартный порт задается через -p.
• При первом подключении отпечаток хост-ключа сравнивают с выводом ssh-keygen -lf в консоли провайдера, а не отвечают yes вслепую.
• Вход по ключу: ssh-keygen на клиенте, затем ssh-copy-id в Linux/macOS или ручная передача ключа через ssh в Windows; passphrase защищает ключ при краже файла.
• После передачи ключа проверяют владельца и права ~/.ssh (700) и authorized_keys (600) — umask не исправляет уже существующие файлы, а вход по паролю отключают только после успешного входа по ключу с -o PreferredAuthentications=publickey в новой сессии, не закрывая текущую.
• Ошибки SSH читаются по тексту: refused и timed out — проблема сети или порта, Permission denied — проблема входа, HOST IDENTIFICATION HAS CHANGED — повод проверить сервер.

Где применяется / связь с практикой

FAQ

Как скопировать файл на сервер через SSH из командной строки?
Командой scp report.txt exampleuser@203.0.113.10:/tmp/ — она есть в Windows, Linux и macOS вместе с клиентом ssh и использует те же ключи и тот же ~/.ssh/config.

Можно ли подключиться по SSH к компьютеру с Windows?
Да, если на нем установлен и запущен компонент «Сервер OpenSSH». Команда подключения та же, но ключи администраторов Windows хранятся в отдельном файле, а не в authorized_keys профиля.

Почему после ssh ничего не происходит и курсор просто мигает?
Обычно клиент ждет ответа сервера, который не приходит: пакеты отбрасывает фаервол или адрес неверный. Через некоторое время появится Connection timed out; ускорить диагностику помогает ssh -v и опция -o ConnectTimeout=5.