Почему / как SSH не может аутентифицироваться, если на * клиентской * машине есть фиктивный pubkey?

Question

На clienthost меня есть пара ключей pub:priv, хранящаяся как ~/.ssh/foo и ~/.ssh/foo.pub соответственно. На remotehost меня есть корректно существующий pubkey в ~/.ssh/authorized_keys , так что я могу войти, используя -i ~/.ssh/foo .

Логин (конечно) не зависит от существования clienthost:~/.ssh/foo.pub: Если я переименую ~/.ssh/foo.pub в ~/.ssh/bar.pub ничего не изменится.

Но если я изменю символ в clienthost:~/.ssh/foo.pub чтобы он по-прежнему выглядел как действительный pubkey, но больше не соответствовал privkey, я не могу войти. Почему бы и нет?

Почему / как SSH заботится о том, что дополнение pubkey к privkey не повреждено - и почему ${privkey}.pub - путь поиска?

Answer 1

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

В этом случае использования клиент считывает оба ключа (открытый и закрытый, хранящиеся в отдельных файлах), но ему не нужно запрашивать парольную фразу и не расшифровывает закрытую часть, если он не знает, что ключ принят сервером.

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