SSH

SSH (Secure Shell) — защищённый сетевой протокол для удалённого доступа к командной строке, выполнения команд, передачи файлов и создания зашифрованных туннелей.

Руководство ориентировано на OpenSSH в Linux и macOS. Большинство клиентских команд также работает во встроенном OpenSSH для Windows.

Содержание

• Как работает SSH
• Подключение к серверу
• Проверка ключа сервера
• SSH-ключи
• Создание ключей через ssh-keygen
• Установка публичного ключа на сервер
• Аутентификация по ключу и паролю
• ssh-agent
• SSH config
• Port forwarding
• Передача файлов через scp
• SFTP
• Базовая безопасность SSH-сервера
• Ограничение ключей в authorized_keys
• Устранение неполадок
• Шпаргалка

Как работает SSH

Обычное SSH-соединение включает несколько этапов:

1. клиент подключается к TCP-порту SSH-сервера, по умолчанию 22;
2. клиент и сервер согласуют алгоритмы шифрования;
3. сервер подтверждает свою подлинность ключом хоста;
4. создаётся зашифрованный канал;
5. пользователь проходит аутентификацию;
6. внутри защищённого канала открывается терминал, выполняется команда или передаются файлы.

Упрощённая схема:

SSH-клиент
    │
    │ TCP-соединение и зашифрованный канал
    ▼
SSH-сервер
    │
    ├── интерактивная оболочка
    ├── выполнение команды
    ├── SFTP
    └── перенаправление портов

Современные версии OpenSSH используют SSH Protocol 2. Устаревший SSH Protocol 1 применять нельзя.

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

• ключ хоста идентифицирует сервер;
• ключ пользователя используется для входа пользователя на сервер.

Приватный ключ пользователя при подключении не передаётся. Клиент доказывает владение им с помощью криптографической подписи.

Подключение к серверу

Основной синтаксис:

ssh USER@HOST

Пример:

ssh alice@example.com

Подключение к нестандартному порту:

ssh -p 2222 alice@example.com

Подключение по IP-адресу:

ssh alice@192.168.1.50

Выполнение одной команды без открытия интерактивной оболочки:

ssh alice@example.com 'uname -a'

Несколько команд:

ssh alice@example.com 'cd /var/log && tail -n 50 syslog'

Передача локальной переменной в удалённую команду требует осторожного экранирования:

ssh alice@example.com "echo '$USER'"

В этом примере $USER раскрывается локальной оболочкой. Чтобы раскрыть переменную на сервере:

ssh alice@example.com 'echo "$USER"'

Полезные параметры

Подключение с конкретным ключом:

ssh -i ~/.ssh/id_ed25519_work alice@example.com

Запуск интерактивной команды, которой нужен терминал:

ssh -t alice@example.com 'sudo systemctl status nginx'

Проверка ключа сервера

При первом подключении OpenSSH показывает отпечаток ключа сервера:

The authenticity of host 'example.com' can't be established.
ED25519 key fingerprint is SHA256:...
Are you sure you want to continue connecting (yes/no/[fingerprint])?

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

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

После подтверждения ключ сохраняется в:

~/.ssh/known_hosts

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

Предупреждение:

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

может появиться после переустановки сервера, изменения ключей или подключения к другому серверу по тому же адресу. Оно также может указывать на перехват соединения. Не удаляйте старую запись, пока не проверите новый отпечаток.

После проверки удалить устаревшую запись можно так:

ssh-keygen -R example.com

Для нестандартного порта:

ssh-keygen -R '[example.com]:2222'

SSH-ключи

Пара SSH-ключей состоит из двух файлов:

~/.ssh/id_ed25519       приватный ключ
~/.ssh/id_ed25519.pub   публичный ключ

Приватный ключ:

• остаётся на клиентском компьютере;
• не должен передаваться другим людям;
• желательно защищать парольной фразой;
• должен храниться с ограниченными правами доступа.

Публичный ключ:

• можно копировать на серверы;
• хранится на сервере в ~/.ssh/authorized_keys;
• сам по себе не позволяет восстановить приватный ключ.

Парольная фраза ключа и пароль пользователя — разные вещи:

• пароль пользователя проверяет SSH-сервер;
• парольная фраза защищает файл приватного ключа на клиентском компьютере.

Создание ключей через ssh-keygen

Рекомендуемый ключ Ed25519

ssh-keygen -t ed25519 -a 100 -C "alice@example.com"

Параметры:

По умолчанию будут созданы файлы:

~/.ssh/id_ed25519
~/.ssh/id_ed25519.pub

Рекомендуется задать парольную фразу. Она защищает приватный ключ при копировании или краже файла.

Отдельный ключ для конкретного назначения

ssh-keygen -t ed25519 -a 100 \
  -f ~/.ssh/id_ed25519_work \
  -C "alice work key"

Будут созданы:

~/.ssh/id_ed25519_work
~/.ssh/id_ed25519_work.pub

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

RSA для совместимости

Если сервер не поддерживает Ed25519:

ssh-keygen -t rsa -b 4096 -a 100 -C "alice@example.com"

Для новых систем предпочтительнее Ed25519. Ключи DSA использовать не следует.

Просмотр публичного ключа

cat ~/.ssh/id_ed25519.pub

Публичный ключ выглядит примерно так:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... alice@example.com

Просмотр отпечатка ключа

ssh-keygen -lf ~/.ssh/id_ed25519.pub

Отпечаток в другом формате:

ssh-keygen -E sha256 -lf ~/.ssh/id_ed25519.pub

Изменение парольной фразы

ssh-keygen -p -f ~/.ssh/id_ed25519

Восстановление публичного ключа из приватного

Если файл .pub потерян:

ssh-keygen -y -f ~/.ssh/id_ed25519 > ~/.ssh/id_ed25519.pub

Права доступа

Рекомендуемые права:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/config

Приватный ключ не должен быть доступен другим пользователям.

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

Через ssh-copy-id

Самый простой вариант:

ssh-copy-id alice@example.com

Установка конкретного ключа:

ssh-copy-id -i ~/.ssh/id_ed25519_work.pub alice@example.com

Для нестандартного порта:

ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 2222 alice@example.com

После установки проверьте подключение:

ssh alice@example.com

Вручную

Если ssh-copy-id отсутствует:

cat ~/.ssh/id_ed25519.pub |
  ssh alice@example.com 'umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys'

Либо скопируйте содержимое .pub в файл на сервере:

~/.ssh/authorized_keys

Каждый публичный ключ должен находиться на отдельной строке.

Права на сервере:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Домашний каталог и каталог .ssh не должны быть доступны для записи посторонним пользователям.

Удаление доступа

Чтобы отозвать ключ, удалите соответствующую строку из:

~/.ssh/authorized_keys

Перед удалением удобно посмотреть ключи с номерами строк:

nl -ba ~/.ssh/authorized_keys

Аутентификация по ключу и паролю

Парольная аутентификация

При парольной аутентификации сервер проверяет пароль учётной записи.

Преимущества:

• не нужно заранее устанавливать ключ;
• удобно для первоначальной настройки;
• поддерживается практически везде.

Недостатки:

• пароль можно подобрать;
• возможны атаки на повторно используемые пароли;
• пароль приходится вводить при каждом подключении;
• менее удобно для безопасной автоматизации.

Пароль передаётся внутри зашифрованного SSH-канала, а не открытым текстом. Основная проблема заключается не в передаче, а в подборе, краже или повторном использовании пароля.

Аутентификация по ключу

При аутентификации по ключу сервер хранит публичный ключ, а клиент доказывает владение приватным ключом.

Преимущества:

• высокая стойкость к перебору;
• приватный ключ не передаётся серверу;
• удобно использовать с ssh-agent;
• подходит для автоматизации;
• доступ можно отозвать удалением публичного ключа.

Недостатки:

• ключи нужно создавать, устанавливать и учитывать;
• украденный незащищённый приватный ключ можно использовать;
• потеря приватного ключа без резервного способа доступа может заблокировать вход.

Рекомендуемый вариант:

1. создать отдельный ключ Ed25519;
2. защитить приватный ключ парольной фразой;
3. установить публичный ключ на сервер;
4. проверить вход по ключу;
5. только после проверки отключить парольную аутентификацию.

ssh-agent

ssh-agent хранит расшифрованные приватные ключи в памяти. Благодаря этому парольную фразу не приходится вводить при каждом подключении.

Запуск агента

Во многих графических окружениях агент запускается автоматически. Вручную его можно запустить так:

eval "$(ssh-agent -s)"

Пример результата:

Agent pid 12345

Проверить наличие агента:

printf '%s\n' "$SSH_AUTH_SOCK"

Добавление ключа

ssh-add ~/.ssh/id_ed25519

Добавление рабочего ключа:

ssh-add ~/.ssh/id_ed25519_work

После ввода парольной фразы агент сохранит ключ в памяти.

Добавление ключа на ограниченное время

Например, на один час:

ssh-add -t 1h ~/.ssh/id_ed25519

На десять минут:

ssh-add -t 10m ~/.ssh/id_ed25519

Просмотр загруженных ключей

ssh-add -l

Просмотр публичных частей:

ssh-add -L

Удаление ключа

ssh-add -d ~/.ssh/id_ed25519

Удаление всех ключей из агента:

ssh-add -D

Добавление ключа в macOS Keychain

В современных версиях OpenSSH для macOS:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

В конфигурации можно указать:

Host *
    AddKeysToAgent yes
    UseKeychain yes

Параметр UseKeychain специфичен для поставляемого Apple клиента OpenSSH и может не поддерживаться в других системах.

Agent forwarding

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

ssh -A alice@gateway.example.com

Приватный ключ при этом не копируется на промежуточный сервер. Однако процесс с достаточными правами на таком сервере потенциально может использовать подключённый агент, пока соединение активно.

Вместо ssh -A по возможности используйте ProxyJump:

ssh -J alice@gateway.example.com bob@internal.example.com

SSH config

Пользовательский конфигурационный файл:

~/.ssh/config

Системный файл:

/etc/ssh/ssh_config

Создание пользовательского файла:

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

Простой пример

Host production
    HostName server.example.com
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_production
    IdentitiesOnly yes

После этого вместо длинной команды:

ssh -p 2222 -i ~/.ssh/id_ed25519_production deploy@server.example.com

можно использовать:

ssh production

Псевдоним работает и в других OpenSSH-командах:

scp report.txt production:/tmp/
sftp production

Основные параметры

Несколько серверов

Host dev
    HostName dev.example.com
    User alice
    IdentityFile ~/.ssh/id_ed25519_work
    IdentitiesOnly yes

Host production
    HostName production.example.com
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_production
    IdentitiesOnly yes

Host backup
    HostName 192.168.10.20
    User backup
    IdentityFile ~/.ssh/id_ed25519_backup
    IdentitiesOnly yes

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3
    AddKeysToAgent yes

OpenSSH обычно использует первое полученное значение параметра. Поэтому специфичные блоки рекомендуется размещать выше общих правил Host *.

Шаблоны

Настройки для всех серверов домена:

Host *.example.com
    User alice
    IdentityFile ~/.ssh/id_ed25519_work

Исключение из шаблона:

Host *.example.com !public.example.com
    User alice

Подключение через промежуточный сервер

Host gateway
    HostName gateway.example.com
    User alice
    IdentityFile ~/.ssh/id_ed25519_work

Host internal
    HostName 10.20.0.15
    User admin
    ProxyJump gateway
    IdentityFile ~/.ssh/id_ed25519_internal

Подключение:

ssh internal

Эквивалентная команда:

ssh -J alice@gateway.example.com admin@10.20.0.15

Просмотр итоговой конфигурации

ssh -G production

Найти отдельные параметры:

ssh -G production | grep -E '^(hostname|user|port|identityfile) '

Port forwarding

SSH может передавать произвольные TCP-соединения через зашифрованный канал.

Основные виды:

Для туннелей обычно используются параметры:

-N    не запускать удалённую команду
-T    не выделять терминал

Local forwarding

Синтаксис:

ssh -N -L LOCAL_ADDRESS:LOCAL_PORT:TARGET_HOST:TARGET_PORT USER@SSH_SERVER

Пример:

ssh -N \
  -L 127.0.0.1:15432:db.internal:5432 \
  alice@gateway.example.com

Схема:

localhost:15432
       │
       │ SSH-туннель
       ▼
gateway.example.com
       │
       ▼
db.internal:5432

Теперь локальная программа может подключиться к:

127.0.0.1:15432

Например:

psql -h 127.0.0.1 -p 15432

Адрес db.internal разрешается и открывается со стороны SSH-сервера, а не локального компьютера.

Если сервис работает непосредственно на SSH-сервере:

ssh -N -L 127.0.0.1:8080:127.0.0.1:80 alice@example.com

Локальный адрес сервиса:

http://127.0.0.1:8080

Remote forwarding

Синтаксис:

ssh -N -R REMOTE_ADDRESS:REMOTE_PORT:LOCAL_HOST:LOCAL_PORT USER@SSH_SERVER

Пример:

ssh -N \
  -R 127.0.0.1:9000:127.0.0.1:3000 \
  alice@example.com

После этого порт 9000 на удалённом сервере перенаправляется на локальный сервис:

локальная машина:3000
        ▲
        │ SSH-туннель
        │
удалённый сервер:9000

На удалённом сервере:

curl http://127.0.0.1:9000

Для открытия удалённого порта на всех интерфейсах может потребоваться:

GatewayPorts yes

в серверном /etc/ssh/sshd_config. Это делает порт доступным из сети и требует осторожности, а также настройки межсетевого экрана.

Без необходимости привязывайте удалённый порт к 127.0.0.1.

Dynamic forwarding

Создание локального SOCKS5-прокси:

ssh -N -D 127.0.0.1:1080 alice@example.com

После этого приложения можно настроить на SOCKS5-прокси:

127.0.0.1:1080

Проверка через curl:

curl --proxy socks5h://127.0.0.1:1080 https://example.com

Вариант socks5h передаёт разрешение доменного имени через прокси и уменьшает риск локальной утечки DNS-запроса.

Не привязывайте SOCKS-прокси к 0.0.0.0, если не хотите сделать его доступным другим устройствам.

Проверка успешного создания туннеля

ssh -o ExitOnForwardFailure=yes \
  -N -L 127.0.0.1:8080:127.0.0.1:80 \
  alice@example.com

Если порт невозможно открыть, SSH сразу завершится с ошибкой.

Запуск туннеля в фоне

ssh -fN \
  -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:8080:127.0.0.1:80 \
  alice@example.com

Параметр -f переводит клиент в фон после аутентификации.

Туннели в SSH config

Host database-tunnel
    HostName gateway.example.com
    User alice
    IdentityFile ~/.ssh/id_ed25519_work
    LocalForward 127.0.0.1:15432 db.internal:5432
    ExitOnForwardFailure yes

Запуск:

ssh -N database-tunnel

Динамический прокси:

Host socks-proxy
    HostName server.example.com
    User alice
    DynamicForward 127.0.0.1:1080
    ExitOnForwardFailure yes

Запуск:

ssh -N socks-proxy

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

scp копирует файлы через SSH. В современных версиях OpenSSH команда scp по умолчанию использует протокол SFTP, сохраняя привычный синтаксис.

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

scp report.txt alice@example.com:/home/alice/

Через псевдоним из ~/.ssh/config:

scp report.txt production:/tmp/

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

scp alice@example.com:/var/log/app.log .

Копирование под другим именем:

scp alice@example.com:/var/log/app.log ./production-app.log

Копирование каталога

scp -r project/ alice@example.com:/home/alice/

Получение каталога:

scp -r alice@example.com:/var/www/site/ ./site-backup/

Нестандартный порт

Для scp порт задаётся заглавным -P:

scp -P 2222 report.txt alice@example.com:/tmp/

Не путайте:

-P PORT    порт SSH-сервера
-p         сохранить время изменения и режим файла

Конкретный ключ

scp -i ~/.ssh/id_ed25519_work report.txt alice@example.com:/tmp/

Ограничение скорости

Ограничение задаётся в килобитах в секунду:

scp -l 8000 large-file.iso alice@example.com:/tmp/

Сохранение атрибутов

scp -p report.txt alice@example.com:/tmp/

Принудительное использование старого SCP-протокола

Для совместимости с устаревшим сервером:

scp -O file.txt alice@legacy.example.com:/tmp/

Старый SCP-протокол имеет больше особенностей с обработкой удалённых путей. Используйте -O только при необходимости.

SFTP

SFTP — протокол передачи и управления файлами поверх SSH. Несмотря на название, он не связан с обычным FTP и не требует отдельного FTP-сервера.

Подключение:

sftp alice@example.com

Нестандартный порт:

sftp -P 2222 alice@example.com

Конкретный ключ:

sftp -i ~/.ssh/id_ed25519_work alice@example.com

Псевдоним из SSH config:

sftp production

Основные команды SFTP

Пример интерактивной работы:

sftp> lcd ~/Downloads
sftp> cd /var/tmp
sftp> put archive.tar.gz
sftp> ls -la
sftp> exit

Копирование каталога

Загрузка:

sftp> put -r project

Скачивание:

sftp> get -r backups

Пакетный режим

Файл sftp-commands.txt:

cd /srv/backups
put backup.tar.gz
ls -l
exit

Выполнение:

sftp -b sftp-commands.txt backup@example.com

Одноразовый пакет без отдельного файла:

printf '%s\n' \
  'cd /srv/backups' \
  'put backup.tar.gz' \
  'exit' |
  sftp backup@example.com

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

Базовая безопасность SSH-сервера

Конфигурация сервера обычно находится в:

/etc/ssh/sshd_config

Дополнительные фрагменты конфигурации могут находиться в:

/etc/ssh/sshd_config.d/

Перед изменениями:

1. убедитесь, что вход по ключу работает;
2. сохраните текущую SSH-сессию открытой;
3. откройте вторую сессию для проверки;
4. проверьте конфигурацию через sshd -t;
5. только после успешного теста закрывайте старое соединение.

Минимальный вариант усиления настроек

Пример фрагмента конфигурации:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
MaxAuthTries 3
LoginGraceTime 30

Ограничение списка пользователей:

AllowUsers alice deploy

Если перенаправление портов не используется:

AllowTcpForwarding no

Если не используется перенаправление агента:

AllowAgentForwarding no

Если не используется X11:

X11Forwarding no

Отключайте функции только после проверки, что они не нужны существующим сценариям работы.

Отключение входа по паролю

Сначала установите публичный ключ и проверьте отдельное подключение:

ssh -o PreferredAuthentications=publickey alice@example.com

Затем задайте на сервере:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no

Проверьте синтаксис:

sudo sshd -t

Если команда ничего не вывела, синтаксических ошибок обычно нет.

Просмотр эффективных параметров:

sudo sshd -T |
  grep -E '^(pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|permitrootlogin) '

Перезагрузка конфигурации в Ubuntu и Debian:

sudo systemctl reload ssh

В Fedora, RHEL и некоторых других системах:

sudo systemctl reload sshd

Не закрывая старую сессию, проверьте новое подключение:

ssh alice@example.com

Запрет входа root

Полный запрет:

PermitRootLogin no

Вариант, допускающий вход root только по ключу:

PermitRootLogin prohibit-password

Обычно безопаснее входить под обычным пользователем и выполнять административные команды через sudo.

Смена порта SSH

Изменение порта уменьшает количество автоматического сетевого шума, но не заменяет ключи, обновления и межсетевой экран.

Пример:

Port 2222

До перезапуска SSH разрешите новый порт в межсетевом экране.

Для UFW:

sudo ufw allow 2222/tcp

Для firewalld:

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload

В системах с SELinux может понадобиться разрешить новый порт для SSH:

sudo semanage port -a -t ssh_port_t -p tcp 2222

Если порт уже зарегистрирован с другим типом, сначала проверьте настройки:

sudo semanage port -l | grep ssh

Затем проверьте конфигурацию и перезагрузите службу:

sudo sshd -t
sudo systemctl reload sshd

Не закрывая текущую сессию, подключитесь через новый порт:

ssh -p 2222 alice@example.com

Только после успешной проверки можно удалить старое правило межсетевого экрана для порта 22.

Обновления и сетевые ограничения

Регулярно устанавливайте обновления OpenSSH и операционной системы.

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

sudo ufw allow from 192.168.1.0/24 to any port 22 proto tcp

Для публичных серверов полезны:

• вход только по ключам;
• запрет прямого входа root;
• ограничение пользователей через AllowUsers;
• межсетевой экран;
• ограничение частоты попыток подключения;
• мониторинг журналов;
• отдельные ключи для людей и автоматизации.

Ограничение ключей в authorized_keys

Перед публичным ключом в authorized_keys можно указать ограничения.

Запрет туннелей, агента и X11:

no-port-forwarding,no-agent-forwarding,no-X11-forwarding ssh-ed25519 AAAA...

Разрешение входа только с определённого адреса:

from="192.168.1.0/24" ssh-ed25519 AAAA...

Принудительное выполнение конкретной команды:

command="/usr/local/bin/create-backup",no-pty,no-port-forwarding ssh-ed25519 AAAA...

Такие ограничения особенно полезны для ключей автоматизации.

Устранение неполадок

Подробная диагностика клиента

ssh -v alice@example.com

Более подробный вывод:

ssh -vvv alice@example.com

В диагностике можно увидеть:

• какие конфигурационные файлы прочитаны;
• какие ключи найдены;
• какие методы аутентификации разрешены;
• какой ключ предложен серверу;
• почему сервер отклонил ключ.

Сервер не принимает ключ

Проверьте на сервере:

ls -ld ~ ~/.ssh
ls -l ~/.ssh/authorized_keys

Исправление типичных прав:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Проверьте, что публичный ключ записан одной строкой:

cat ~/.ssh/authorized_keys

Проверьте эффективную конфигурацию сервера:

sudo sshd -T | grep -E 'pubkeyauthentication|authorizedkeysfile'

Permission denied (publickey)

Явно укажите ключ:

ssh -i ~/.ssh/id_ed25519 alice@example.com

Запретите перебор остальных ключей из агента:

ssh \
  -o IdentitiesOnly=yes \
  -i ~/.ssh/id_ed25519 \
  alice@example.com

Эквивалент в ~/.ssh/config:

Host example
    HostName example.com
    User alice
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Too many authentication failures

SSH-agent предлагает серверу слишком много ключей, и сервер разрывает соединение раньше, чем будет проверен нужный ключ.

Решение:

ssh \
  -o IdentitiesOnly=yes \
  -i ~/.ssh/id_ed25519_work \
  alice@example.com

Либо удалите лишние ключи из агента:

ssh-add -l
ssh-add -D
ssh-add ~/.ssh/id_ed25519_work

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

Ошибка может выглядеть так:

WARNING: UNPROTECTED PRIVATE KEY FILE!

Исправление:

chmod 600 ~/.ssh/id_ed25519

Соединение разрывается при простое

Добавьте в ~/.ssh/config:

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

Клиент будет отправлять проверочный пакет каждые 60 секунд и завершит соединение после трёх пропущенных ответов.

Не работает SSH config

Проверьте права:

chmod 600 ~/.ssh/config

Посмотрите итоговые параметры:

ssh -G HOST_ALIAS

Запустите диагностику:

ssh -vvv HOST_ALIAS

Не открывается перенаправленный порт

Запустите туннель с обязательной проверкой:

ssh -v \
  -o ExitOnForwardFailure=yes \
  -N -L 127.0.0.1:8080:127.0.0.1:80 \
  alice@example.com

Проверьте локальный порт:

ss -lnt | grep 8080

В macOS можно использовать:

lsof -nP -iTCP:8080 -sTCP:LISTEN

Убедитесь, что целевой сервис доступен со стороны SSH-сервера.

Проверка журналов сервера

Ubuntu и Debian:

sudo journalctl -u ssh --since '10 minutes ago'

Fedora и RHEL:

sudo journalctl -u sshd --since '10 minutes ago'

Просмотр журнала в реальном времени:

sudo journalctl -fu sshd

Имя службы зависит от дистрибутива.

Шпаргалка

Подключение

Ключи

ssh-agent

Туннели

Передача файлов

Минимум для запоминания

ssh user@host
ssh-keygen -t ed25519 -a 100
ssh-copy-id user@host
ssh-add ~/.ssh/id_ed25519
ssh -v user@host

scp file user@host:/tmp/
sftp user@host

ssh -N -L 127.0.0.1:8080:target:80 user@host
ssh -N -R 127.0.0.1:9000:127.0.0.1:3000 user@host
ssh -N -D 127.0.0.1:1080 user@host

Главное правило: сначала настройте и проверьте вход по ключу в отдельной SSH-сессии, а уже затем отключайте парольную аутентификацию или меняйте порт сервера.