New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sign_and_send_pubkey: signing failed: agent refused operation #397
Comments
|
It's probably |
|
Reported the issue to OpenSSH and there is now an OpenSSH bug open. |
|
Thanks! |
st-probe: Fix hang when user has no libusb access
|
Hi, do you think there will be a fix for this at some point? It is really annoying since it means I cannot use the agent on my phone and always have to enter my password when I do thinks like git pull. |
|
BTW, the problem occurs when I use connectbot to connect to an amd64 Ubuntu zesty machine (openssh-client 1:7.4p1-10) and then from there to an armhf Ubuntu xenial machine (openssh-client 1:7.2p2-4ubuntu2.2). However, interestingly the problem does not happen the other way around. |
|
I think this is a bug I reported to OpenSSH a while ago:
https://bugzilla.mindrot.org/show_bug.cgi?id=2568
…On Thu, Aug 10, 2017 at 3:42 PM, Sebastian Unger ***@***.***> wrote:
BTW, the problem occurs when I use connectbot to connect to an amd64
Ubuntu zesty machine (openssh-client 1:7.4p1-10) and then from there to an
armhf Ubuntu xenial machine (openssh-client 1:7.2p2-4ubuntu2.2).
However, interestingly the problem does not happen the other way around.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#397 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AADE56VMIc1s3qSAK6d29KxHsYFxVYGsks5sWrR0gaJpZM4Ia0c5>
.
|
|
Is connect-bot using openssh under the hood? If so, then this could also be solved by updating the openssh implementation (in particular the agent) that ConnectBot uses instead of waiting for upstream to solve this. ConnectBot is far less useful without agent-forwarding. |
|
If I interpret the latest comment on the upstream bug-report correctly, then they consider the current behaviour (failure to use keys) the lesser of two evils (usability vs security) and that the only solution is to get agents updated. This puts the ball back into connect-bot's court. Is it difficult for connect-bot to update the agent? |
|
@kruton (and anyone else reading along here) just wanted to let you know that using auth agent with ConnectBot 1.9.6 to a host with e.g. OpenSSH 8.1 (which includes the bug released with openssh-8.0) with a I did however just encounter the same |
|
Thanks for letting me know.
…On Sun, Mar 22, 2020, 15:43 Michael Vorburger
|
|
Same happened to. |
|
same here, forwarding with ed25519 not working |
|
I just came across this too - ed25519 keys can't be used with the auth agent, which is a shame. Confirming still an issue with connectbot 1.9.8 in 2022 |
As far as I understand ConnectBot relies on the binaries of the ROM. |
|
The SSH agent is entirely dependent on ConnectBot source code, so not adding ed25519 is just an oversight. |
I login on a server (fpirisp) without problems with connectbot. But if I try to ssh to it again from the command prompt (having agent enabled on connectbot) it refuses to login using the agent with the error
sign_and_send_pubkey: signing failed: agent refused operation
The ssh keypair is configured correctly (if it weren’t it would not let me login from connectbot). And the agent in connectbot is also correct, because it lets me login to other servers (that have lower versions of OpenSSH: OpenSSH_6.7p1 Debian-5+deb8u2 on a debian stable, for example).
The server in question that gives me problems has OpenSSH_7.2p2 Debian-5.
This is the output when trying to ssh back into the server from the connectbot session:
The text was updated successfully, but these errors were encountered: