-
Notifications
You must be signed in to change notification settings - Fork 742
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
warning: agent returned different signature type ssh-rsa (expected rsa-sha2-512) when key registered with ssh-agent #1551
Comments
Sorry i mean the private key in user.ssh or registered with the agent |
Similar problem here. I've gotten the "different signature" line before, and here's some logs. I have added id_rsa via ssh-add, both with forward and backward slashes on different attempts. The only thing that sometimes works is deleting my identities from ssh-agent
|
This problem came up in October 2018, and the fix still has not been shipped out with Windows. The open ssh client needs to have an updated version of ssh-agent. Please see #1263 for a few workarounds, including manually updating the ssh-agent executable #1263 (comment) I'm hopeful that after 1.5 years this will eventually be released officially. |
@RaptahJezus - fyi, We are updating the windows inbox version of openssh with V8.1.0.0. This will be available during fall time. |
already 2020 Apr. but windows exist this issue. |
@BichengWang - The fix will be part of next windows release which will be available during fall time (sometime in June / july) |
Thank for the update. |
So just to be clear - is there any way to work around this issue, or is the current SSH agent just completely unusable when connecting to newer SSH servers? |
Works fine as long as you don't register the private key with the registry -- put it in a usr/.ssh folder. Seems to work with visual studio code and remote ssh debugging to a pi as well as ssh loginStephen
-------- Original message --------From: wallacms <notifications@github.com> Date: 07/05/2020 19:05 (GMT+00:00) To: PowerShell/Win32-OpenSSH <Win32-OpenSSH@noreply.github.com> Cc: stephencalvert2 <stephen.calvert2@hotmail.co.uk>, Author <author@noreply.github.com> Subject: Re: [PowerShell/Win32-OpenSSH] warning: agent returned different signature type ssh-rsa (expected rsa-sha2-512) when key registered with ssh-agent (#1551)
So just to be clear - is there any way to work around this issue, or is the current SSH agent just completely unusable when connecting to newer SSH servers?
—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or unsubscribe.
[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "#1551 (comment)",
"url": "#1551 (comment)",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]
|
If I don't register the private key with the registry then what is SSH agent doing? To be clear, I have a file .ssh/id_rsa that is setup in the authorized_keys file on the remote host. If I do not run ssh-add and then SSH to the remote host, I'm prompted for my passphrase, I enter it and everything works (which is exactly what happens if I'm not using SSH agent at all). If I do run ssh-add, my key gets added to the agent and everything appears to work. Then when I SSH to the remote host, I get: |
Wasting space on the machine as far as I can tellStephen
-------- Original message --------From: wallacms <notifications@github.com> Date: 08/05/2020 19:32 (GMT+00:00) To: PowerShell/Win32-OpenSSH <Win32-OpenSSH@noreply.github.com> Cc: stephencalvert2 <stephen.calvert2@hotmail.co.uk>, Author <author@noreply.github.com> Subject: Re: [PowerShell/Win32-OpenSSH] warning: agent returned different signature type ssh-rsa (expected rsa-sha2-512) when key registered with ssh-agent (#1551)
Works fine as long as you don't register the private key with the registry
If I don't register the private key with the registry then what is SSH agent doing?
To be clear, I have a file .ssh/id_rsa that is setup in the authorized_keys file on the remote host. If I do not run ssh-add and then SSH to the remote host, I'm prompted for my passphrase, I enter it and everything works (which is exactly what happens if I'm not using SSH agent at all).
If I do run ssh-add, my key gets added to the agent and everything appears to work. Then when I SSH to the remote host, I get:
warning: agent returned different signature type ssh-rsa (expected rsa-sha2-512)
and then I'm prompted for my password (not the key passphrase) and I can login to the remote host.
—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or unsubscribe.
[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "#1551 (comment)",
"url": "#1551 (comment)",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]
|
Are you referring to the May Update (2004)? I just updated and I'm still noticing this issue.
|
@silentflight15 - May update (2004) doesn't have the fix. |
Which year? |
The next windows update will be available on 10/20/2020. |
what can I do to fix the error until that date? |
Wow! this needs to be fixed. Either through Windows Update or a downloadable patch. |
i worked around using this comment: #1263 (comment) |
I've installed Windows 10 20H2 19042.546 (Insider beta channel), but it's still |
Windows 10 20H2 RTM also contains 'OpenSSH_7.7p1 for Windows' (file version 7.7.2.1). |
Ye, still waiting for the "update"... |
This is deplorable. Honestly, the solution is to decouple from the in-box version and keep up to date with the latest version yourself. |
this isn't the case: can you make some statement why this wasn't included in the 20H2 Update? |
@bagajjal On 29th of May, which was about 5 month ago, you said that this will be include in October update. Note, that the code changes were ready back then, it was just the matter of including them. We have patiently waited for this for 5 months. Remember me asking above "which year?" Well, it looks like contrary to what you said, may be not this one. Could you please explain what happened? Was 5 month not enough time to include already released code into the update? Why not, is it very laborious process? Did something went wrong? |
Here's what happened. I checkin the changes to the destined branch in Jan 2020. It's released to insider fast ring (first party customers who have early access). Please see this issue. In the very end, windows decided to use a different branch. We were not informed of this change. Just like our OpenSSH community, I got surprised. |
@bagajjal you must be looking at the wrong issue and not #1263. The fix for that did NOT ship in June of 2019. Look at your own comment in June 2020:
That issue is NOT fixed. You've never released the fix. The thread is nothing but dozens of people saying they are still having it and absolutely no one has confirmed a fix. You must have been looking at a different issue? |
Also, if you read the title and description of this issue and #1263 they sound like the same issue to me, but I'm no expert so I'll have to defer to you. |
@altano - We have two different releases.
This issue is fixed as part of Github release (NOT windows release) in v7.9.0.0p1-Beta. We didn't have a windows release from v7.7 which is couple of years old. I agree it's too old, it happened because of several reasons (dev resource change, change in project priorities, misalignment of windows release dates, etc.). I upgraded the windows release to V8.1 in Jan 2020. Unfortunately this couldn't make it to latest windows update because of reasons mentioned earlier. |
I think I'm missing something about the relevancy of that. Here's what I'm understanding:
Is any of that wrong? |
Why isn't this part of the normal windows update as it is a critical\breaking bugfix and potential security risk? Why is it only update in the latest windows version if we also have LTS versions? |
I think this list of pre-8.x OpenSSH vulnerabilities speaks for itself...I can't believe its taken over a year to create a Windows update that includes a fixed OpenSSH version compatible with the latest Linux distros. |
relax bro, I think they will fix it before Feb 12 2021, until now, it still less a year. |
For those generating new keys, joe-p's workaround posted in the other issue about this problem is helpful. TLDR: if you generate a modern ssh key using Curve25519, the agent doesn't sign the key with the wrong hash function, so a workaround is to use keys generated via:
Note that very old OSes may not accept ed25519 keys, and you can use |
This helped a LOT! Thanks! |
I had same issue. Re-Installing OpenSSH through windows feature solved for me. |
FYI, that should be ssh-add [path/to/id_ed25519] You add the private key to your agent, not the public key |
@bagajjal A couple of days ago Windows 10 version 21H1 was announced. In the notes I don't see anything about SSH, so probably the fix is also not in this version? It has been a year since this issue is created, there is a fix available, but the deployment is hard. Is it, for instance, a possibility to talk to other teams within Microsoft how they deploy fixes and use that information to get this fix out there? Since December last year .NET Core updates are distributed via Windows Update, maybe talk to them how to get the fix distributed? |
@Jeej , OpenSSH v8.1 will be released as April windows update. |
I had to remove the rsa key first ( |
This worked for me, but, I am not too technically versed in ssh. Can you tell me why the command "-t ed25519 -a 100" works and what it does? |
ssh-keygen -t ed25519 -a 100 Worked like magic, I left the generated private key location as the default, and just scp'ed the public key over to linux: then on linux side (could do this via ssh...) make sure to set permissions for .ssh folder and authorized_keys in linux!!!!! cd /home/[linuxuser] chmod 700 .ssh cd .ssh THEN IT SHOULD JUST WORK LIKE MAGIC! |
Hi, guy...I find a better way to fix it. Uninstall the OpenSSH Client
Install the OpenSSH Client
-No restart needed ENJOY |
Thank you @JulioAviles for your suggestions:
But I tried it and it did not change anything on my system, it just reinstalls the same old C:\Windows\System32\OpenSSH\ssh.exe version 7.7.2.1 from 2019. Maybe for example you installed a newer version of OpenSSH with Git for Windows? Could you provide the output of the following cmd.exe commands?:
and maybe I'm still on Windows 20h2 (According to: |
Shure @johannesbone , all step in PowerShell (no any Git), just I want to let you know that was working well in 2 server, (1 Windows 10 Pro, 1 Ubuntu 20.04), and today stop working in Ubuntu, why? I dont know, I coundn't find the problem !! (warning: agent returned different signature type ssh-rsa (expected rsa-sha2-512) came back. :( winver = Win10Pro 20H2 (OS Built 19042.928) |
I can help a little but I have a doubt too !! |
Just check any of the man pages (like this one):
|
FWIW, the recent upgrade of Windows 10 OpenSSH to 8,1p1 by KB5003173 fixed the issue for me. |
Using ssh included in Git for windows bundle worked to solve the problem for me. And my windows has pre-installed too old version: |
Closing this issue as it's fixed in Win32-openssh V8.1+ |
Couldn't find a solution so opened opened a new issue:
trying to ssh to Pi 3b+ from Powershell in windows vs code using key authentication.
Works as expected if the public key file is in user/ .ssh and not registered with the agent using with ssh-add. If the key is registered the error: warning: agent returned different signature type ssh-rsa (expected rsa-sha2-512) is generated and the remote system logon password is requested. Removing the key from the agent (ssh-add -d) and putting the .pub file in .ssh enables it to work as expected. Same error is encountered from a powershell window opened as administrator.
Client : Windows 10pro 10.0.18363
Key generated with 10.0.18363 ssh-keygen
Server : Raspberry Pi running Raspbian Buster with desktop
system updated with latest software versions
The text was updated successfully, but these errors were encountered: