Вопрос или проблема
Это мой первый раз, когда я пытаюсь подключиться к серверу с помощью SSH. Я получил детали от моего старшего разработчика, но когда я пытаюсь подключиться, то получаю ошибку, касающуюся отказа в доступе (publickey).
Я пытался запустить команду SSH с отладочными параметрами, но она выдает список вывода, который я не могу сильно понять.
Это команда, которую я запускаю
ssh -vvv [youruser]@[yourLinode]
А вот вывод
OpenSSH_8.5p1, OpenSSL 1.1.1j 16 фев 2021
debug1: Чтение конфигурационных данных /etc/ssh/ssh_config
debug3: расширенный UserKnownHostsFile '~/.ssh/known_hosts' -> '/c/Users/pc8/.ssh/known_hosts'
debug3: расширенный UserKnownHostsFile '~/.ssh/known_hosts2' -> '/c/Users/pc8/.ssh/known_hosts2'
debug2: разрешение "[yourLinode]" порт 22
debug3: ssh_connect_direct: вход
debug1: Подключение к [yourLinode] [54.213.195.223] порт 22.
debug3: set_sock_tos: установка сокета 3 IP_TOS 0x48
debug1: Подключение установлено.
debug1: файл идентичности /c/Users/pc8/.ssh/id_rsa тип -1
debug1: файл идентичности /c/Users/pc8/.ssh/id_rsa-cert тип -1
debug1: файл идентичности /c/Users/pc8/.ssh/id_dsa тип -1
debug1: файл идентичности /c/Users/pc8/.ssh/id_dsa-cert тип -1
debug1: файл идентичности /c/Users/pc8/.ssh/id_ecdsa тип -1
debug1: файл идентичности /c/Users/pc8/.ssh/id_ecdsa-cert тип -1
debug1: файл идентичности /c/Users/pc8/.ssh/id_ecdsa_sk тип -1
debug1: файл идентичности /c/Users/pc8/.ssh/id_ecdsa_sk-cert тип -1
debug1: файл идентичности /c/Users/pc8/.ssh/id_ed25519 тип -1
debug1: файл идентичности /c/Users/pc8/.ssh/id_ed25519-cert тип -1
debug1: файл идентичности /c/Users/pc8/.ssh/id_ed25519_sk тип -1
debug1: файл идентичности /c/Users/pc8/.ssh/id_ed25519_sk-cert тип -1
debug1: файл идентичности /c/Users/pc8/.ssh/id_xmss тип -1
debug1: файл идентичности /c/Users/pc8/.ssh/id_xmss-cert тип -1
debug1: Локальная версия строка SSH-2.0-OpenSSH_8.5
debug1: Удаленная версия протокола 2.0, удаленная версия программного обеспечения Platform.sh
debug1: compat_banner: нет совпадений: Platform.sh
debug2: fd 3 установка O_NONBLOCK
debug1: Аутентификация к [yourLinode]:22 как '[youruser]'
debug3: record_hostkey: найден тип ключа RSA в файле /c/Users/pc8/.ssh/known_hosts:2
debug3: load_hostkeys_file: загружен 1 ключ из [yourLinode]
debug3: record_hostkey: найден тип ключа RSA в файле /c/Users/pc8/.ssh/known_hosts2:2
debug3: load_hostkeys_file: загружен 1 ключ из [yourLinode]
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: Нет такого файла или каталога
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: Нет такого файла или каталога
debug3: order_hostkeyalgs: предпочтение hostkeyalgs: [email protected],[email protected],[email protected],rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT отправлено
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT получено
debug2: локальное клиентское предложение KEXINIT
debug2: алгоритмы KEX: curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c
debug2: алгоритмы ключей хоста: [email protected],[email protected],[email protected],rsa-sha2-512,rsa-sha2-256,ssh-rsa,[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected]
debug2: шифры ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,3des-cbc,aes256-cbc,aes192-cbc
debug2: шифры stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,3des-cbc,aes256-cbc,aes192-cbc
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: сжатие ctos: none,[email protected],zlib
debug2: сжатие stoc: none,[email protected],zlib
debug2: языки ctos:
debug2: языки stoc:
debug2: first_kex_follows 0
debug2: зарезервировано 0
debug2: соперник серверный предложение KEXINIT
debug2: алгоритмы KEX: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1,ext-info-s
debug2: алгоритмы ключей хоста: rsa-sha2-256,rsa-sha2-512,ssh-rsa
debug2: шифры ctos: [email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr
debug2: шифры stoc: [email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr
debug2: MACs ctos: [email protected],hmac-sha2-256
debug2: MACs stoc: [email protected],hmac-sha2-256
debug2: сжатие ctos: none
debug2: сжатие stoc: none
debug2: языки ctos:
debug2: языки stoc:
debug2: first_kex_follows 0
debug2: зарезервировано 0
debug1: kex: алгоритм: [email protected]
debug1: kex: алгоритм ключа хоста: rsa-sha2-512
debug1: kex: сервер->клиент шифр: [email protected] MAC: <implicit> сжатие: none
debug1: kex: клиент->сервер шифр: [email protected] MAC: <implicit> сжатие: none
debug3: send packet: type 30
debug1: ожидает SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: SSH2_MSG_KEX_ECDH_REPLY получено
debug1: Ключ хоста сервера: ssh-rsa SHA256:0k+lbQiTn4QgfmNupriYGozTdTOG9u6E5OxwhxWkHlk
debug3: record_hostkey: найден тип ключа RSA в файле /c/Users/pc8/.ssh/known_hosts:2
debug3: load_hostkeys_file: загружен 1 ключ из [yourLinode]
debug3: record_hostkey: найден тип ключа RSA в файле /c/Users/pc8/.ssh/known_hosts2:2
debug3: load_hostkeys_file: загружен 1 ключ из [yourLinode]
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: Нет такого файла или каталога
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: Нет такого файла или каталога
debug1: Хост '[yourLinode]' известен и соответствует ключу RSA хоста.
debug1: Найден ключ в /c/Users/pc8/.ssh/known_hosts:2
debug3: send packet: type 21
debug2: set_newkeys: режим 1
debug1: смена ключа после 134217728 блоков
debug1: SSH2_MSG_NEWKEYS отправлено
debug1: ожидает SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS получено
debug2: set_newkeys: режим 0
debug1: смена ключа после 134217728 блоков
debug1: Будет попытка ключа: /c/Users/pc8/.ssh/id_rsa
debug1: Будет попытка ключа: /c/Users/pc8/.ssh/id_dsa
debug1: Будет попытка ключа: /c/Users/pc8/.ssh/id_ecdsa
debug1: Будет попытка ключа: /c/Users/pc8/.ssh/id_ecdsa_sk
debug1: Будет попытка ключа: /c/Users/pc8/.ssh/id_ed25519
debug1: Будет попытка ключа: /c/Users/pc8/.ssh/id_ed25519_sk
debug1: Будет попытка ключа: /c/Users/pc8/.ssh/id_xmss
debug2: pubkey_prepare: завершено
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO получено
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,[email protected],ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected]>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT получено
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Возможные методы аутентификации: publickey
debug3: начать снова, передан другой список publickey
debug3: предпочтительный publickey, keyboard-interactive, password
debug3: authmethod_lookup publickey
debug3: оставшиеся предпочтительные: keyboard-interactive, password
debug3: authmethod_is_enabled publickey
debug1: Следующий метод аутентификации: publickey
debug1: Попытка приватного ключа: /c/Users/pc8/.ssh/id_rsa
debug3: нет такой идентичности: /c/Users/pc8/.ssh/id_rsa: Нет такого файла или каталога
debug1: Попытка приватного ключа: /c/Users/pc8/.ssh/id_dsa
debug3: нет такой идентичности: /c/Users/pc8/.ssh/id_dsa: Нет такого файла или каталога
debug1: Попытка приватного ключа: /c/Users/pc8/.ssh/id_ecdsa
debug3: нет такой идентичности: /c/Users/pc8/.ssh/id_ecdsa: Нет такого файла или каталога
debug1: Попытка приватного ключа: /c/Users/pc8/.ssh/id_ecdsa_sk
debug3: нет такой идентичности: /c/Users/pc8/.ssh/id_ecdsa_sk: Нет такого файла или каталога
debug1: Попытка приватного ключа: /c/Users/pc8/.ssh/id_ed25519
debug3: нет такой идентичности: /c/Users/pc8/.ssh/id_ed25519: Нет такого файла или каталога
debug1: Попытка приватного ключа: /c/Users/pc8/.ssh/id_ed25519_sk
debug3: нет такой идентичности: /c/Users/pc8/.ssh/id_ed25519_sk: Нет такого файла или каталога
debug1: Попытка приватного ключа: /c/Users/pc8/.ssh/id_xmss
debug3: нет такой идентичности: /c/Users/pc8/.ssh/id_xmss: Нет такого файла или каталога
debug2: мы не отправили пакет, отключить метод
debug1: Больше нет методов аутентификации для попытки.
[youruser]@[yourLinode]: отказано в доступе (publickey).
Я не могу сильно понять, глядя на эти шаги. Я вижу 1 ошибку, которая говорит, что файл не найден. Скриншот
Не мог бы кто-нибудь подсказать, является ли это ошибкой, которую мне нужно исправить, чтобы подключиться к серверу. Если да, то пожалуйста, дайте мне знать, где мне нужно создать этот файл (/etc/ssh/ssh_known_hosts).
Также, если это не ошибка, то мог бы кто-то помочь мне понять шаги отладки и направить, в чем может быть проблема.
Я использую GitBash на Windows для подключения к серверу.
Пожалуйста, дайте мне знать, если нужны дополнительные данные с моей стороны.
Выделенная вами строка выглядит как ошибка, но это нормально. Чуть выше вы можете увидеть, что ваш клиент успешно нашел файл с именем known_hosts и нашел там ключ удаленного хоста. Этот файл не нужен для успешного подключения, но клиент SSH использует его, чтобы отслеживать ключи, которым он уже доверяет, таким образом вам нужно проверять отпечаток ключа только один раз.
Настоящая проблема очевидна в конце вывода, который вы вставили: серверная сторона поддерживает только аутентификацию по открытому ключу, но клиент не находит приватный SSH ключ ни в одном из обычных мест, поэтому он не может аутентифицировать вас на сервере. Вы не сможете подключиться, пока это не будет исправлено.
Включенная вами информация об отладке содержала эту строку:
debug1: Удаленная версия протокола 2.0, удаленная версия программного обеспечения Platform.sh
Это означает, что вы пытаетесь подключиться к среде, размещенной компанией Platform.sh. Вы можете найти дополнительную информацию о том, как это сделать, в публичной документации на странице Надежное подключение через SSH. Вы можете установить CLI Platform.sh и позволить ей автоматически настроить ваш SSH клиент, или вы можете сгенерировать собственную пару ключей, а затем добавить открытый ключ в свою учетную запись Platform.sh. Вы можете использовать это руководство на GitHub, чтобы узнать, как сгенерировать ключ, это должно нормально работать в Git Bash на Windows.
Если вы собираетесь часто взаимодействовать с проектом, вам будет удобнее сделать это после установки CLI Platform.sh, но если вы предпочитаете нет, вы можете сгенерировать и добавить ключ без CLI.
Наконец, если у вас нет учетной записи Platform.sh, вы можете попросить вашего разработчика прислать приглашение, используя эти инструкции.
Вам нужно запустить ssh-gen-key на вашем локальном компьютере, а затем скопировать открытый ключ(и), который он создает, в файл ~/.ssh/authorized_keys на удаленной системе. Открытые ключи заканчиваются на *.pub; не копируйте приватные ключи, которые не имеют этого расширения имени файла.
Существует программа ssh-copy-id, которая сделает копию, если вы сможете войти с помощью пароля. В противном случае вам придется сделать копию каким-то другим способом.
Еще одной возможной причиной этого сообщения об ошибке является проблема с конфигурацией на стороне сервера.
Проверьте, включена ли аутентификация по паролю на вашем сервере.
Откройте файл /etc/sshd_config и убедитесь, что следующая строка существует:
PasswordAuthentication yes
Ответ или решение
Ошибка "Permission denied (publickey)" является стандартной проблемой, с которой сталкиваются пользователи SSH при попытке подключиться к серверу. Давайте разберем, что может быть причиной этой проблемы и как ее исправить.
1. Причины возникновения ошибки
Ошибка указывает на то, что сервер не распознал или не принял ваш открытый ключ для аутентификации. Вот несколько распространенных причин:
- Отсутствие ключа: На вашем компьютере нет соответствующего закрытого ключа, который должен соответствовать открытому ключу, добавленному на сервер.
- Неправильный ключ: Если закрытый ключ не совпадает с открытым ключом, добавленным на сервер, это также приведет к подобной ошибке.
- Ошибки конфигурации сервера: Сервер может быть настроен так, чтобы использовать только аутентификацию с помощью ключей, и игнорировать другие методы (например, пароли).
2. Проверка наличия ключей
Сначала необходимо проверить, есть ли у вас SSH ключи на вашей машине. Для этого выполните следующую команду в Git Bash:
ls ~/.sshВы должны увидеть файлы с названиями, например, id_rsa (закрытый ключ) и id_rsa.pub (открытый ключ). Если таких файлов нет, вам нужно их сгенерировать.
3. Генерация SSH ключей
Если у вас нет ключей, выполните следующее:
ssh-keygen -t rsa -b 2048 -C "your_email@example.com"
Следуйте инструкциям на экране и подтверждайте все настройки по умолчанию (нажмите Enter). Это создаст два файла: закрытый ключ (id_rsa) и открытый ключ (id_rsa.pub).
4. Добавление открытого ключа на сервер
Теперь необходимо добавить открытый ключ на сервер. Обычно это делается следующим образом:
- Скопируйте содержимое вашего открытого ключа:
cat ~/.ssh/id_rsa.pub- Войдите на сервер, используя другой доступный метод (например, пароль, если это возможно) и добавьте открытый ключ в файл
~/.ssh/authorized_keys:
echo "ваше_содержимое_файла_id_rsa.pub" >> ~/.ssh/authorized_keys5. Проверка конфигурации сервера
Убедитесь, что на сервере включена аутентификация по паролю (если вы хотите использовать её как резервный вариант):
- Откройте файл конфигурации SSH на сервере:
sudo nano /etc/ssh/sshd_config- Убедитесь, что строки, касающиеся аутентификации, имеют следующий вид:
PubkeyAuthentication yes
PasswordAuthentication yes- Сохраните изменения и перезапустите службу SSH:
sudo systemctl restart sshd6. Подключение к серверу
Теперь попробуйте снова подключиться к серверу с помощью SSH:
ssh -vvv [youruser]@[yourLinode]7. Анализ вывода отладки
В случае, если ошибка все еще сохраняется, проверьте отладочную информацию, выводимую командой ssh -vvv. Обратите внимание на строки, где упоминается о ключах. Это покажет, какие ключи использовались и были ли они найдены.
Резюмируя, основная проблема заключается в том, что ваш SSH клиент не может найти подходящий закрытый ключ для аутентификации к серверу. Следуйте указанным шагам для его создания и настройки, и это должно помочь вам успешно подключиться к серверу через SSH. Если вам нужны дополнительные разъяснения или помощь, не стесняйтесь спрашивать.