ui_pageant » Revisions »
Differences
This shows you the differences between the selected revisions of the page.
| ui_pageant 2022-04-07 | ui_pageant 2024-09-25 (current) | ||
| Line 42: | Line 42: | ||
| <code> | <code> | ||
| - | ssh-ed25519 SHA256:TddlQk20DVs4LRcAsIfDN9pInKpY06D+h4kSHwWAj4w | + | Ed25519 ···SHA256:TddlQk20DVs4LRcAsIfDN9pInKpY06D+h4kSHwWAj4w |
| - | ssh-rsa 2048 SHA256:8DFtyHm3kQihgy52nzX96qMcEVOq7/yJmmwQQhBWYFg | + | RSA 2048 ·SHA256:8DFtyHm3kQihgy52nzX96qMcEVOq7/yJmmwQQhBWYFg |
| </code> | </code> | ||
| For each key, the list box will tell you: | For each key, the list box will tell you: | ||
| - | * The type of the key. Currently, this can be ''ssh-rsa'' (an RSA key), ''ssh-dss'' (a DSA key), ''ecdsa-sha2-*'' (an ECDSA key), ''ssh-ed25519'' (an Ed25519 key), ''ssh-ed448'' (an Ed448 key), or ''ssh1'' (an RSA key for use with the deprecated SSH-1 protocol, not supported by WinSCP). | + | * The type of the key. Currently, this can be ''RSA'', ''DSA'', ''NIST'' (an ECDSA key), ''Ed25519'', ''Ed448'', or ''SSH-1'' (an RSA key for use with the deprecated SSH-1 protocol, not supported by WinSCP). (If the key has an associated certificate, this is shown here with a ''cert'' suffix.) |
| - | * The size (in bits) of the key, for key types that come in different sizes. | + | * The size (in bits) of the key, for key types that come in different sizes. (For ECDSA NIST keys, this is indicated as ''p256'' or ''p384'' or ''p521''.) |
| - | * The fingerprint for the public key. This should be the same fingerprint given by [[ui_puttygen|PuTTYgen]], and also the same fingerprint shown by remote utilities such as ''ssh-keygen'' when applied to your ''authorized_keys'' file. \\ By default this is shown in the SHA-256 format. You can change to the older MD5 format (which looks like ''aa:bb:cc:...'') with the //Fingerprint type// drop-down, but bear in mind that this format is less secure and should be avoided for comparison purposes where possible. | + | * The fingerprint for the public key. This should be the same fingerprint given by [[ui_puttygen|PuTTYgen]], and also the same fingerprint shown by remote utilities such as ''ssh-keygen'' when applied to your ''authorized_keys'' file. \\ By default this is shown in the SHA-256 format. You can change to the older MD5 format (which looks like ''aa:bb:cc:...'') with the //Fingerprint type// drop-down, but bear in mind that this format is less secure and should be avoided for comparison purposes where possible. \\ If some of the keys loaded into Pageant have certificates attached, then Pageant will default to showing the fingerprint of the underlying key. This way, a certified and uncertified version of the same key will have the same fingerprint, so you can see that they match. You can instead use the //Fingerprint type// drop-down to ask for a different fingerprint to be shown for certified keys, which includes the certificate as part of the fingerprinted data. That way you can tell two certificates apart. |
| * The comment attached to the key. | * The comment attached to the key. | ||
| * The state of [[#deferred_decryption|deferred decryption]], if enabled for this key. | * The state of [[#deferred_decryption|deferred decryption]], if enabled for this key. | ||
| Line 94: | Line 94: | ||
| "C:\Program Files (x86)\WinSCP\PuTTY\pageant.exe" d:\main.ppk -c "C:\Program Files (x86)\WinSCP\WinSCP.exe" | "C:\Program Files (x86)\WinSCP\PuTTY\pageant.exe" d:\main.ppk -c "C:\Program Files (x86)\WinSCP\WinSCP.exe" | ||
| </code> | </code> | ||
| + | |||
| + | ==== [[openssh]] Integrating with Windows OpenSSH ==== | ||
| + | |||
| + | Windows's own port of OpenSSH uses the same mechanism as Pageant to talk to its SSH agent (Windows named pipes). This means that Windows OpenSSH can talk directly to Pageant, if it knows where to find Pageant's named pipe. | ||
| + | |||
| + | When Pageant starts up, it can optionally write out a file containing an OpenSSH configuration directive that tells the Windows ''ssh.exe'' where to find Pageant. If you include this file from your Windows SSH configuration, then ''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 ''%%--openssh-config%%'', and you follow it with a filename. | ||
| + | |||
| + | To refer to this file from your main OpenSSH configuration, you can use the ''Include'' directive. For example, you might run Pageant like this (with your own username substituted, of course): &winpath | ||
| + | <code> | ||
| + | pageant --openssh-config C:\Users\martin\.ssh\pageant.conf | ||
| + | </code> | ||
| + | |||
| + | and then add a directive like this to your main ''.ssh\config'' file (assuming that lives in the same directory that you just put | ||
| + | ''pageant.conf''): | ||
| + | <code> | ||
| + | Include pageant.conf | ||
| + | </code> | ||
| + | Note: this technique only works with Windows's port of OpenSSH, which lives at ''%SYSTEMROOT%\System32\OpenSSH\ssh.exe'' if you have it installed. (If not, it can be installed as a Windows optional feature, e.g., via //Settings > Apps & features > Optional features > Add a feature > OpenSSH Client//.) &wincp &winpath | ||
| + | |||
| + | There are other versions of OpenSSH for Windows, notably the one that comes with Windows Git. Those will likely not work with the same configuration, because they tend to depend on Unix emulation layers like MinGW or MSys, so they won't speak Windows native pathname syntax or understand named pipes. The above instructions will only work with Windows's own version of OpenSSH. | ||
| + | |||
| + | So, if you want to use Windows Git with an SSH key held in Pageant, you'll have to set the environment variable ''GIT_SSH'', to point at a different program. You could point it at ''C:\Windows\System32\OpenSSH\ssh.exe'' once you've done this setup – but it's just as easy to point it at Plink! | ||
| + | |||
| + | ==== Unix-domain sockets: integrating with WSL 1 ==== | ||
| + | |||
| + | Pageant can listen on the WinSock implementation of Unix-domain sockets. These interoperate with the Unix-domain sockets found in the original Windows Subsystem for Linux (now known as WSL 1). So if you ask Pageant to listen on one of these, then your WSL 1 processes can talk directly to Pageant. | ||
| + | |||
| + | To configure this, run Pageant with the option ''--unix'', followed with a pathname. Then, in WSL 1, set the environment variable ''SSH_AUTH_SOCK'' to point at the WSL translation of that pathname. | ||
| + | |||
| + | For example, you might run | ||
| + | <code> | ||
| + | pageant --unix C:\Users\Simon\.ssh\agent.sock | ||
| + | </code> | ||
| + | and in WSL 1, set the environment variable | ||
| + | <code> | ||
| + | SSH_AUTH_SOCK=/mnt/c/Users/Simon/.ssh/agent.sock | ||
| + | </code> | ||
| + | Alternatively, you can add a line to your ''.ssh/config'' file inside WSL that says | ||
| + | <code> | ||
| + | IdentityAgent /mnt/c/Users/Simon/.ssh/agent.sock | ||
| + | </code> | ||
| + | although doing it like that may mean that ''ssh-add'' commands won't find the agent, even though ''ssh'' itself will. | ||
| + | |||
| + | Security note: Unix-domain sockets are protected against access by other users by the file protections on their containing directory. So if your Windows machine is multiuser, make sure you create the socket inside a directory that other users can't access at all. (In fact, that's a good idea on general principles.) | ||
| + | |||
| + | Compatibility note: WSL 2 processes cannot talk to Pageant by this mechanism, because WSL 2's Unix-domain sockets are managed by a separate Linux kernel, and not by the same kernel that WinSock talks to. | ||
| ==== Starting with the Key List Visible ==== | ==== Starting with the Key List Visible ==== | ||