Ты арендовал VPS, загрузил туда Telegram-бота, а потом увидел совет: «Подключись по SSH и перезапусти сервис». Чёрное окно, IP-адрес и незнакомые команды могут выглядеть как территория системных администраторов. На практике для первых задач достаточно понять несколько правил, а нужные команды может подготовить Claude Code.
Главное — отличать команду от результата, открытый ключ от закрытого и безопасное действие от рискованного. Тогда SSH превращается из пугающей аббревиатуры в обычный рабочий вход на свой сервер.
Содержание
- Что такое SSH простыми словами
- Зачем SSH новичку, который не программирует
- SSH-ключи: что это и чем они лучше пароля
- Как выглядит первое SSH-подключение к серверу
- Как создать SSH-ключ и положить его на сервер
- Файл ~/.ssh/config: алиасы вместо IP-адресов
- SSH-порт: что это, почему обычно встречается 22 и при чём здесь firewall
- SSH и GitHub: git push без пароля
- SSH-туннель и scp: файл и удалённый порт без сложной настройки
- Практический пример: деплой Telegram-бота для «Змейки» на VPS
- Типичные ошибки новичка при работе с SSH
- Безопасность SSH: что нельзя отправлять ИИ и коммитить
- Как проверить, что SSH настроен и готов к работе
- Частые вопросы
Что такое SSH простыми словами
SSH расшифровывается как Secure Shell — «защищённая оболочка». Это протокол, то есть набор правил, по которым твой компьютер устанавливает зашифрованное соединение с удалённым компьютером. Чаще всего удалённым компьютером оказывается VPS — виртуальный сервер, который работает в дата-центре круглосуточно.
После подключения ты видишь терминал сервера и вводишь команды почти так же, как в терминале на своём компьютере. Можно узнать, какие файлы лежат в папке, перейти в каталог проекта, скачать обновления из GitHub, запустить тесты, перезапустить бота или прочитать журнал ошибок. Команды выполняются не на твоём ноутбуке, а на сервере.
Соединение шифруется. Провайдер интернета и случайный наблюдатель в общей сети не получают содержимое команд, пароли и ответы сервера в читаемом виде. Сам SSH не делает сервер неуязвимым: безопасность всё равно зависит от ключей, настроек входа, обновлений и того, какие команды ты запускаешь.
Когда спрашивают «SSH что это», иногда смешивают сразу три вещи:
- SSH-протокол определяет, как устанавливается защищённое соединение.
- SSH-сервер — программа на VPS, которая принимает подключения и проверяет, можно ли впустить пользователя.
- SSH-клиент — программа на твоём компьютере, которая начинает соединение. Команда
sshв терминале и есть такой клиент.
SSH отличается от FTP и панели хостинга назначением. FTP и его защищённый вариант SFTP в первую очередь нужны для передачи файлов. Через них удобно загрузить картинку или скачать архив, но ими не перезапустишь системную службу и не посмотришь живой журнал процесса. SFTP при этом часто работает поверх SSH и использует те же учётные данные.
Панель хостинга — графический интерфейс в браузере. Она помогает создать сервер, увидеть IP, переустановить систему, настроить сеть или добавить открытый SSH-ключ. Панель показывает только те действия, для которых провайдер сделал кнопки. SSH открывает терминал самой операционной системы и даёт больше возможностей, но требует внимательнее относиться к командам.
Разделение можно запомнить так: панель управляет услугой у провайдера, FTP или SFTP переносит файлы, SSH позволяет работать внутри сервера. Эти инструменты не конкурируют и часто используются вместе.
Главная мысль: SSH — это защищённый удалённый терминал. Ты сидишь за своим компьютером, а команды выполняются на VPS.
Зачем SSH новичку, который не программирует
Чтобы пользоваться SSH, не нужно уметь писать программу с нуля. Тебе нужно понимать цель действия и уметь проверить результат. Синтаксис команды может подсказать ИИ, но решение о запуске остаётся за тобой.
Новичку SSH обычно нужен для нескольких практических задач:
- впервые зайти на арендованный VPS;
- проверить, запущен ли Telegram-бот;
- перезапустить бота после обновления;
- посмотреть последние сообщения и ошибки в журнале;
- получить новую версию проекта из GitHub;
- установить зависимости, которые перечислены в проекте;
- проверить свободное место на диске;
- скопировать небольшой файл с компьютера на сервер или обратно.
Допустим, «Змейка» опубликована в интернете, а Telegram-бот отправляет игрокам ссылку и сообщает о новых рекордах. Бот перестал отвечать. Через SSH можно подключиться к VPS, посмотреть состояние службы и прочитать последние строки журнала. Вместо просьбы «почини всё» лучше дать Claude Code наблюдаемые факты: название проекта, команду запуска, текст ошибки и то, что изменилось перед поломкой.
Хороший запрос к ИИ выглядит так:
Я новичок. Telegram-бот для проекта «Змейка» работает на Ubuntu как служба snake-bot. Дай только безопасные команды для проверки состояния и просмотра последних записей журнала. Объясни каждую команду до запуска. Не предлагай удаление файлов, переустановку системы и изменение firewall.
Такой запрос задаёт границы. ИИ сначала предлагает диагностику, а не случайный набор действий. Ты можешь запускать команды по одной и возвращать результат без секретов. Если команда содержит rm, перезаписывает файл через >, меняет права рекурсивно или касается сетевых правил, попроси отдельно объяснить последствия.
Если терминал пока совсем незнаком, пригодится материал «Не бойся терминала». Для выбора VPS можно отдельно сравнить общую логику зарубежного сервера в объяснении про DigitalOcean и российской панели в разборе Timeweb Cloud. Актуальные тарифы смотри на сайте сервиса.
SSH не отменяет панель провайдера. Если ты ошибся в сетевых настройках и закрыл себе вход, аварийная консоль или восстановление через панель может остаться единственным способом вернуться на сервер. Поэтому до изменений полезно знать, где у провайдера находится доступ к консоли восстановления, не запоминая названия конкретных кнопок.
SSH-ключи: что это и чем они лучше пароля
SSH-доступ можно защищать паролем, ключом или сочетанием нескольких способов. Пароль знаком: сервер хранит данные для его проверки, а ты вводишь секрет при подключении. SSH-ключ устроен иначе и состоит из пары:
- открытый ключ можно передать серверу, GitHub и администратору;
- закрытый ключ остаётся только на твоём компьютере и никому не отправляется.
Открытый и закрытый ключи математически связаны. При входе сервер проверяет, способен ли твой компьютер подтвердить владение подходящим закрытым ключом. Сам закрытый ключ по сети не отправляется. Сервер хранит только открытую часть, по которой нельзя восстановить закрытую за разумное время при использовании современных алгоритмов и корректно созданного ключа.
Это похоже не на передачу копии пароля, а на проверку подписи. Сервер выдаёт одноразовую задачу, клиент подписывает данные закрытым ключом, а сервер сверяет подпись с открытым. Если проверка прошла, вход разрешён.
| Критерий | Пароль | SSH-ключ |
|---|---|---|
| Что хранится у тебя | Строка, которую можно запомнить или сохранить в менеджере паролей | Файл закрытого ключа, при желании защищённый кодовой фразой |
| Что хранится на сервере | Данные для проверки пароля | Открытый ключ |
| Что происходит при входе | Ты вводишь пароль | Клиент подтверждает владение закрытым ключом |
| Устойчивость к перебору | Зависит от длины и уникальности пароля | Современный ключ практически нельзя подобрать перебором |
| Удобство регулярной работы | Пароль приходится вводить или хранить в программе | После настройки подключение может выполняться без ввода серверного пароля |
| Риск фишинга | Пароль можно ввести не на том сервере или отдать злоумышленнику | Закрытый ключ не передаётся серверу, но файл всё равно нужно беречь |
| Отзыв доступа | Нужно менять пароль и сообщать его тем, кому он нужен | Можно удалить один открытый ключ, не затрагивая остальные |
| Подходит для автоматизации | Нежелательно хранить пароль в скрипте | Можно применять отдельный ограниченный ключ |
Ключ обычно безопаснее пароля по двум причинам. Его нельзя угадать как короткое слово, дату рождения или повторно использованный пароль. Кроме того, после успешной проверки вход по паролю на сервере можно отключить, и автоматические боты потеряют возможность перебирать комбинации.
Закрытый ключ можно дополнительно защитить кодовой фразой. Тогда одного украденного файла недостаточно: при первом использовании понадобится ещё и фраза. Чтобы не вводить её при каждой команде, система может временно хранить разблокированный ключ в ssh-agent — локальном помощнике для работы с ключами.
Удобство не означает, что один ключ должен жить вечно и использоваться повсюду. Для личного VPS и GitHub допустимо начать с одного ключа, если ты понимаешь, где он добавлен. По мере роста проекта удобнее завести отдельные ключи для разных устройств и задач: потерю ноутбука тогда можно обработать удалением только его открытого ключа.
Как выглядит первое SSH-подключение к серверу
Для входа нужны три значения: имя пользователя, адрес сервера и способ подтверждения доступа. Их выдаёт провайдер или тот, кто настроил VPS. Адресом может быть IP вроде 203.0.113.10 либо доменное имя. Это демонстрационный IP из диапазона для документации; подставь адрес своего сервера.
Базовая команда выглядит так:
ssh user@host
Например:
ssh deploy@203.0.113.10
deploy — пользователь на сервере, @ отделяет его от адреса, а оставшаяся часть указывает, куда подключаться. Имя пользователя нельзя угадывать по названию своего аккаунта: оно зависит от образа системы и настроек провайдера.
При первом подключении клиент ещё не знает этот сервер и показывает предупреждение о подлинности узла. В сообщении будет fingerprint — короткое представление открытого ключа самого сервера. Оно помогает убедиться, что ты соединяешься со своим VPS, а не с чужой машиной, которая перехватила трафик.
Не отвечай yes автоматически. Сравни fingerprint с тем, который показывает панель провайдера, документация для созданного сервера или администратор по независимому каналу. Формат и место публикации зависят от сервиса. Если сравнить значение сейчас негде, лучше сначала уточнить его у поддержки, чем превращать предупреждение в формальность.
После подтверждения адрес и ключ сервера записываются в файл known_hosts внутри папки ~/.ssh. При следующих подключениях клиент сверит их автоматически. Если ключ неожиданно изменится, SSH выдаст заметное предупреждение. Такое бывает после переустановки VPS, смены IP или переноса сервера, но также может указывать на попытку подмены. Сначала выясни причину, затем обновляй запись.
Если на сервере разрешён вход по паролю, терминал попросит его. Во время ввода символы обычно не отображаются — даже точки или звёздочки. Это нормальное поведение, а не зависание. Введи пароль и нажми Enter.
После успешного входа приглашение командной строки изменится. Проверить, где выполняются команды, можно безопасными запросами:
whoami
hostname
pwd
Они покажут текущего пользователя, имя сервера и рабочую папку. Завершить сеанс можно командой:
exit
Если SSH-сервер слушает нестандартный порт, его указывают параметром -p:
ssh -p 2222 deploy@203.0.113.10
Число здесь служит примером. Реальный SSH-порт бери из настроек своего сервера.
Как создать SSH-ключ и положить его на сервер
На macOS, Linux и современных системах Windows клиент OpenSSH часто уже доступен в терминале. Проверить наличие можно без изменения системы:
ssh -V
Если команда не найдена, установи OpenSSH штатным способом для своей операционной системы. Названия экранов и кнопок меняются, поэтому ориентируйся на актуальную документацию системы.
Новый ключ создаёт команда ssh-keygen. Для современного личного ключа обычно подходит алгоритм Ed25519:
ssh-keygen -t ed25519 -C "snake-vps"
Комментарий snake-vps не является секретом и нужен только для узнаваемости. Программа предложит путь сохранения и кодовую фразу. Если принять стандартный путь, обычно появятся два файла:
~/.ssh/id_ed25519— закрытый ключ;~/.ssh/id_ed25519.pub— открытый ключ.
Расширение .pub означает public, то есть «открытый». Файл без .pub — закрытый. Перед копированием всегда проверяй имя файла, а не только содержимое буфера обмена.
Есть два распространённых способа добавить открытый ключ на VPS.
Способ 1. Скопировать ключ через уже работающий вход
Если вход по паролю разрешён и в системе есть утилита ssh-copy-id, выполни на своём компьютере:
ssh-copy-id deploy@203.0.113.10
Утилита войдёт на сервер обычным способом и добавит открытый ключ в ~/.ssh/authorized_keys нужного пользователя. Для нестандартного порта синтаксис зависит от параметров утилиты, поэтому перед запуском попроси ИИ составить команду для твоего порта и проверить её по справке ssh-copy-id в твоей системе.
Способ 2. Добавить ключ через панель хостинга
Провайдеры VPS обычно позволяют указать открытый ключ при создании сервера или добавить его позже. Общая логика одинакова: скопировать одну строку из файла с .pub, вставить её в поле для SSH-ключа и связать с нужным сервером или пользователем. Точные названия разделов и доступность изменения уже созданного VPS зависят от провайдера.
На macOS и Linux вывести открытую часть можно так:
cat ~/.ssh/id_ed25519.pub
На Windows путь и команда зависят от выбранной оболочки. Claude Code может подсказать вариант, если ты сообщишь, используешь ли PowerShell, командную строку или WSL. Перед отправкой результата убедись, что имя заканчивается на .pub.
После добавления ключа открой новое окно терминала и проверь вход. Старое соединение пока не закрывай: оно поможет исправить настройку, если новый ключ не сработает.
ssh deploy@203.0.113.10
Отключать парольный вход имеет смысл только после успешной проверки ключа в отдельном сеансе и при наличии пути восстановления через панель провайдера. Изменение настроек SSH-сервера и firewall лучше поручать ИИ маленькими проверяемыми шагами: сначала показать текущие значения, затем предложить изменение, проверить синтаксис конфигурации и лишь потом перезагрузить службу.
Файл ~/.ssh/config: алиасы вместо IP-адресов
Постоянно вводить пользователя, IP, порт и путь к ключу неудобно. Локальный файл ~/.ssh/config хранит короткие имена подключений. Он находится на твоём компьютере, а не на VPS.
Пример записи:
Host snake-vps
HostName 203.0.113.10
User deploy
Port 22
IdentityFile ~/.ssh/id_ed25519
Теперь вместо длинной команды достаточно написать:
ssh snake-vps
Тот же алиас понимают многие программы, использующие SSH. Например, файл можно отправить так: scp report.txt snake-vps:/home/deploy/. Это уменьшает количество опечаток и не заставляет помнить IP.
Host — придуманное тобой локальное имя. HostName — настоящий адрес. User — пользователь на сервере. Port — SSH-порт. IdentityFile — путь к закрытому ключу на твоём компьютере.
Можно завести отдельные записи для рабочего и тестового VPS, даже если на них одинаковое имя пользователя. Если ключи разные, каждая запись указывает свой IdentityFile.
Файл конфигурации не предназначен для паролей и токенов. Не добавляй туда пароль сервера, токен Telegram-бота или ключ API. На системах семейства Unix права на конфигурацию обычно ограничивают текущим пользователем:
chmod 600 ~/.ssh/config
SSH-порт: что это, почему обычно встречается 22 и при чём здесь firewall
Порт — это числовой «вход» сетевой программы на одном IP-адресе. Веб-сервер, база данных и SSH могут работать на одной машине, потому что слушают разные порты. Порт 22 стандартно назначен SSH, поэтому команда ssh user@host пробует его, если другой номер не указан.
Публичные серверы постоянно сканируют автоматические боты. Они проверяют известные IP и стучатся в порт 22, пытаясь найти слабый пароль или старую уязвимость. Записи о неудачных входах сами по себе не означают, что сервер уже взломан: это обычный фон публичного интернета. Смена порта уменьшает шум в журналах, но не заменяет защиту; рабочая основа — вход только по ключам, отключённый пароль после проверки, запрет прямого входа под root там, где он не нужен, своевременные обновления, firewall с доступом лишь к нужным портам и fail2ban для временной блокировки повторных попыток. Все изменения применяй по одному, сохраняя активный сеанс и аварийный доступ через панель, иначе можно закрыть вход самому себе.
Firewall — сетевой фильтр сервера. Он разрешает одни входящие соединения и отклоняет другие. Если SSH перенесён с 22 на другой порт, сначала нужно разрешить новый порт в firewall и проверить новое подключение, а уже затем закрывать старый. У VPS может быть ещё один облачный firewall в панели провайдера; тогда правила должны согласовываться на обоих уровнях.
Скрывать номер порта бессмысленно как единственную защиту: сканер способен найти открытый порт. Польза смены — меньше автоматического мусора и более чистые журналы. Ключи и ограниченные сетевые правила дают реальную основу безопасности.
SSH и GitHub: git push без пароля
GitHub использует SSH не для входа в терминал своего сервера, а для подтверждения личности при работе с Git-репозиториями. Механизм тот же: закрытая часть остаётся на твоём компьютере, открытую ты добавляешь в настройки аккаунта GitHub. После этого git pull и git push могут работать без ввода пароля GitHub.
Можно добавить тот же открытый ключ, который используется для личного VPS. Для первого проекта это проще. Более аккуратный подход — отдельный ключ для GitHub: тогда доступ к репозиториям и доступ к серверу можно отзывать независимо. Если ключей несколько, нужный выбирается через ~/.ssh/config.
SSH-адрес репозитория выглядит так:
git@github.com:owner/snake.git
Он отличается от HTTPS-адреса. Если репозиторий уже добавлен через HTTPS, один созданный ключ не переключит его автоматически. Текущий адрес можно посмотреть командой:
git remote -v
Проверка связи с GitHub обычно выполняется так:
ssh -T git@github.com
Эта команда проверяет аутентификацию, но не открывает обычный серверный терминал. При первом запуске также появится fingerprint узла: сверяй его с актуальной официальной документацией GitHub.
Токены GitHub, HTTPS и SSH решают похожую задачу разными способами. Разница разобрана в материале «Что такое GitHub и токен». Не вставляй токен в SSH-конфигурацию и не путай его с закрытым ключом.
SSH-туннель и scp: файл и удалённый порт без сложной настройки
Через SSH можно не только вводить команды. Два полезных дополнения для новичка — безопасное копирование файлов и локальный туннель.
scp копирует данные через SSH-соединение. Чтобы отправить локальный файл config.example в домашнюю папку пользователя на VPS, команда может выглядеть так:
scp config.example deploy@203.0.113.10:/home/deploy/
Чтобы скачать журнал с сервера на текущий компьютер, направление меняется:
scp deploy@203.0.113.10:/home/deploy/bot.log ./bot.log
Сначала указан источник, потом место назначения. Точка и косая черта ./ означают текущую локальную папку. Для каталога используют параметр -r, но перед копированием большой папки полезно проверить её размер: случайно скачанные зависимости или архивы занимают много места.
У scp номер нестандартного порта задаётся заглавной -P, а у ssh — строчной -p. Это частая причина ошибок:
scp -P 2222 report.txt deploy@203.0.113.10:/home/deploy/
SSH-туннель связывает локальный порт с портом, доступным со стороны сервера. Например, панель диагностики бота работает на VPS только по адресу localhost:3000 и специально не открыта всему интернету. Можно временно вывести её на порт 8080 своего компьютера:
ssh -L 8080:localhost:3000 snake-vps
Пока соединение открыто, в браузере на своём компьютере можно перейти на http://localhost:8080. Запросы пойдут внутри SSH-соединения к localhost:3000 на VPS. Сервис остаётся закрытым от публичного интернета, что безопаснее, чем открывать диагностический порт в firewall ради разового просмотра.
Числа 8080 и 3000 — примеры. Первый порт должен быть свободен на твоём компьютере, второй должен совпадать с реальным портом приложения на сервере. Туннель не запускает приложение: если сервис на VPS выключен, перенаправлять будет нечего.
Практический пример: деплой Telegram-бота для «Змейки» на VPS
Пусть в GitHub лежит Telegram-бот, который отправляет ссылку на браузерную «Змейку» и получает от твоего приложения уведомления о рекордах. Сервер уже создан, репозиторий однажды скопирован в /srv/snake-bot, зависимости установлены, а процесс оформлен как системная служба snake-bot. Названия здесь условные: в своём проекте подставь реальные путь и службу.
Рабочее обновление можно разделить на короткие этапы.
1. Подключиться и проверить окружение
ssh snake-vps
whoami
hostname
pwd
Ты убеждаешься, что попал на нужный сервер и работаешь под ожидаемым пользователем. Если whoami показывает root, остановись и уточни, нужен ли проекту прямой вход с такими правами. Для обычного обновления приложения чаще используют отдельного пользователя и sudo только для конкретных административных команд.
2. Перейти в проект и посмотреть состояние Git
cd /srv/snake-bot
git status
git remote -v
git status покажет незакоммиченные изменения на сервере. Если они есть, не запускай git pull вслепую: сначала выясни, откуда появились файлы и нужны ли они. Сервер не должен быть местом для случайного редактирования рабочей версии.
3. Получить проверенное обновление
git pull --ff-only
Параметр --ff-only не разрешает Git молча создавать слияние при расхождении истории. Если команда отказалась работать, это сигнал разобраться в состоянии репозитория, а не отменять ограничение случайной командой из интернета.
Для проекта на Node.js следующие команды могут выглядеть так:
npm ci
npm test
npm ci устанавливает версии зависимостей из файла блокировки, а npm test запускает тесты, если проект их настроил. Команды зависят от технологии и сценариев в репозитории. Попроси Claude Code прочитать package.json проекта и назвать существующие команды, не придумывая новые.
4. Перезапустить бота и проверить состояние
Если бот оформлен как служба systemd, последовательность может быть такой:
sudo systemctl restart snake-bot
sudo systemctl status snake-bot --no-pager
sudo journalctl -u snake-bot -n 100 --no-pager
Первая команда перезапускает службу, вторая показывает её состояние, третья выводит последние записи журнала. Число строк не является лимитом сервиса — это выбранный объём вывода для диагностики. Если у тебя применяется другой менеджер процессов, команды будут другими.
5. Проверить поведение снаружи
Отправь боту тестовую команду и открой ссылку на «Змейку». Серверный статус active сообщает, что процесс запущен, но не доказывает, что бот отвечает правильно, видит сеть и использует верные настройки. Финальная проверка должна повторять действие обычного пользователя.
Токен Telegram-бота не хранят в Git и не вставляют прямо в команду, которая останется в истории оболочки. Обычно приложение получает секрет из переменной окружения или защищённого файла на сервере. Общие правила собраны в материале «Хранение секретов и токенов».
Если обновление не сработало, передай ИИ обезличенный фрагмент журнала. Удали токены, пароли, закрытые ключи, адреса приватных систем и персональные данные. Полезный запрос содержит точную команду, её код завершения, текст ошибки и ожидаемый результат.
Типичные ошибки новичка при работе с SSH
Ошибка SSH редко означает «всё сломалось». Обычно сообщение указывает на этап, где остановилось соединение: адрес не найден, порт недоступен, сервер не узнан или ключ не принят.
| Сообщение или ситуация | Что обычно означает | Что проверить и сделать |
|---|---|---|
Permission denied (publickey) |
Сервер разрешает ключи, но не принял ни один предложенный ключ | Проверь пользователя, нужный файл .pub в authorized_keys, выбранный IdentityFile и подробный вывод ssh -v; не включай пароль только ради обхода ошибки |
Permission denied после запроса пароля |
Пароль неверен либо вход по паролю запрещён | Уточни пользователя и способ входа у провайдера; не перебирай варианты многократно |
Connection refused |
Адрес отвечает, но на выбранном порту никто не принимает SSH или соединение отклоняется | Проверь порт, состояние SSH-службы и недавние изменения; используй консоль провайдера, если удалённого входа нет |
Connection timed out |
Ответ не пришёл вовремя | Проверь IP, сеть, облачный и системный firewall, разрешён ли твой адрес; это не доказывает, что пароль или ключ неверен |
Could not resolve hostname |
Клиент не смог превратить имя в сетевой адрес | Исправь опечатку в домене или алиасе ~/.ssh/config, проверь HostName |
REMOTE HOST IDENTIFICATION HAS CHANGED |
Ключ сервера отличается от сохранённого | Не удаляй запись автоматически; сначала подтверди переустановку, перенос или смену ключа по независимому каналу |
| Ключ существует, но игнорируется | Клиент выбрал другой файл или сервер отвергает права доступа | Укажи нужный IdentityFile, посмотри ssh -v, проверь права и владельца файлов |
| Потерян закрытый ключ | Компьютер больше не может подтвердить доступ | Войди с другого заранее добавленного ключа или через консоль восстановления, добавь новый открытый ключ и отзови потерянный |
| Закрытый ключ попал в публичный репозиторий | Секрет больше нельзя считать секретом, даже если файл быстро удалён | Немедленно удали соответствующий открытый ключ со всех серверов и сервисов, создай новую пару, замени доступ и очисти историю репозитория отдельной проверенной процедурой |
На Linux и macOS SSH проверяет права доступа к чувствительным файлам. Слишком широкие права могут привести к отказу использовать ключ. Типичные значения для локального пользователя выглядят так:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
На сервере для каталога и списка разрешённых ключей обычно применяют:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
Одних чисел недостаточно: файлы должны принадлежать правильному пользователю. Не запускай рекурсивный chmod или chown по большой папке без проверки пути. В Windows разрешения управляются иначе, и механическое повторение Unix-команд не поможет.
Для диагностики можно включить подробный режим клиента:
ssh -v snake-vps
Он показывает, к какому адресу и порту идёт подключение, какие ключи клиент предлагает и на каком этапе возникает отказ. Перед отправкой полного вывода в публичный чат просмотри его: там могут оказаться имена пользователей, внутренние адреса и пути на твоём компьютере.
Безопасность SSH: что нельзя отправлять ИИ и коммитить
Закрытый SSH-ключ — секрет того же уровня, что пароль от сервера. Никогда не отправляй его в чат ИИ, поддержку, мессенджер или форму на сайте. Не добавляй его в Git, даже в приватный репозиторий. Не вставляй содержимое в запрос «проверь, правильный ли ключ».
Открытый ключ с расширением .pub предназначен для передачи. Но даже его лучше публиковать только там, где это нужно: он может раскрыть подпись-комментарий и связать твои аккаунты между собой. Если ИИ помогает настроить доступ, ему достаточно знать путь к файлу, алгоритм, пользователя, адрес и обезличенную ошибку. Содержимое закрытой части для диагностики не требуется никогда.
Файлы закрытых ключей часто начинаются строкой с указанием PRIVATE KEY. Если видишь такие слова в подготовленном к отправке фрагменте, остановись и удали весь ключ из сообщения. Фрагмент закрытого ключа тоже нельзя считать безопасным.
Базовые привычки заметно снижают риск:
- защищай закрытый ключ кодовой фразой;
- блокируй экран компьютера и включай шифрование диска;
- создавай отдельный ключ для нового устройства;
- удаляй открытый ключ потерянного устройства со всех серверов;
- не работай постоянно под
root; - проверяй fingerprint нового сервера;
- обновляй сервер и SSH-пакеты штатным способом;
- перед изменением firewall сохраняй работающий сеанс;
- храни резервный способ входа, но не складывай незашифрованные ключи в облачную папку;
- просматривай
git statusперед коммитом и убеждайся, что секретные файлы исключены.
Файл .gitignore помогает не добавить ключ или .env случайно, но не является защитой уже опубликованного секрета. Если закрытый ключ хотя бы один раз попал в репозиторий, его нужно отозвать и заменить. Удаление последнего коммита или перевод репозитория в приватный режим не возвращает секретность.
ИИ может уверенно предложить опасную или неподходящую команду, особенно если не видит устройство сервера целиком. Проси сначала объяснить: что команда читает, что меняет, какие файлы затрагивает, как проверить результат и как восстановить доступ при ошибке. Разрешай диагностические команды отдельно от изменений.
Правило без исключений: открытый ключ можно добавить на сервер, закрытый ключ остаётся на твоём устройстве. Ни Claude Code, ни администратору хостинга закрытый ключ не нужен.
Как проверить, что SSH настроен и готов к работе
Проверка должна подтверждать не только факт входа, но и возможность восстановиться после ошибки. Пройди короткий список до первого серьёзного обновления проекта:
- Команда
ssh snake-vpsподключает к ожидаемому серверу. -
whoamiпоказывает отдельного пользователя, а не неожиданный аккаунт. - Fingerprint сервера был сверен с доверенным источником.
- Вход по ключу проверен в новом окне терминала.
- Старый сеанс не закрывался до завершения проверки новых настроек.
- Закрытый ключ защищён и не находится внутри папки проекта.
- Понятно, где удалить открытый ключ при потере компьютера.
- Известен способ открыть аварийную консоль в панели провайдера.
- В firewall разрешены только действительно нужные публичные порты.
- Токен Telegram-бота хранится вне Git.
- Команды перезапуска и просмотра журнала записаны в документации проекта.
- После перезапуска бот проверен реальным сообщением, а не только статусом процесса.
Полезно сохранить в README проекта нейтральную памятку: имя алиаса, путь к проекту на сервере, название службы, команды проверки и порядок отката. Секреты и содержимое ключей в такую памятку не включают. Тогда при сбое не придётся восстанавливать безопасную последовательность по памяти.
Частые вопросы
SSH-доступ — что это и где его взять?
SSH-доступ — разрешение подключаться к серверу под определённым пользователем с паролем или ключом. Адрес, имя пользователя и способ первого входа сообщает провайдер VPS или администратор. Если этих данных нет, ищи их в документации услуги или обращайся в поддержку, не угадывая логин.
SSH-сервер — что это: отдельный компьютер или программа?
В разговоре SSH-сервером могут назвать и сам VPS, и программу, принимающую SSH-соединения. Технически точнее второе: на удалённой машине работает служба SSH, а клиент ssh на твоём компьютере подключается к ней.
SSH-порт — что это и обязательно ли использовать 22?
Это номер сетевого входа, на котором SSH-служба ждёт подключения. Стандартный номер — 22, но администратор может выбрать другой. Смена порта уменьшает автоматический шум, однако не заменяет ключи, firewall и обновления.
Можно ли подключаться по SSH с Windows?
Да. В современных версиях Windows доступен клиент OpenSSH, а также можно работать через PowerShell, Windows Terminal или WSL. Если команда ssh -V не находится, используй актуальную инструкцию Microsoft для своей версии системы.
Что делать, если я потерял закрытый SSH-ключ?
Создай новую пару на доверенном устройстве, добавь новый открытый ключ через другой действующий доступ или консоль провайдера, затем удали потерянный ключ из authorized_keys и связанных сервисов. Восстановить прежний закрытый ключ из открытого нельзя.
Может ли Claude Code сам подключиться к VPS и всё настроить?
Он может подготовить и выполнить команды в доступном ему окружении, если ты явно дал такое разрешение и настроил доступ. Не передавай закрытый ключ в чат и не позволяй применять непроверенный набор изменений. Безопаснее идти этапами: диагностика, объяснение, одна правка, проверка результата и только потом следующий шаг.
SSH что это простыми словами? Это защищённая дверь в терминал твоего сервера. Для уверенной работы достаточно освоить вход по ключу, проверку fingerprint, алиас в ~/.ssh/config и несколько команд проекта. Всё остальное добавляется по мере реальной необходимости — без спешки и без передачи секретов кому-либо.
Читай дальше
Все статьиНе просто статьи — тебя доведут до результата
В практикуме за 2499 ₽ рядом живая команда практикующих разработчиков и маркетологов: ведём по шагам до твоего работающего приложения. Не «ролики и сам разбирайся» — помогаем на каждом затыке.
Перейти к практикуму