putty-cac: an SSH client that can use a smart card, a token or a passkey

A fork that changes the credential, not the terminal

putty-cac is described as a fork of PuTTY, a popular Secure Shell terminal, and it adds support for the Windows Certificate API, PKCS #11 libraries and Fast Identity Online authenticators to perform SSH public key authentication.

That framing matters, because a fork usually implies divergence. This one keeps the client recognisable and replaces the credential story. The point of the project is narrow and concrete: a PuTTY user who is handed a Common Access Card at their desk, or whose organisation has issued hardware tokens, or who is now expected to use a passkey, needs a way to answer the SSH public key challenge with that credential instead of a key file on disk.

The CAC in the name refers to Common Access Card, a smart card used in US Government facilities, and the README says it was one of the original drivers behind the project. It also says PuTTY CAC is maintained independently of the US Government by the open source community, which is a useful thing to know given the origin of many such forks.

The licence situation is unusual and worth stating carefully. The README says the source code and binaries are free to use for any purpose and points to the licence file, and the licence identifier recorded for the repository is a custom one that GitHub cannot classify. The file is at code/LICENCE, and this review does not give legal advice, so a team using it inside a government or regulated environment should read that file and the guidance in their own organisation's policy group.

The audience is a Windows user with a hardware credential. The system requirement is Microsoft Windows 10 or later.

Three credential paths and their prerequisites

The prerequisites section splits by credential type, and the split matters because each path has a different piece of software you have to install first.

For CAPI support you need an appropriate Windows smart card mini-driver, typically provided by the smart card manufacturer, though many common hardware tokens are supported by OpenSC. For PKCS support you need a PKCS #11 library, typically a DLL file, to interface with the hardware token, again usually from the manufacturer and again often available through OpenSC. For FIDO support you use a FIDO authenticator supported by Windows, and on Windows 11 this can include compatible phone-based authenticators on Android and iPhone in addition to physical hardware keys.

The Windows 11 passkey point is the most modern capability here. The built-in Windows FIDO2 integration means a phone can act as the authenticator for an SSH session, which removes the need to carry a token, and it is a genuinely different deployment story from the CAC case the project started with.

The three mechanisms are genuinely different rather than three names for the same thing. CAPI talks to the Windows certificate store through a mini-driver. PKCS #11 talks to a vendor library loaded as a DLL. FIDO is the WebAuthn-style protocol spoken over USB or, on Windows 11, over the platform's own passkey integration. The project topic list reflects that range, with capi, pkcs11, fido, webauthn, passkeys, smartcard, cac, yubikey and 2fa among the tags, alongside pki, fips, mfa, dod and ssh.

Referring to a certificate on the command line

The command line usage is the part of the documentation that tells you how the fork fits into scripts, because for any PuTTY utility you can use a certificate thumbprint or application identifier in place of a PuTTY key file path.

Connecting with a certificate from the user certificate store uses a CAPI prefix followed by the thumbprint, so the -i option takes the value CAPI:716B8B58D8F2C3A7F98F3F645161B1BF9818B689. Adding a PKCS #11 library uses a PKCS prefix with the thumbprint and the library path joined by an equals sign, so the value is PKCS:B8B58D8F2C3A7F98F3F645161B1BF9818B689716=C:\PKCS.dll. And a FIDO key from the PuTTY CAC FIDO key cache uses the FIDO prefix with an ssh: identifier, so the value is FIDO:ssh:MyFidoKey. In all three cases the command is putty.exe followed by user@host and the -i flag.

The same -i option therefore covers all three credential types, and the prefix tells PuTTY CAC which mechanism to use. That is a clean design, because a script that connects to a host does not have to change when the organisation moves from smart cards to FIDO keys, only the value after the -i flag.

The README notes that the Putty executables, putty.exe, pageant.exe and psftp.exe, all support the additional options, so the same credential plumbing works for the SSH client, the agent and the file transfer tool.

Pageant flags, and why the defaults matter

The additional command line options are mostly about Pageant behaviour, and they can also be set from its user interface. Once set they apply automatically to subsequent executions unless explicitly unset, which is a useful property for a machine that also runs scheduled jobs.

There is a flag to automatically load any compatible CAPI certificates at startup, and one to save the key list between PuTTY executions. There is one to enable supplementary PIN caching in Pageant, and one to prompt when a certificate signing operation is requested, which matters for a human-driven flow where an unexpected signature prompt is a security signal rather than a nuisance.

There is one to attempt X.509v3 certificate authentication when the server advertises it per RFC 6187, and it is off by default, which is correct since advertising an authentication method the server supports is not the same as the client choosing to use it.

Then there are three about which certificates appear in the selection dialogs. Only display trusted certificates. Do not display expired certificates. And disable all filtering. The last one is the base setting, and the first two are opt-in restrictions, which is the opposite of what you would want in a locked-down environment.

One more detail from the usage section is easy to miss. The Copy To Clipboard buttons in PuTTY's Connection, SSH, Certificate panel and Pageant's key list include the certificate subject in the copied key's comment by default, and holding Shift while activating either button omits the subject. That is a small usability decision with a security reason, since a pasted key comment can end up in a ticket or a chat window.

Certificates as a naming convention for key pairs

The Special Considerations section explains what a certificate means in PuTTY CAC, and the answer reframes the whole feature.

For PuTTY CAC a certificate is simply a convenient way to reference a private and public key pair. That is the entire point. A smart card holds the private key and never releases it, so the card, its thumbprint or its application identifier is what you name on the command line, and the key material stays on the device.

Two consequences follow. If you want to use PuTTY CAC to securely log on to your system and you do not have access to a Certificate Authority, the certificate can be self-signed. And conversely, PuTTY CAC can be used with managed SSH servers to enforce multifactor authentication.

The enforcement mechanism is worth reading carefully, because it is the server-side half of the story. You ensure the OpenSSH authorized_keys file only contains public keys associated with approved authenticators, for example hardware tokens or managed FIDO devices. You can do that procedurally, or by creating an index of all issued certificates and looking them up through OpenSSH directives such as AuthorizedKeysCommand.

That is a genuine architectural point. A certificate-based SSH setup can be centrally revocable, because the server decides which certificates are valid at connection time, rather than every host holding a list of keys that must be edited individually. The trade-off is that the certificate authority and the lookup mechanism become infrastructure that has to be operated.

FIPS, the PuTTYTab session host, and what the fork does not change

The FIPS section explains that the code used to interface with the hardware token relies on Microsoft cryptographic libraries, which are governed by system-level FIPS settings, and that the hardware token used for signing authentication challenges is guaranteed to use FIPS-compliant algorithms if the hardware key is FIPS certified.

So compliance is a property of the whole chain rather than of the fork: the Windows policy settings, the Microsoft libraries, and the certification of the token. The fork adds no cryptographic authority of its own, which is the right design for something in this category.

PuTTYTab, puttytab.exe, is the other half of the project and is not really about authentication. It hosts independent PuTTY processes in one tabbed window, and the feature list is specific: saved-session and arbitrary-argument launchers, saved-session autocomplete from the Connect Bar, exact duplication of a running session, tab rename, reorder and close-protection actions, PuTTY's runtime session commands, full-screen and always-on-top modes, and graceful multi-session shutdown.

The mouse behaviour is worth noting because it is the kind of detail that decides whether a tabbed host feels right. Double-click a tab to rename it, drag tabs to reorder them, middle-click a tab to close it, and double-click empty tab-strip space to open a new session. Locked tabs ignore tab-level close actions but still close after an explicit whole-application exit confirmation.

You can start it with no arguments for an empty tabbed window, and New Session with Ctrl+Shift+T opens PuTTY's standard configuration dialog, or you can pass any normal PuTTY command line such as puttytab.exe -load "My Session" or puttytab.exe -ssh [email protected]. One deployment constraint is stated plainly: PuTTYTab and putty.exe must remain in the same directory.

The shortcut list is Alt+R for the Connect Bar, Ctrl+Shift+T for a new session, Ctrl+Shift+D to duplicate the current session, Ctrl+Shift+R to reconnect an inactive session, Ctrl+Shift+W or Ctrl+F4 to close a tab, Ctrl+Tab and Ctrl+Shift+Tab to switch tabs, Ctrl+Shift+Page Up and Page Down to reorder tabs, Ctrl+1 through Ctrl+9 to select a tab, and F11 for full screen.

Editorial conclusion

putty-cac fits an administrator who is required to authenticate to a system with a Common Access Card, a YubiKey or a FIDO credential, and who wants to keep the PuTTY interface they already know, because the fork changes the authentication backend and leaves the rest of the client recognisable. It is the wrong choice for a Linux or macOS user, for anyone whose only credential is an ordinary key file, and for a deployment that needs a maintained upstream PuTTY rather than a community fork. Before deploying it, check that your smart card has a Windows mini-driver, install the PKCS #11 library from the token vendor or OpenSC, and read the certificate selection flags, because the default is to show all certificates and filtering is opt-in.

Frequently asked questions

Official sources

1. Issues
2. NoMoreFood/putty-cac on GitHub
3. README
4. Releases