я читаю Эта статья по настройке автоматического резервного копирования в Duplicity.
Я в части под названием 7.2. Кэширование ключей SSH
Я добавил в свой корень следующее .bash_profile
keychain --clear id_rsa
. /root/.keychain/www-sh
Статья заявляет, что связка ключей должна запуститься, и что на этом этапе у меня должен быть запрошен мой PASSPHRASE для моего закрытого ключа (/root/.ssh/id_rsa).
Я не получаю здесь ожидаемых результатов, хотя связка ключей действительно запускается, в этот момент она выдает некоторые предупреждения:
KeyChain 2.6.8; http://www.gentoo.org/proj/en/keychain/
Copyright 2002-2004 Gentoo Foundation; Distributed under the GPL
* Found existing ssh-agent (2014)
* ssh-agent: All identities removed.
* Warning: /root/.ssh/id_rsa.pub missing; can't tell if /root/.ssh/id_rsa is loaded
root@www:~#
Я нашел упоминание об этом в Форумы Gentoo но пользователи потока, похоже, озадачены тем, почему связка ключей запрашивает id_rsa.pub и мне было интересно, знает ли кто-нибудь, почему связка ключей запрашивает открытый ключ.
Я открыто признаю, что мне ничего не известно о внутренней работе связки ключей, но вполне разумно, что локальный агент ssh должен расстраиваться из-за того, что у него нет открытого ключа, соответствующего закрытому ключу, который у него есть.
Подумайте, что происходит, когда вы приближаетесь к удаленному серверу для аутентификации. Удаленный сервер знает, из своего authorized_keys файл, что он готов принять клиента, который может доказать, что у него есть соответствующий закрытый ключ для каждой записи в нем. Но как он требует этого от клиента? Он не может предоставить каждый закрытый ключ сам по себе или какие-либо его свойства, потому что у него их нет; все, что он может сделать, - это предоставить открытый ключ (ключи) или их отпечатки пальцев, которые он примет.
Если у клиента есть какой-либо из этих открытых ключей, он может немедленно выбрать соответствующий закрытый ключ и сделать ответ, который сервер примет как правильный. Если у него нет этих открытых ключей, что ему делать? Попробовать по очереди каждый закрытый ключ из своего репертуара? Трудно представить себе лучший рецепт раскрытия небезопасной информации; Черной шляпе достаточно было бы организовать атаку «человек посередине» на одно новое соединение, чтобы собрать законные ответы от каждого ключа в вашем связке ключей.
Возможно, пары ключей имеют какую-то внутреннюю нумерацию, но на это было бы совершенно произвольно и неразумно полагаться. Не существует гарантированного внутреннего свойства, связывающего закрытый и открытый ключи вместе, потому что ключи в паре ключей ничего не разделяют, кроме того, что один (надеюсь) единственный объект, который может отменить то, что делает другой.
Нет, лучший способ для клиента выбрать правильный закрытый ключ для использования на любом сервере - это иметь соответствующие открытые ключи, которые помогут ему в выборе ключа.
думаю keychain пытается быть более безопасным, чем программа, для которой он является помощником (ssh).
В моей текущей версии OpenSSH можно добавить закрытый ключ в ssh-agent с участием ssh-add без файла открытого ключа. После того, как вы это сделаете, вы можете увидеть, удалось ли это, как ssh-add -l также будет указано имя файла закрытого ключа. ssh будет использовать кэшированный ключ для подключения, даже если доступно более одного идентификатора. Попытка их по очереди явно упоминается в документации.
$ ssh -V
OpenSSH_7.2p2, OpenSSL 1.0.2g 1 Mar 2016
$ man ssh_config
...
IdentityFile
...
It is possible to have multiple identity files speci‐
fied in configuration files; all these identities
will be tried in sequence. Multiple IdentityFile
directives will add to the list of identities tried
(this behaviour differs from that of other configura‐
tion directives).
...
Я думаю, что лучше всего использовать AddKeysToAgent возможность ssh. Пароль будет запрашиваться только в первый раз в сеансе, если у вас есть ssh-agent доступный. В твоем .bashrc вы можете добавить просто eval $(keychain --eval --noask)