Что тип файла идентификационных данных означает в messags отладки SSH?
Я отлаживал соединение SSH с помощью следующей команды:
ssh -vT user@mysite.com
И я получил следующие сообщения:
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to smilescooter.com port 22.
debug1: Connection established.
debug1: identity file /Users/jerry/.ssh/id_rsa type 0
debug1: key_load_public: No such file or directory
debug1: identity file /Users/jerry/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/jerry/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/jerry/.ssh/id_dsa-cert type -1
debug1: identity file /Users/jerry/.ssh/id_ecdsa type 2
debug1: key_load_public: No such file or directory
debug1: identity file /Users/jerry/.ssh/id_ecdsa-cert type -1
...
debug3: hostkeys_foreach: reading file "/Users/jerry/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /Users/jerry/.ssh/known_hosts:19
debug3: load_hostkeys: loaded 1 keys from smilescooter.com
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
К счастью проблема была решена, но мне интересно как, чем "файлом идентификационных данных file_route тип n", средний, n, здесь мог быть-1,0,1,2...
И что делает число (1/2/3..) после отладки, средней в начале каждой строки отладки?
Я не спросил бы это здесь, если я нашел поиск с помощью Google результатов об этом. Существует много результатов в Google относительно отладки задач SSH, но никто, кажется, не говорит о двух, которые я спросил здесь.
Огромное спасибо заранее.
2 ответа
Файл идентификационных данных является просто закрытым ключом (или сертификат), обычно создаваемый путем выполнения ssh-keygen. Это по умолчанию создаст ключ RSA, но можно изменить это с -t опция. Согласно Вашему выводу, у Вас есть RSA и ключ ECDSA.
Число в identity file type .../.ssh/id_* type <number> просто целочисленное значение (базирующийся нуль) sshkey_types перечисления и-1 ошибки значения (как с большинством функций POSIX). Вы видите, что имена файлов содержат также ключевой тип:
enum sshkey_types {
KEY_RSA, // id_rsa has type 0
KEY_DSA, // id_dsa has type 1, but as you have no id_dsa key file, -1 is used
KEY_ECDSA, // id_ecdsa has type 2
...
Сообщения об ошибках key_load_public: Никакой такой файл или каталог после файла идентификационных данных... не обменивается сообщениями, является странным, кажется, что соответствующие файлы с открытым ключом были удалены. Они несут то же имя файла как закрытый ключ с добавленным .pub суффикс. Это не трагично, поскольку открытый ключ может быть повторно создан от закрытого ключа (но не наоборот по очевидным причинам) с ssh-keygen -y.
Вывод отладки объяснен в этой хорошей статье Wikibooks о входе OpenSSH. Короче говоря: число в отладке [123]:... префикс строки указывает на уровень отладки сообщения позади него. Это соответствует количеству -vs Вы дал на командной строке (с 3 являющийся максимумом). Т.е. если Вы устанавливаете -v, сообщения debug1 будут распечатаны, с -vv Вы получите debug1 и debug2 и т.д. (Немного странно, что Вы получаете сообщения debug3 даже при том, что Вы только дали сингл -v, хотя)
Как вывод предполагает, "тип n" является внутренним идентификатором ключевого типа (RSA, ECDSA, ED25519, и т.д.). Список виден в sshkey.c.
Точно так же n после debug уровень отладки. Вывод, который Вы показали, для -vvv, или отладка, регистрирующаяся до уровня 3 (максимум), следовательно debug1, debug2 и debug3.
Полное изложение обоих было бы обычно полезно только для разработчиков OpenSSH (прежде всего, разработчики OpenBSD), таким образом, я не буду ожидать, что это будет обычно обсуждено.