similar to: Keys from -i should have precedence over agent keys

https://bugzilla.mindrot.org/show_bug.cgi?id=2642 Bug ID: 2642 Summary: [sshconnect2] publickey authentication only properly works if used first: pubkey_prepare doesn't work after pubkey_cleanup Product: Portable OpenSSH Version: 7.3p1 Hardware: amd64 OS: Linux Status:

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:

Allow users to specify certificates to be used for authentication on the command line with the '-z' argument when running ssh. For successful authentication, the key pair associated with the certificate must also be presented during the ssh. Certificates may also be specified in ssh_config as a CertificateFile. This option is meant the address the issue mentioned in the following

https://bugzilla.mindrot.org/show_bug.cgi?id=2095 Bug ID: 2095 Summary: ssh client not respecting IdentitiesOnly=yes option Classification: Unclassified Product: Portable OpenSSH Version: 6.2p1 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 Component: ssh

My keys are secured with a passphrase. That's good for security, but having to type the passphrase either at every login or at every invocation of ssh(1) is annoying. I know I could invoke ssh-add(1) just before invoking ssh(1), if I keep track of whether I invoked it already, or write some hacky scripts; but the rest of OpenSSH is wonderfully usable without any hacks. Hence, this patch.

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

https://bugzilla.mindrot.org/show_bug.cgi?id=3681 Bug ID: 3681 Summary: SSH Agent Certificate Not Recognized with 'IdentitiesOnly' Configured Product: Portable OpenSSH Version: 9.7p1 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 Component:

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

A co-worker argues we can login using only password to a "ssh-key restricted host (PasswordAuthentication no)", without being asked by any passphase; just by putting a key (no need to be the private key) on another password-based host. It that true? I do not think so. I would name that as an "important OpenSSH daemon security bug". That is because I think it is not true.

Hi Darren, On 4/1/19 10:41 AM, Darren Tucker wrote: > On Mon, 1 Apr 2019 at 08:12, Harald Dunkel <harald.dunkel at aixigo.de> wrote: >> I've got a moderate number of keys in my ssh config file. >> Problem: Very often I get an error message like > [...] >> The solution seems to be to set IdentitiesOnly, e.g.: > [...] >> Shouldn't an explicit

editors note: just now found something about IdentitiesOnly that might do the trick. there's some other stuff in here too. about preventing info leakage [keys for other sites] from appearing in the client<-->server key negotiation with ssh-agent and IdentityFile. ssh/config:IdentityFile - seems to indicate that only the specified key will be tried, and if that key fails, no other keys

> ssh should do this already Hi Damien, Let's discuss what it does already... For example, if ssh-agent already has six keys, will it append the "-i key" as the seventh choice? Apparently there is a "six-key authentication limit on most servers". A seventh key will fail. If ssh is adding the new key to the end of the list it would be expected to fail. This limit is

Trying to get SSH agent forwarding working for a popular open source configuration management system called Ansible. I?ve had some unexpected behaviour, the only cause of which I can find is how I express the command line arguments. http://stackoverflow.com/questions/20952689/vagrant-ssh-agent-forwarding-how-is-it-working?noredirect=1#comment31511341_20952689 In summarise: In the first

It seems that users may be disclosing unintended public key info when logging into remote hosts. Use of the words keypair/keyid/etc have been bastardized. Signature is likely better. Note also, the author may be without clue. Setup: [g] - refers to an administrative group of hosts [n] - refers to a host within that group ws[g][n] - management workstations [trusted] User ssh-add's keys for

I wanted to draw attention to this bug report [A] which highlights a change that was made between Mocha 0.4 and 0.5. It may have lead to tests which pass unexpectedly. Does my explanation (below) make sense to people? It feels like we should at least add some warnings to the documentation. You are correct that this behaviour did change between Mocha v0.4.0 and > v0.5.0 (in revision 115).

> A problem with that, it's a bit cumbersome. You have to realize what the > cause of the problem, so that adding the flag will fix it (why is ssh > failing anyway?). And then check the exact syntax. And write that, on the > command-line. It is another option though. Personally, I set IdentitiesOnly yes as the global default in ~/.ssh/config, and explicitly set the preferred key

Hey everyone, I hope this isn't an old issue; I wasn't able to locate it in the archives. I have a number of scripts which make use of ssh -i and scp -i, where the target host has the specified key in its authorized_keys file with a command= override to do immediate processing of the received data. This works extremely well, as we are able to establish single-function, triggered-action

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=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:

I have been looking into this over the weekend, and what I have found might be of interest to OpenSSH developers. First, the bug that triggers the problem is in the embedded system. Second, such as things were changed in 6.4p1, the OpenSSH client seems to be open to a potential DoS attack. The infinite loop described in my previous post is embodied in the last four messages of the 6.4p1 traces.