Welcome to mirror list, hosted at ThFree Co, Russian Federation.

github.com/mRemoteNG/PuTTYNG.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorSimon Tatham <anakin@pobox.com>2022-01-15 21:36:22 +0300
committerSimon Tatham <anakin@pobox.com>2022-01-15 21:54:31 +0300
commit8a2883933d4f664681a015341cf8760a0231a41b (patch)
tree7795e05668bb2cb844e898a529bcc4a7ccff8c01 /doc
parent11aa9ab8f3f426131fdeb2f37f98a94802a0a37c (diff)
Windows Pageant: integrate with Windows OpenSSH.
After a discussion with a user recently, I investigated the Windows native ssh.exe, and found it uses a Windows named pipe to talk to its ssh-agent, in exactly the same way Pageant does. So if you tell ssh.exe where to find Pageant's pipe, it can talk directly to Pageant, and then you can have just one SSH agent. The slight problem is that Pageant's pipe name is not stable. It's generated using the same system as connection-sharing pipe names, and contains a hex hash value whose preimage was fed through CryptProtectData. And the problem with _that_ is that CryptProtectData apparently reinitialises its seed between login sessions (though it's stable within a login session), which I hadn't fully realised when I reused the same pipe-name construction code. One possibility, of course, would be to change Pageant so that it uses a fixed pipe name. But after a bit of thought, I think I actually like this feature, because the Windows named pipe namespace isn't segregated into areas writable by only particular users, so anyone using that namespace on a multiuser Windows box is potentially vulnerable to someone else squatting on the name you wanted to use. Using this system makes that harder, because the squatter won't be able to predict what the name is going to be! (Unless you shut down Pageant and start it up again within one login session - but there's only so much we can do. And squatting is at most a DoS, because PuTTY's named-pipe client code checks ownership of the other end of the pipe in all cases.) So instead I've gone for a different approach. Windows Pageant now supports an extra command-line option to write out a snippet of OpenSSH config file format on startup, containing an 'IdentityAgent' directive which points at the location of its named pipe. So you can use the 'Include' directive in your main .ssh/config to include this extra snippet, and then ssh.exe invocations will be able to find wherever the current Pageant has put its pipe.
Diffstat (limited to 'doc')
-rw-r--r--doc/pageant.but22
1 files changed, 22 insertions, 0 deletions
diff --git a/doc/pageant.but b/doc/pageant.but
index 8abb5cdf..392c1da1 100644
--- a/doc/pageant.but
+++ b/doc/pageant.but
@@ -170,6 +170,28 @@ by the command, like this:
\c C:\PuTTY\pageant.exe d:\main.ppk -c C:\PuTTY\putty.exe
+\S{pageant-cmdline-openssh} Integrating with Windows OpenSSH
+
+When Pageant starts up, it can optionally write out a file containing
+an OpenSSH configuration directive that tells the Windows \c{ssh.exe}
+where to find Pageant. If you include this file from your Windows SSH
+configuration, then \c{ssh.exe} should automatically use Pageant as
+its agent, so that you can keep your keys in one place and have both
+SSH clients able to use them.
+
+The option is \c{--openssh-config}, and you follow it with a filename.
+
+To refer to this file from your main OpenSSH configuration, you can
+use the \cq{Include} directive. For example, you might run Pageant
+like this:
+
+\c pageant --openssh-config C:\Users\Simon\.ssh\pageant.conf
+
+and then add a directive like this to your main \cq{.ssh\\config}
+file:
+
+\c Include C:\Users\Simon\.ssh\pageant.conf
+
\S{pageant-cmdline-keylist} Starting with the key list visible
Start Pageant with the \i\c{--keylist} option to show the main window