Я открыто признаю, что ничего не знаю о внутренней работе связки ключей, но вполне разумно, что локальный агент ssh должен расстраиваться из-за отсутствия открытого ключа, соответствующего закрытому ключу, который это действительно так.
Подумайте, что происходит, когда вы приближаетесь к удаленному серверу для аутентификации. Удаленный сервер знает из своего файла authorized_keys
, что он готов принять клиента, который может доказать, что у него есть соответствующий закрытый ключ для каждой записи в нем. Но как он требует этого от клиента? Он не может предоставить каждый закрытый ключ сам по себе или какие-либо его свойства, потому что у него их нет; все, что он может сделать, - это предоставить открытый ключ (ключи) или их отпечатки пальцев, которые он примет.
Если у клиента есть любой из этих открытых ключей, он может сразу выбрать соответствующий закрытый ключ и дать ответ, который сервер примет как правильный. Если у него нет этих открытых ключей, что ему делать? Попробовать по очереди каждый закрытый ключ из своего репертуара? Трудно представить себе лучший рецепт раскрытия небезопасной информации; черная шляпа должна была бы организовать атаку «злоумышленник посередине» только на одно новое соединение, чтобы собрать допустимые ответы от каждого ключа в вашей связке ключей.
Возможно, пары ключей имеют какую-то внутреннюю нумерацию, но на это было бы совершенно произвольно и неразумно полагаться. Не существует гарантированного внутреннего свойства, связывающего закрытый и открытый ключи вместе, потому что ключи в паре ключей не имеют ничего общего, кроме того, что один (надеюсь) единственный объект, который может отменить то, что делает другой.
Нет,
Я думаю, что связка ключей
пытается быть более безопасной, чем программа, для которой она является помощником ( ssh
).
На мой В текущей версии OpenSSH можно добавить закрытый ключ к ssh-agent
с помощью ssh-add
без файла открытого ключа. После того, как вы это сделаете, вы увидите, удалось ли это, поскольку ssh-add -l
также отобразит имя файла закрытого ключа. ssh
будет использовать кэшированный ключ для подключения, даже если доступно более одного идентификатора. Попытка их по очереди явно упоминается в документации.
$ ssh -V
OpenSSH_7.2p2, OpenSSL 1.0.2g 1 марта 2016 г.
$ man ssh_config
...
IdentityFile
...
Можно указать несколько файлов идентификации.
хранится в файлах конфигурации; все эти личности
будут пробовать последовательно. Множественный IdentityFile
директивы добавят в список проверенных идентификаторов
(это поведение отличается от поведения других конфигураций
ции директив).
...
Я думаю, что лучше всего использовать параметр AddKeysToAgent
для ssh
. Пароль будет запрашиваться только в первый раз в сеансе, если у вас есть ssh-agent
. В свой .bashrc
вы можете добавить только eval $ (keychain --eval --noask)