similar to: Can one set an agent timeout for a specific host?

On Wed, 5 Jun 2024 at 22:20, Chris Green <cl at isbd.net> wrote: > If I set a timeout for a specific host's key does it set the timeout > for just that key/host? [...] > Host backup > IdentityFile ~/.ssh/backup_id_rsa > IdentityAgent 600 I think you meant AddKeysToAgent? > Will it just time out the key saved for backup and leave any other > keys

On 2024/01/02 09:51, Chris Green wrote: > I think I have it! I need to unset SSH_AUTH_SOCK, that's all that's > needed. See:- > > chris$ ssh -i backup_id_rsa backup > [here the pop-up appears and I cancel it] > sign_and_send_pubkey: signing failed for RSA "backup_id_rsa" from > agent: agent refused operation > chris at backup's

> > There must be *something* in the environment that affects this because > I'm seeing two different ways of asking for the passphrase on the same > screen. The only difference is that one is a simple terminal window > running on my system and the other is one where I have used ssh to > connect to a remote system and then ssh again back to the 'home' > system.

Hi folks, I've got a moderate number of keys in my ssh config file. Problem: Very often I get an error message like Received disconnect from 2001:db8::8077 port 999:2: Too many authentication failures Authentication failed. AFAIU the ssh-agent is to blame here, trying out all keys he has ever seen. This conflicts with MaxAuthTries 6, set by default on the peer. The solution seems to be to

Hi, I usually have around 10 identities loaded in my local ssh-agent and when I use the "ForwardAgent" option all them are forwarded to the remote server, which is not ideal. I usually only need to forward one (or two) of the identities and I would like to be able to choose which one(s) to forward. Looking for solutions it seems that the only option is to create a new ssh-agent, add

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

A few options appear to be missing from the list in ssh's manual. The one I didn't add is EnableSSHKeysign, whose description implies it is only effective when placed in the system-wide config file. Index: ssh.1 =================================================================== RCS file: /cvs/src/usr.bin/ssh/ssh.1,v retrieving revision 1.319 diff -u -p -r1.319 ssh.1 --- ssh.1 7 May 2011

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:

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

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

Hello, I'm using Ruby's Shellwords module, which generates a string from an array, suitable for shell evaluation. Ruby's implementation prefers escaping whitespace with a backslash rather than quotes. However, this appears to cause some kind of issue in Rsync when it computes argv from -e option. Here is an example command generated by some Ruby code: rsync --archive --stats -e

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

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

On Wed, Sep 30, 2020 at 03:35:43PM +1000, Damien Miller <djm at mindrot.org> wrote: > On Wed, 30 Sep 2020, raf wrote: > > > 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:

https://bugzilla.mindrot.org/show_bug.cgi?id=3572 Bug ID: 3572 Summary: ssh-agent refused operation when using FIDO2 with -O verify-required Product: Portable OpenSSH Version: 9.3p1 Hardware: Other OS: Linux Status: NEW Severity: minor Priority: P5 Component:

https://bugzilla.mindrot.org/show_bug.cgi?id=3080 Bug ID: 3080 Summary: Document IdentityFile=none and clarify interaction of defaults with IdentitiesOnly Product: Portable OpenSSH Version: 8.0p1 Hardware: Other OS: All Status: NEW Severity: normal Priority: P5

http://bugzilla.mindrot.org/show_bug.cgi?id=207 ------- Additional Comments From jclonguet at free.fr 2003-04-22 05:08 ------- Created an attachment (id=273) --> (http://bugzilla.mindrot.org/attachment.cgi?id=273&action=view) Patch for OpenSSH-3.6.1p1 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

Fix and/or document issues raised in this thread: https://www.redhat.com/archives/libguestfs/2017-February/msg00010.html Rich.

The attached patch adds a new 'ConnectTimeout' option (man page updated in patch) to avoid wasting time when the target host is down. I needed that because I was using rsync/rdist over ssh for massive files update and the default connect() took too long for my purpose. The patch was tested on Linux only, but I used a similar one for ssh 1.2.XX on Linux, Solaris and HP-UX without