search for: ssh_auth_sock

The idea behind this change is to add support for different "ssh-agents" being able to run at the same time. It does not change the current behaviour of the ssh-agent (which will set SSH_AUTH_SOCK just for itself). Neither does it change the behaviour of SSH_AGENT_PID (which still supports only one pid). The new implementation will go through the list of sockets (which are separated by a colon (:)), and will return the very first functional one. An example of the new supported syntax is: SSH...

https://bugzilla.mindrot.org/show_bug.cgi?id=2480 Bug ID: 2480 Summary: Support a list of sockets on SSH_AUTH_SOCK Product: Portable OpenSSH Version: 7.1p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: ssh-agent Assignee: unassigned-bugs at mindrot.org Reporter: fabi...

Hi all, i'm trying to figure out if i'm being silly or if there is a genuine problem. Running on the notorious Redhat 7, 2.2.16-22 #1, X86. [user at host]$ ssh-agent -s SSH_AUTH_SOCK=/tmp/ssh-XXYFcFR6/agent.2101; export SSH_AUTH_SOCK; SSH_AGENT_PID=2102; export SSH_AGENT_PID; echo Agent pid 2102; [user at host]$ echo $SSH_AUTH_SOCK [user at host]$ echo $SSH_AGENT_PID [user at host]$ ssh-add Could not open a connection to your authentication agent. [user at host]$ ls -l /tmp/s...

http://bugzilla.mindrot.org/show_bug.cgi?id=500 ------- Additional Comments From djm at mindrot.org 2003-02-24 12:43 ------- I think that: [ -z "$SSH_AUTH_SOCK" ] && eval `ssh-agent -s` [ -z "$SSH_AGENT_PID" ] || ssh-add -l >/dev/null 2>&1 || ssh-add Is as effective and a lot more concise. On the other hand, fragile heuristics like: > export SSH_AUTH_SOCK=`ls /tmp/ssh-*/agent.$SSH_AUTH_PID` have no place in our doc...

...m 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. The local system window gets the GUI pop-up the 'two ssh' > window asks for the passphrase in the terminal. > 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 password: chris$ env | grep...

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...

...variables aren't being passed to the spawned shell. sol# env | wc -l 23 sol# env | grep -i ssh SSH_CLIENT=10.0.1.146 1047 22 SSH_TTY=/dev/pts/0 sol# sol# ssh-agent sh sol# env | wc -l 1 sol# env SSH_AGENT_PID=12032 sol# If I set SSH_AUTH_SOCK manually, ssh-agent (and ssh-add) does function properly... sol# find /tmp -name 'agent*' -exec ls -l {} \; srwxr-xr-x 1 root other 0 Feb 20 14:07 /tmp/ssh-Lfa12009/agent.12009 sol# sol# SSH_AUTH_SOCK=/tmp/ssh-Lfa12009/agent.12009 sol# export SSH_AUTH_SOC...

...ronment. >> >> As a proof of concept I wrote a standalone ssh-agent that _unlink_ the >> current running agent in the guest machine and creates its socket in >> the same path used by the old agent. > > unlinking the socket seems a bit overkill. You could play with > SSH_AUTH_SOCK Playing with SSH_AUTH_SOCK may be a bit problematic. As far as I understand it would require a session restart in order to set a new value to the env var (at least using GNOME). Btw, I would like to be really clear here that I am focused in a DE-agnostic solution. :-) > > > >> A f...

https://bugzilla.mindrot.org/show_bug.cgi?id=2216 Bug ID: 2216 Summary: allow forwarding a different socket than SSH_AUTH_SOCK Product: Portable OpenSSH Version: 6.5p1 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: ssh Assignee: unassigned-bugs at mindrot.org Reporter: chrysn at fsfe...

...ed. If a maintainer can confirm that this is an acceptable fix, I may be able to write a patch. Environments reproduced on: Ubuntu 19.10, Fedora Version of OpenSSH: git commit b2491c28, latest at time of writing. Example output demonstrating the problem (with a Yubikey in PIV mode inserted): $ SSH_AUTH_SOCK=/tmp/ssh-dhfNCpXwSk8B/agent.21022; export SSH_AUTH_SOCK; $ ssh-add -s /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so Enter passphrase for PKCS#11: Could not add card "/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so": agent refused operation $ SSH_AUTH_SOCK=/tmp/ssh-RORElJeiiHBc/agent.21116; expo...

Dear friends, First, thanks for helping me on ssh default option for smartcards. I recompiled SSH from CVS and it seems to work. I still have problems with: ssh-add -s /usr/lib/opensc-pkcs11.so Enter passphrase for PKCS#11: (I enter PIN code) SSH_AGENT_FAILURE Could not add card: /usr/lib/opensc-pkcs11.so pkcs11-tool --slot 1 -O Public Key Object; RSA 2048 bits label: Public Key ID:

...? > > One obvious approach is to create a proxy agent which looks like an > agent to all clients, but which also integrates with SPICE. This is a good solution, probably the best one. The main problem is how to implement it. We have two clear ways for adding a proxy agent. One is with the SSH_AUTH_SOCK supporting a list of sockets, but it won't be dynamically. In other words, if I want to replace the spice-agent for another one, it would, most likely, require a session restart and it's not exactly good :-\ The other option would be extend the ssh-agent protocol to support a few new operat...

...imit it to do just some operations (like, ssh-add .ssh/id_rsa probably must not go to the spice agent). But how to do that? What could be a good approach for doing that? Expand the agent protocol in order to have a "ssh-add --proxy /path/to/the/new/agent/socket" can be one option. Making SSH_AUTH_SOCK support a list of agents is another option, then the first agent would be the "dispatcher". These are the questions that I have and I am open to suggestions/further discussions. Best Regards, -- Fabiano Fid?ncio

Folks, MacOSX 10.6.x (Snow Leopard) runs { ssh-agent -l }; that's not an s/ssh-add/ssh-agent/ typo. It appears to be an undocumented addition (the man-pages were not updated). I *suspect* that it just tells the agent to honour whatever pre-existing value of $SSH_AUTH_SOCK it inherits and to try to listen to that. I don't know for sure. Does anyone have details on what exactly it does, please? I'm tempted to hack a more recent OpenSSH's ssh-agent to support it, so I can switch which agent is launched by launchd and then load ECDSA keys. Thanks, -Phil

...4, Christian Weisgerber wrote: > > > Chris Green: > > > > > Setting SSH_ASKPASS_REQUIRE=never in the environment on my xubuntu > > > 23.10 system doesn't seem to work. I have set it:- > > > > > > chris$ env | grep SSH > > > SSH_AUTH_SOCK=/run/user/1000/keyring/ssh > > > SSH_ASKPASS_REQUIRE=never > > > > What component is actually calling ssh-askpass? > > > > Setting SSH_ASKPASS_REQUIRE=never has no effect for me either, but > > that's because... > > > > Jan 1 21:26:12 l...

...he certificate, and it should not do so. You can have the command check if the cert is expired or near expired before refreshing it. I've done this in the past with expiring certificates. > This would be more useful if ssh could _start_ the agent. This is difficult because ssh relies on $SSH_AUTH_SOCK in its environment to find the agent's socket. In normal use, the way this works is usually one of: - the agent is started before the shell (eg by a desktop environment), the shell inherits SSH_AUTH_SOCK from the window manager or equivalent and ssh inherits it from the shell. - the agent...

Some systems like to have a CA supply short-lived certificates to ssh clients. The basic idea is that servers enable certificate authentication, clients authenticate to the CA out of band, and the CA issues client certificates that are valid for a short enough time that users don't want to manually drop them into ~/.ssh or otherwise think about them. There are a handful of commercial

On 09/13/2018 07:54 PM, Darren Tucker wrote: > I'd guess that the reason it doesn't work is that the key is encrypted > and neither the agent nor a tty to ask for the decryption passphrase > is available. Try repeating your command line test after unsetting > SSH_AUTH_SOCK > Okay. That reproduced the issue. Is there a recommended way to provide the decryption passphrase? $ export SSH_AUTH_SOCK="" $ bin/sftp-sma-download command: /usr/bin/sftp -P 1022 -p -o GSSAPIAuthentication=no -i /home/xxx/.ssh/jumpline -b /home/xxx/bin/sftp-sma-download-batch y...

...ing is not working for me. The best troubleshooting guide that I found, and also the one I've been using, is the ssh forwarding guide on github - https://help.github.com/articles/using-ssh-agent-forwarding I've checked all things there, yet it is just still not working. E.g., echo "$SSH_AUTH_SOCK" shows correctly on the server and my local machine, and I have checked both .ssh/config and /etc/ssh_config and /etc/ssh/sshd_config on the server (machine B) - they're all set up correctly. However, the forwarding doesn't seem to be actually working - "ssh -T git at github.com&...

..._AGENT_PID environment), but I get the > > following error: > > kill: No such process > > > > Can you please explain why there is no agent? > > When you run: > > eval `ssh-agent` I didn't run eval `ssh-agent` but ssh-agnet and then ssh-add (I needed the SSH_AUTH_SOCK that return from ssh-agent since I am running two different processes). I guess I can read the environment SSH_AUTH_SOCK after run eval `ssh-agent`... do you think there is a different between running with to without eval? Shahar. > > ssh-agent starts up and creates several environment...