То, почему authorized_keys файл не мешает SSH предложить мне с “Подлинностью хоста <хост>, не может быть установлено”?
Я создал 2 пары ключей с помощью ssh-keygen, один на сервере и один на клиенте.
Я затем добавил открытый ключ сервера к файлу $HOME/.ssh/authorized_keys клиента, и наоборот.
Когда я пробую к ssh от клиента к серверу, меня все еще встречают
The authenticity of host <host> can't be established
ECDSA key fingerprint is SHA256:<hash>
Почему это происходит? Я ожидал бы в присутствии открытых ключей, аутентификация хоста могла быть установлена. Также я не создал ключ ECDSA сам, только RSA. Действительно ли это - сборка - в ключе?
3 ответа
Вы путаете проверку сервера с его ключом хоста (сделанный клиентом) с аутентификацией входа в систему пользователя SSH (сделанный сервером).
Подлинность хоста проверяется на клиенте с ключом хоста. Это должно предотвратить возможные нападения на MITM, симулирующие быть Вашим сервером. Ключи хоста сохраняются на сервере в /etc/ssh/ssh_host*key и на клиенте в ~/.ssh/known_hosts файл.
Соединение с использованием сервера ssh -vvv шоу это:
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:fYR10r/RKXIzOmJYbgbDi29E10oW7MLjto2plpALaBY
debug3: hostkeys_foreach: reading file "/home/xxxx/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/xxxx/.ssh/known_hosts:69
debug3: load_hostkeys: loaded 1 keys from xx.xx.xx.xx
debug1: Host 'xx.xx.xx.xx' is known and matches the ECDSA host key.
- Сервер отправляет ключ хоста
- Клиент ищет ключ
known_hosts - Клиент загружается и verfies ключ
Вы не должны вручную создавать ключ хоста, это сделано автоматически. На стороне клиента Вы не должны добавлять ключ хоста вручную, поскольку это сделано на первом соединении с сервером (Необходимо ввести 'да').
Когда ключ хоста изменяется из-за новой установки сервера, необходимо удалить тот ключ из known_hosts файл, иначе ssh отказывается соединяться, если Вы не имеете -o StrictHostKeyChecking=no набор опции, которому я не советовал бы, чтобы сделать.
Когда Вы добавили ssh ключ от своего сервера до Ваших клиентов authorized_keys файл, Вы авторизовываете соединения от своего сервера до Вашего пользователя на клиенте, который является, вероятно, не, что Вы хотите. Я советую Вам удалять ключ на стороне клиента.
Дальнейшее чтение:
Вы получаете это сообщение из-за "цифрового отпечатка ключа ECDSA", не общедоступный ключ RSA. Когда Вы копируете содержание файла с открытым ключом .pub кому: .ssh/known_hosts вручную, цифровой отпечаток не включен.
Если Вы смотрите на какую-либо другую запись в known_hosts в котором Вы уже приняли сообщение:
The authenticity of host '<host>' can't be established.
RSA key fingerprint is SHA256:fingerprint.
Are you sure you want to continue connecting (yes/no)?
Вы найдете строку, предшествующую типу ключа (ssh-rsa, ecdsa-sha2-nistp256, и т.д....). Это - цифровой отпечаток и может быть вручную вычислено с ssh-keygen -lf <public_key_file> (который расположен в /etc/ssh/ в Вашем сервере) или ssh-keygen -l -F <domain_or_ip> от Вашего клиента.
Кроме того, это сообщение является результатом опции StrictHostKeyChecking. Это сообщение активируется по умолчанию для безопасности, но может быть отключено с ssh -o "StrictHostKeyChecking=no" user@host, создание ssh цифровые отпечатки хранилища без любого сообщения (поскольку я сказал, не рекомендуемый).
Этот вопрос так или иначе связан с Вашим: https://serverfault.com/questions/422869/answer-yes-to-ssh-copy-id-first-time-run-by-script
Можно передать клиентский ключ к серверу (Вы не должны передавать ключ сервера к клиенту) путем выполнения:
ssh-copy-id <your-ssh-server-ip_or_hostname>
После этого можно войти в систему через пару ключей просто ssh <your-ssh-server-ip_or_hostname>
Править:
И Ваш ecdsa (ключ эллиптической кривой) является Вашим ключом сервера, та ключевая передача является автоматической. Ваш сервер был переустановлен, таким образом имея новый ключ сервера?
можно удалить ключ сервера от клиента путем выполнения:
ssh-keygen -R <your-ssh-server-ip_or_hostname>