similar to: [Bug 448] ssh ignores key specified with -i if agent is running

http://bugzilla.mindrot.org/show_bug.cgi?id=448 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2004-03-30 16:12

http://bugzilla.mindrot.org/show_bug.cgi?id=448 ------- Additional Comments From ssh-bugzilla at andrew.pimlott.net 2003-02-12 01:57 ------- I'm not sure how you mean that turning off the agent might break things, but it is obviously wrong for -i to be ignored. Why can't you simply try keys specified with -i before trying the agent? You may need to lists of keys rather than one:

http://bugzilla.mindrot.org/show_bug.cgi?id=448 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|trivial |enhancement ------- Additional Comments From markus at openbsd.org 2002-11-28 21:37 ------- having -i automagically turning off the

https://bugzilla.mindrot.org/show_bug.cgi?id=2024 Priority: P5 Bug ID: 2024 Assignee: unassigned-bugs at mindrot.org Summary: Allow to ssh client say to ssh-agent which key should be used. Severity: enhancement Classification: Unclassified OS: Linux Reporter: pub at mnu.pp.ru Hardware:

http://bugzilla.mindrot.org/show_bug.cgi?id=448 Summary: ssh ignores key specified with -i if agent is running Product: Portable OpenSSH Version: older versions Platform: All OS/Version: Linux Status: NEW Severity: trivial Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org

http://bugzilla.mindrot.org/show_bug.cgi?id=684 Summary: ssh cannot access keys stored in agent Product: Portable OpenSSH Version: 3.7.1p1 Platform: UltraSparc OS/Version: Solaris Status: NEW Severity: major Priority: P2 Component: ssh AssignedTo: openssh-bugs at mindrot.org ReportedBy:

https://bugzilla.mindrot.org/show_bug.cgi?id=2066 Bug ID: 2066 Summary: ssh tries the keys proposed by the agent before those passed with -i Classification: Unclassified Product: Portable OpenSSH Version: 6.0p1 Hardware: All OS: Linux Status: NEW Severity: normal

https://bugzilla.mindrot.org/show_bug.cgi?id=2331 Bug ID: 2331 Summary: ssh-copy-id -i id_new.pub fails to copy that id, also: wrong error msg Product: Portable OpenSSH Version: -current Hardware: All OS: Linux Status: NEW Severity: major Priority: P5 Component:

https://bugzilla.mindrot.org/show_bug.cgi?id=1834 Summary: OpenSSH ignores keys in ~/.ssh/config and offers keys from Seahorse instead Product: Portable OpenSSH Version: 5.6p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo:

https://bugzilla.mindrot.org/show_bug.cgi?id=3153 Bug ID: 3153 Summary: Prefer user specified keys to avoid the agent overloading MaxAuthTries before even trying the key that was specified Product: Portable OpenSSH Version: 8.2p1 Hardware: Other OS: Linux Status: NEW

There are cases when a user might have multiple keys in ssh-agent, but wants to use a specific one. Unless I'm mistaken, this is currently impossible. I've put together a proof of concept using the key's "filename" (the third column in the output of 'ssh-add -l') and it works. Is this a new feature that would be accepted? If so, should the key be identified with its

I've noticed that the ssh-agent applies any keys it already has passwords for (via ssh-add) first, overriding the ssh config files for preferred identity file from .ssh/config and -i. This seems a documented behavior. However, this causes problems with some tool chains that use the authorized_keys command directive to change behavior based on which key is used. In my case, I use gitolite for

https://bugzilla.mindrot.org/show_bug.cgi?id=1898 Summary: possible unreasonable behaviour when using ProxyCommand with multiple IdentityFile(s) Product: Portable OpenSSH Version: 5.8p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Miscellaneous

https://bugzilla.mindrot.org/show_bug.cgi?id=2221 Bug ID: 2221 Summary: Explicit identity files are being used after implicit files are attempted Product: Portable OpenSSH Version: 6.2p1 Hardware: Other OS: Linux Status: NEW Severity: minor Priority: P5 Component:

Hi, I have a VM with a git repository whose origin is on github. I have several keys known to github, so I needed to set git's core.sshcommand config parameter in the repository to something like this: ssh -i ~/.ssh/id_ed25519_github2 But it meant that I needed to copy that key to the VM. The same key is available via my forwarded ssh-agent connection. Is it possible to tell ssh to use

https://bugzilla.mindrot.org/show_bug.cgi?id=1914 Summary: ssh-add: add an option to cryptographically verify if agent can access the matching private key of a given public key Product: Portable OpenSSH Version: 5.8p2 Platform: All OS/Version: Linux Status: NEW Severity: enhancement

http://bugzilla.mindrot.org/show_bug.cgi?id=1159 Summary: %u and %h not handled in IdentityFile Product: Portable OpenSSH Version: 4.3p2 Platform: All URL: http://www.math.ualberta.ca/imaging/snfs/openssh.html OS/Version: Linux Status: NEW Keywords: patch Severity: normal Priority: P2

https://bugzilla.mindrot.org/show_bug.cgi?id=2284 Bug ID: 2284 Summary: ssh-copy-id option to replace one key with another key (or ssh-replace-id command) Product: Portable OpenSSH Version: 6.6p1 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5

(please CC me in replies, I'm not subscribed) I do have the following problem: When adding more than 7 keys to ssh-agent (openssh-3.7.1p2/Linux 2.4) only the first 7 keys work. All other keys fail when trying to set up a ssh connection with: Received disconnect from *.*.*.*: 2: Too many authentication failures for ***** Note: *=censored All keys work when added to ssh-agent as one of

https://bugzilla.mindrot.org/show_bug.cgi?id=2617 Bug ID: 2617 Summary: sign_and_send_pubkey: no separate private key for certificate Product: Portable OpenSSH Version: 7.3p1 Hardware: 68k OS: Mac OS X Status: NEW Severity: normal Priority: P5 Component: ssh