Подключиться к серверу по SSH можно одной командой: ssh пользователь@адрес, например ssh dev@203.0.113.10. В первый раз ssh спросит, доверять ли ключу сервера, потом попросит пароль. Для постоянной работы пароль заменяют ключом: ssh-keygen создаёт пару ключей, а ssh-copy-id кладёт открытую часть на сервер. Ниже каждый шаг показан с настоящим выводом, а ошибки разобраны по шагу, на котором они случаются.
Три проверки при входе по SSH
Первое подключение по паролю
Для входа нужны адрес сервера, имя пользователя на нём и пароль. Их выдаёт хостинг или администратор. Клиент ssh входит в OpenSSH; если в Debian или Ubuntu его нет, он ставится пакетом openssh-client. Подключаемся к серверу 203.0.113.10 под пользователем dev:
ssh dev@203.0.113.10The authenticity of host '203.0.113.10 (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:vpk9orgwNVRno8E4ILAKp4kybOM5TYlvdhxt4zKjW40.
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.
dev@203.0.113.10's password:
dev@server:~$Вопрос в первых строках — проверка сервера. ssh видит его впервые и показывает отпечаток его ключа. После yes ключ записывается в ~/.ssh/known_hosts, и при следующих входах ssh сверяет его молча. Пароль при вводе не отображается: ни звёздочек, ни движения курсора. Приглашение dev@server:~$ значит, что дальше команды выполняются на сервере.
Отвечать yes вслепую не стоит. Отпечаток можно сверить с тем, что печатает сам сервер: в веб-консоли хостинга или у администратора.
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub256 SHA256:vpk9orgwNVRno8E4ILAKp4kybOM5TYlvdhxt4zKjW40 root@server (ED25519)Отпечатки совпали, значит, отвечает тот самый сервер. Закончить сеанс можно командой exit или сочетанием Ctrl+D:
exitlogout
Connection to 203.0.113.10 closed.Вход по ключу: ssh-keygen и ssh-copy-id
Ключ надёжнее пароля и избавляет от его ввода. Ключей два: закрытый остаётся на твоём компьютере, открытый кладут на сервер в файл ~/.ssh/authorized_keys. При входе сервер просит доказать, что закрытый ключ у тебя, и сам этот ключ не получает.
Пару создаёт ssh-keygen. Тип ed25519 даёт короткий ключ: открытая часть — строка меньше сотни символов. Параметр -C добавляет комментарий, чтобы на сервере было видно, чей это ключ:
ssh-keygen -t ed25519 -C "dev@laptop"Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/dev/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/dev/.ssh/id_ed25519
Your public key has been saved in /home/dev/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:YjxZo3fUxtq61V6h+oQfU0oa4AWz/pw40trS9irvdqw dev@laptopНа вопрос о файле хватит Enter. Дальше ssh-keygen просит фразу-пароль для самого ключа: если файл утечёт, без фразы им не воспользоваться. В конце программа рисует картинку из символов, randomart, — её можно не читать.
Права на новые файлы ssh-keygen выставил сам. Закрытый ключ читает и меняет только владелец, открытый читают все:
stat -c "%a %n" ~/.ssh ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.pub700 /home/dev/.ssh
600 /home/dev/.ssh/id_ed25519
644 /home/dev/.ssh/id_ed25519.pubГлавная мысль: закрытый ключ
id_ed25519никуда не копируют и никому не пересылают. На сервер уходит только открытый — файл с окончанием.pub.
Положить открытый ключ на сервер проще всего через ssh-copy-id. Он в последний раз спросит пароль и допишет ключ в ~/.ssh/authorized_keys, создав каталог и файл, если их нет:
ssh-copy-id dev@203.0.113.10/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/dev/.ssh/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/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
dev@203.0.113.10's password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'dev@203.0.113.10'"
and check to make sure that only the key(s) you wanted were added.Если ssh-copy-id нет, ту же работу сделает одна команда. Она создаёт ~/.ssh с правами 700, дописывает ключ в конец authorized_keys и закрывает файл от чужих:
cat ~/.ssh/id_ed25519.pub | ssh dev@203.0.113.10 'mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys'Теперь ssh спрашивает не пароль от сервера, а фразу от ключа:
ssh dev@203.0.113.10Enter passphrase for key '/home/dev/.ssh/id_ed25519':
Last login: Sun Oct 18 14:47:48 2026 from 203.0.113.20
dev@server:~$Чтобы не вводить фразу при каждом подключении, ключ держит в памяти ssh-agent. Фразу спросят один раз, дальше до конца сеанса терминала ssh входит без вопросов:
eval "$(ssh-agent -s)"
ssh-addAgent pid 634
Enter passphrase for /home/dev/.ssh/id_ed25519:
Identity added: /home/dev/.ssh/id_ed25519 (dev@laptop)С ключом в агенте удобно выполнять команды на сервере, не открывая сеанс. Команду пишут после адреса, ssh возвращает её вывод и закрывает соединение:
ssh dev@203.0.113.10 hostnameserverКогда вход по ключу работает, пароль на сервере лучше выключить: подбирать его станет бесполезно. Настройки сервера лежат в /etc/ssh/sshd_config. В Debian и Ubuntu он подключает ещё файлы из /etc/ssh/sshd_config.d/, туда и положи свою строку. sshd -t проверяет настройки до перезагрузки службы:
echo "PasswordAuthentication no" | sudo tee /etc/ssh/sshd_config.d/nopass.conf
sudo sshd -t && sudo systemctl reload sshsshd -T печатает настройки, с которыми сервер работает на самом деле:
sudo sshd -T | grep -E '^(passwordauthentication|port) 'port 22
passwordauthentication noНе закрывай текущий сеанс, пока не проверишь вход из второго окна терминала. Перезагрузка настроек не рвёт уже открытое соединение, а новое при ошибке в настройках не пустит. Из старого окна ошибку можно исправить.
Нестандартный порт и файл ~/.ssh/config
По умолчанию ssh подключается к порту 22. Если SSH на сервере перенесли, например на порт 2222, без параметра -p соединение упрётся в закрытый порт:
ssh dev@203.0.113.10ssh: connect to host 203.0.113.10 port 22: Connection refusedС номером порта всё работает:
ssh -p 2222 dev@203.0.113.10Enter passphrase for key '/home/dev/.ssh/id_ed25519':
Last login: Sun Oct 18 14:49:26 2026 from 203.0.113.20
dev@server:~$У scp, который копирует файлы через SSH, порт задаётся большой буквой -P. Маленькая -p там уже занята: она сохраняет даты и права файла.
scp -P 2222 report.txt dev@203.0.113.10:/tmp/report.txt 100% 10 49.8KB/s 00:00Чтобы не набирать адрес, пользователя и порт каждый раз, опиши сервер в ~/.ssh/config. Писать в этот файл должен только ты, поэтому после создания выполни chmod 600 ~/.ssh/config:
Host myserver
HostName 203.0.113.10
User dev
Port 2222
IdentityFile ~/.ssh/id_ed25519Теперь хватает имени из строки Host, и оно работает во всех командах OpenSSH:
ssh myserver hostname
scp report.txt myserver:server
report.txt 100% 10 46.5KB/s 00:00Какие настройки применятся к серверу, показывает ssh -G. Он печатает итог разбора конфигурации и не подключается:
ssh -G myserver | grep -E '^(user|hostname|port|identityfile) 'user dev
hostname 203.0.113.10
port 2222
identityfile ~/.ssh/id_ed25519Ошибки, на которых спотыкаются
По тексту ошибки видно, на каком шаге со схемы выше остановился вход.
Connection refused. Сервер ответил, но на этом порту никто не слушает: sshd не запущен или работает на другом порту. Узнай номер порта у хостинга. Если на сервер можно попасть через веб-консоль, посмотри, какой порт ждёт подключений:
sudo ss -ltnp | grep -E 'sshd|systemd'LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1350,fd=4))
LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=1350,fd=5))Номер после двоеточия — порт. В Ubuntu 24.04 порт держит сам systemd через ssh.socket и запускает sshd при первом подключении, поэтому там в строке может стоять systemd. Пустой вывод значит, что подключений никто не ждёт: запусти службу командой sudo systemctl start ssh.
Connection timed out. Ответа нет совсем: адрес неверный, сервер выключен или файрвол молча отбрасывает пакеты. ssh ждёт до таймаута, а -o ConnectTimeout=5 сокращает ожидание до пяти секунд:
ssh -o ConnectTimeout=5 dev@192.0.2.10ssh: connect to host 192.0.2.10 port 22: Connection timed outПохожая ошибка No route to host значит, что до адреса нет пути: машины с ним нет в сети или маршрутизатор сообщает, что она недоступна.
ssh -o ConnectTimeout=5 dev@203.0.113.99ssh: connect to host 203.0.113.99 port 22: No route to hostCould not resolve hostname. Имя сервера не нашлось в DNS: в нём опечатка или домен ещё не направлен на сервер. Проверь написание или подключись по IP-адресу. Как имя превращается в адрес, разобрано в материале о DNS.
ssh dev@sreverssh: Could not resolve hostname srever: Name or service not knownHost key verification failed. Сервер показал ключ, который не совпадает с записанным в known_hosts, и ssh отказался подключаться:
ssh dev@203.0.113.10@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:bY41Hg51MI54x0KHljewFZ8W/Ll3hxz7elG/8Z9x7DU.
Please contact your system administrator.
Add correct host key in /home/dev/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/dev/.ssh/known_hosts:3
remove with:
ssh-keygen -f "/home/dev/.ssh/known_hosts" -R "203.0.113.10"
Host key for 203.0.113.10 has changed and you have requested strict checking.
Host key verification failed.Если сервер переустанавливали или адрес перешёл к другой машине, так и должно быть. Удали старую запись и подключись заново, сверив новый отпечаток:
ssh-keygen -R 203.0.113.10# Host 203.0.113.10 found: line 1
# Host 203.0.113.10 found: line 2
# Host 203.0.113.10 found: line 3
/home/dev/.ssh/known_hosts updated.
Original contents retained as /home/dev/.ssh/known_hosts.oldЗаписей три, потому что после входа сервер сообщает клиенту ключи всех своих типов, и OpenSSH их запоминает. Если же на сервере ничего не менялось, не подключайся и спроси администратора: так выглядит и подмена сервера, о которой предупреждает сообщение.
Permission denied (publickey). Сервер не принял ни одного ключа, а вход по паролю у него выключен. Частая причина — не тот пользователь. Если не написать его перед @, ssh подставит имя, под которым ты работаешь локально. Здесь команду запустили от root:
ssh 203.0.113.10root@203.0.113.10: Permission denied (publickey).Какие ключи предлагает клиент и что отвечает сервер, видно с параметром -v:
ssh -v root@203.0.113.10 2>&1 | grep -E 'Authentications|Offering|No more|denied|Server accepts'debug1: Authentications that can continue: publickey
debug1: Offering public key: /home/dev/.ssh/id_ed25519 ED25519 SHA256:YjxZo3fUxtq61V6h+oQfU0oa4AWz/pw40trS9irvdqw agent
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
root@203.0.113.10: Permission denied (publickey).Клиент предложил ключ, сервер отказал: в authorized_keys у root этого ключа нет. Для пользователя dev тот же ключ проходит, и в выводе появляется строка Server accepts key.
Закрытый ключ доступен другим. ssh не берёт ключ, который могут прочитать другие пользователи, и продолжает без него:
chmod 644 ~/.ssh/id_ed25519
ssh dev@203.0.113.10@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/dev/.ssh/id_ed25519' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/home/dev/.ssh/id_ed25519": bad permissions
dev@203.0.113.10: Permission denied (publickey).Верни права командой chmod 600 ~/.ssh/id_ed25519. Что значат 600 и 644, разобрано в материале о правах доступа.
Сервер молча не принимает ключ. Клиент видит тот же Permission denied (publickey), а причина на сервере: ~/.ssh или домашний каталог открыты на запись другим. С настройкой StrictModes yes, а она включена по умолчанию, sshd такой ключ не принимает. Ответ ищи в журнале sshd на сервере, в Debian и Ubuntu это sudo journalctl -u ssh:
Authentication refused: bad ownership or modes for directory /home/dev/.ssh
Connection closed by authenticating user dev 203.0.113.20 port 54580 [preauth]Чинят права: chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys и chmod go-w ~ на сервере.
Пароль не подходит. После трёх неверных паролей ssh сдаётся. В скобках последней строки перечислены способы входа, которые сервер принимает:
dev@203.0.113.10's password:
Permission denied, please try again.
dev@203.0.113.10's password:
Permission denied, please try again.
dev@203.0.113.10's password:
dev@203.0.113.10: Permission denied (publickey,password).Пароль вводится вслепую, поэтому сначала проверь раскладку и Caps Lock.
Порт для scp указали маленькой -p. scp принял 2222 за имя файла и пошёл на порт 22:
scp -p 2222 report.txt dev@203.0.113.10:ssh: connect to host 203.0.113.10 port 22: Connection refused
scp: Connection closedЧастые вопросы
Как выйти из зависшей SSH-сессии
Если сервер перестал отвечать и терминал не реагирует даже на Ctrl+C, нажми по очереди Enter, ~ и .. Эту команду выполняет сам клиент ssh: он обрывает соединение и возвращает тебя в свой терминал.
Connection to 203.0.113.10 closed.Тильда срабатывает только в начале строки, поэтому сначала Enter.
Почему сессия обрывается, если долго ничего не делать
Соединение без трафика обычно рвёт роутер или файрвол по дороге: они забывают соединения, по которым давно ничего не шло. ssh может сам проверять связь. Добавь в ~/.ssh/config блок для всех серверов:
Host *
ServerAliveInterval 60По умолчанию ssh таких проверок не делает. С этой строкой он после 60 секунд тишины отправляет серверу запрос, а после трёх запросов без ответа закрывает сеанс сам:
ssh -G myserver | grep -E '^serveralive'serveralivecountmax 3
serveraliveinterval 60Как скопировать файл с сервера
Поменяй местами источник и цель: сначала путь на сервере, потом локальный каталог. Для целого каталога добавь -r.
scp dev@203.0.113.10:report.txt /tmp/report.txt 100% 10 33.1KB/s 00:00Можно ли оставить ключ без фразы-пароля
Можно: на вопрос о фразе ssh-keygen примет пустой ответ. Но тогда любой, кто скопирует файл id_ed25519, войдёт на все серверы, где лежит твой открытый ключ. С фразой и ssh-agent её всё равно вводишь один раз за сеанс.
Где потренироваться
SSH — одна из тем карты навыков DevOps, рядом с правами, процессами и сетью. Проверить себя по Linux можно в тесте навыков: 8 вопросов, баллы видны без регистрации. Когда вход на сервер настроен, следующий шаг — расписание задач в crontab. Как завести на сервере отдельного пользователя и выдать ему sudo, разобрано в материале о пользователях и группах.