[Expired for openssh (Ubuntu) because there has been no activity for 60
days.]
** Changed in: openssh (Ubuntu)
Status: Incomplete => Expired
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
I am a bit confused by the bug report.
I think ssh-add is correctly adding the DSA key to the agent, and the
fact that running ssh-add again requests the password again is normal
and expected. Looks Trusty behaves the same:
ubuntu@paride-t:~$ eval $(ssh-agent -s)
Agent pid 2406
A bit more info because this bug came up again for me.
It was mentioned that this was working OK in Trusty, so I assume that
openssh 6.6 was being used there, and that when the upgrade to openssh
7.x happened this issue started happening. I agree that the tool itself
could be more helpful in its
Thank you for following up with this.
It seems like an interesting bug to consider, but it appears to be low
priority, so I am marking it as such.
On a side note, I would like to point out that these kind of bugs are
usually better dealt with by upstream, so I would recommend you to file
a
while you can certainly argue that the obsolete key was a configuration
issue, I'd find it surprising to see the missing warning about this
while silently pretending to be working just fine not to be considered a
bug.
** Changed in: openssh (Ubuntu)
Status: Incomplete => New
--
You
Rolf,
Thank you for taking the time to file a bug report.
I have just used the following in my .bashrc (like keychain man page
says so):
"""
keychain id_rsa id_dsa id_ecdsa
[ -z "$HOSTNAME" ] && HOSTNAME=`uname -n`
[ -f $HOME/.keychain/$HOSTNAME-sh ] && . $HOME/.keychain/$HOSTNAME-sh
[ -f
I finally was able to solve this. It turns out, my key was too old and
thus kind of disabled as a security measure, I suppose. After creating a
new key based off ED25519 and adding the corresponding public key to
~/.ssh/authorized_keys on the server, things are now working again.
Can we please do
** Description changed:
In the below example, on the second invocation of ssh-add I should not
be prompted to enter the passphrase again after I successfully entered
- it on the first instance.
+ it on the first instance. This used to work fine in trusty i386 setup.
$ keychain &&
8 matches
Mail list logo
