Damien Miller wrote:>This is ssh trying to connect to $SSH_AUTH_SOCK, perhaps JuiceSSH's >agent that you've forwarded. > ... >the sudo is probably clearing $SSH_AUTH_SOCK and so it doesn't >try to connect to it. > >You can simulate this by clearing the environment variable yourself and >see if the hangs persist. > >If it is the forwarded agent, then the problem is probably in JuiceSSH >but I'm not able to offer any debugging advice for that, sorry.I replied privately by accident. The list was CC'd, not primary. Damien's analysis is absolutely correct. This annoyance has bothered me for a long time. The necessary description was tedious enough to inhibit me from asking for help. No need to fix JuiceSSH. It's authors ignore all contact anyway. Fixed on my system with a simple bash command: "alias xssh="unset SSH_AUTH_SOCK; ssh". -- Dave Close, Compata, Irvine CA +1 714 434 7359 dave at compata.com dhclose at alumni.caltech.edu "Reality leaves a lot to the imagination." -- John Lennon
On Fri, 23 Aug 2024, Dave Close wrote:>No need to fix JuiceSSH. It's authors ignore all contact anyway. Fixed >on my system with a simple bash command: > "alias xssh="unset SSH_AUTH_SOCK; ssh".Or you could put the unset into .ssh/rc, or if you use a key to connect from JuiceSSH to machine1 you could add the restrict keyword to the corresponding authorised_keys line (and then unrestrict anything else you actually need). bye, //mirabilos -- 15:41?<Lo-lan-do:#fusionforge> Somebody write a testsuite for helloworld :-)
On 24.08.24 03:16, Dave Close wrote:> Damien Miller wrote: >> This is ssh trying to connect to $SSH_AUTH_SOCK, perhaps JuiceSSH's >> agent that you've forwarded. > > No need to fix JuiceSSH. It's authors ignore all contact anyway. Fixed > on my system with a simple bash command: > "alias xssh="unset SSH_AUTH_SOCK; ssh".[scratches head] If JuiceSSH's forwarded agent reliably refuses to serve, why not simply tell it to stop doing such a forward ... ? On another note, the fact that you apparently do not need an agent to authenticate the SSH connections from the first jump host onward is (I hope) not a common situation. I suspect that the more general approach would be to start a *new* agent on the jump host (which should hijack $SSH_AUTH_SOCK with a *working*, albeit "not running quite where you'd expect it to", agent). Assuming that the keypair(s) on your Android exist *only* there, I'd try giving the pubkey in the jump host's authorized_keys a command="..." option to run something that starts the new agent and lets the sub-shell execute $SSH_ORIGINAL_COMMAND (or turn into an interactive login shell if the env var is empty). Kind regards, -- Jochen Bern Systemingenieur Binect GmbH -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3447 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20240824/3c5c89e8/attachment.p7s>