Closed meilon closed 2 years ago
I downloaded the source code of PuTTy and found winmisc.c, there is the definition of char *get_username(void)
which itself uses the Windows API call GetUserNameExA
(if available and returns something) with the NameUserPrincipal
format. And yep, that's for UPN. That might be why it didn't work at home, too, because I'm using Microsoft login there.
I'm digging in how Go fetches it...
hi. I had same the problem. I saw this post Pageant Support and winssh-pageant and tried using it with Tera Term. After checking "pageant" and clicking login, the dialog like "use XXX.pem?" popped up, and when I clicked ok, the next dialog "Windows Hello" popped up. So, some part of the progress works, but after that Tera Term stopped logging in.
I'm in Microsoft AD environment, too. I'm glad if this information helps.
I've been doing some investigation. I'm unable to replicate this problem thus far on my system, can either of you maybe provide more details?
@meilon the pageant named pipe is not used by KiTTY/PuTTY (nor klink/plink) when connecting to a remote. I've been doing my investigation with the --no-pageant-pipe
flag.
My testing setup:
V8.9.1.0p1-Beta
packagessh-keygen -t {rsa,ed25519} ...
~/.ssh/authorized_keys
filessh-add -L
ssh-add -L
should return the list of keys you have added to 1Passwordssh <user>@<remote IP> -v
and connecting to a remote
ssh
packaged in Microsoft OpenSSH, ran from Windows Terminalwinssh-pageant --no-pageant-pipe
. I recommend killing and explicitly re-running the application for this testing.klink.exe
from the KiTTY website
klink.exe
is interchangeable with: plink.exe
, putty.exe
, kitty.exe
or kitty_portable.exe
klink.exe
(and all the others) in a temporary folder that's not in my System PATHcd
to the location you put your klink.exe
in. Run the following command:
.\klink -l <username> <remote IP> -v
note the -v
flag for verbose logging.
If everything works correctly, which it did on my system, you will successfully connect to your remote, and you'll see similar log output (from the -v
) to this: (I have removed some irrelevant lines)
PS H:\Home\code\winssh-pageant\tmp> .\klink -l nate <REMOTE-IP> -v
Looking up host "<REMOTE-IP>" for SSH connection
Connecting to <REMOTE-IP> port 22
We claim version: SSH-2.0-PuTTY_KiTTY
Connected to <REMOTE-IP>
Remote version: SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.4
Using SSH protocol version 2
Doing ECDH key exchange with curve Curve25519 and hash SHA-256 (SHA-NI accelerated)
Server also has ecdsa-sha2-nistp256/rsa-sha2-512/rsa-sha2-256/ssh-rsa host keys, but we don't know any of them
Host key fingerprint is:
ssh-ed25519 255 <SHA256 fingerprint>
Pageant is running. Requesting keys.
Pageant has 1 SSH-2 keys
Using username "nate".
Trying Pageant key #0
Authenticating with public key "id_ed25519_1password_passwd" from agent
Sending Pageant's response
Access granted
Please ask for any clarification if needed.
In this screenshot it shows the service is running, for testing 1Password ssh-agent it should NOT be running.
Like I said, 1Password is working, ssh-add -L lists the keys from there successfully (with Windows integrated and the upgraded 8.9 OpenSSH binaries). Services are disabled. Also connecting with both versions of the ssh binary works fine. But not with PuTTy/KiTTy
There's a typo, its --no-pageant-pipe
, I copied your flag and winssh-pageant then just doesn't start, nothing in the console window.
Correctly started I get these three important lines (and, as expected, no named pipes for the winssh-pageant process):
Pageant is running. Requesting keys.
2022/04/12 16:33:49 Der Vorgang wurde erfolgreich beendet.
Failed to get reply from Pageant
The one in the middle is from the running winssh-pageant process. I get the same line when I try to connect via KiTTy or PuTTy and means the "The Operation Completed Successfully", what ever that means.
Hmm, this is perplexing. What version of winssh-pageant are you using? (there were changes to how the key proxying works between v1.2 and now). If you installed this program before Jul 13, 2021, please update to the latest version: https://github.com/ndbeals/winssh-pageant/releases/latest
Like I said, 1Password is working, ssh-add -L lists the keys from there successfully (with Windows integrated and the upgraded 8.9 OpenSSH binaries). Services are disabled. Also connecting with both versions of the ssh binary works fine. But not with PuTTy/KiTTy
Excellent. Could you clarify what "both versions of the ssh binary" means please?
Thanks for pointing out the typo, I've fixed it.
Correctly started I get these three important lines (and, as expected, no named pipes for the winssh-pageant process):
That's the output from klink -v
?
Would you be willing to spend some time working on this with me over Discord? (or something else if you don't have discord, let me know) If so, add me @ Nate#5274
I'm dedicated to getting this working for you and any others experiencing the same problems!
Another note: Sometimes 1Password, through Windows Hello, will open a dialog where you enter your Windows Account password (or PIN, or fingerprint, etc) to (re)authorize usage of the key being requested. In my testing, this window gets minimized and can be easy to miss.
I know it doesn't help solve it, but here's a gif of kitty_portable
working with winssh-pageant
: https://i.imgur.com/CkVxxus.mp4
The 1Password Community thread that @disksystem linked contains a likely key piece of information, quoted below:
When running winssh-pageant via the authors recommended way (as a Scheduled Task set to run at Log On), it exhibits the behaviour I orginally posted. I suspect this may be connected to the owning process. This method has the ownership chain of winssh-pageant.exe -> svchost.exe (task scheduler) -> services.exe -> wininit.exe
The autorun via scheduled task is no longer the suggested way. It's likely the user is correct about their suspicion about process ownership causing issues. Here are the instructions for the new autostart method.
What version of winssh-pageant are you using?
The current 2.1 x64 binary
Could you clarify what "both versions of the ssh binary" means please?
I meant the same thing as before: The default pre installed OpenSSH binaries (C:\Windows\System32\OpenSSH) and the ones from the aforementioned Microsoft/PowerShell repo (C:\Program Files\OpenSSH). The latter one doesn't replace the preinstalled ones, but on the system where I installed these I've added them to the PATH before the preinstalled one.
That's the output from
klink -v
?
I'm guessing you meant the version information (with an uppercase V):
plink: Custom build
Build platform: 32-bit x86 Windows
Compiler: gcc 9.2.0
Build option: NO_SECUREZEROMEMORY
Source commit: unavailable
If you meant the verbose output of the connection the important lines are above:
Pageant is running. Requesting keys.
2022/04/12 16:33:49 Der Vorgang wurde erfolgreich beendet.
Failed to get reply from Pageant
And regarding to the process owner, I killed all 1Password tasks and started 1Password, winssh-pageant and another command prompt from one command prompt (so all have the same parent process), still, same output.
And I'll contact you on discord, we can try and solve it on my personal machine.
@meilon I think I just figured out the problem. And it's internationalization.
2022/04/12 16:33:49 Der Vorgang wurde erfolgreich beendet.
means the "The Operation Completed Successfully", what ever that means.
Indeed it is a message from winssh-pageant. specifically https://github.com/ndbeals/winssh-pageant/blob/master/pageant.go#L59.
This is because the OpenFileMappingA
always returns an error, even if it succeeded, so in my naive handling of the error I check if the message is "The operation completed successfully." which obviously won't evaluate to true if the text is in German.
Because of that, it causes the main event handler to exit early: https://github.com/ndbeals/winssh-pageant/blob/master/pageant.go#L121
I switched my display language to english and it worked, so at least in my case the hard coded string check is the issue here
Indeed this problem is because of my naive string comparison. A fix is implemented, I'm just waiting for confirmation it works before publishing a new release. If anyone else would like to test the fix, here's the updated binary. No installer, just run this manually, confirm it works and leave a message here. I'll publish the update ASAP. winssh-pageant-string-fix_amd64.zip
worked for me! Thanks for the fast fix of this issue!
Hi!
I can't seem to get winssh-pageant to run with 1Passwords integrated ssh-agent. The Windows 10 included OpenSSH and the manually installed OpenSSH-x64-v8.9.1.0.msi can show me the available keys with
ssh-add -L
, but when I open a connection from KiTTy, no request appears from 1Password and KiTTy falls back to keyboard interactive login.I haven't set a key file for the KiTTy connection and the connections work with Pageant flawlessly. I can also connect to the server with the ssh binarys from Windows 10 and the more current one, in both cases I get asked by 1Password if this is allowed and I have to confirm via Windows Hello.
I tried multiple devices and I also tried vanilla PuTTy, but it never works.
What I found out is the named pipes visible in Process Explorer. When I start pageant it has a different one than winssh-pageant:
So my guess is KiTTy, PuTTy and Pageant use a different method to generate the NamedPipe name than winssh-pageant. At least in my situation. I try to use it in our Microsoft AD environment and as you can see the username portion of my UPN is different from the login name aka sAMAccountName.
I dove a bit into the code and found that in the pageant.go the user information gets pulled. I guess pageant goes a different route creating the username portion, and I couldn't understand what exactly gets sha256 hashed for the last part.
What could I do to make winssh-pageant work in my situation?`