SSH-Passkeys: WebAuthn for Passwordless SSH

Updated 6 July 2026

SSH-Passkeys are a framework for SSH authentication that uses WebAuthn passkeys to replace traditional passwords and key files.
The design employs a PAM module that launches a browser-based WebAuthn challenge, enabling passwordless and backward-compatible SSH logins.
Empirical studies show that SSH-Passkeys reduce security errors, prevent private key leakage, and cut authentication time significantly.

Searching arXiv for the cited SSH-passkeys paper and closely related SSH/WebAuthn work. Search query: SSH-Passkeys WebAuthn SSH [PAM](https://www.emergentmind.com/topics/parabolic-anderson-model-pam) passkeys SSH-Passkeys are a framework and prototype implementation for SSH authentication that uses Web Authentication (WebAuthn) passkeys instead of passwords or traditional SSH key files. The design delegates authentication to WebAuthn through a UNIX pluggable authentication module (PAM), so the SSH protocol and client remain unchanged while the credential lifecycle is handled by a WebAuthn authenticator on behalf of the user. In the reported design, this yields passwordless remote server login with passkeys, remains backwards-compatible, supports stock SSH servers, and requires no new software client-side (Kayali et al., 11 Jul 2025).

1. Definition and motivation

SSH-Passkeys were proposed against the background that passwords remain the dominant mode of SSH authentication despite well known flaws such as phishing and reuse. The paper summarizes that many internet-facing SSH servers see approximately $250\text{k}$ unauthorized attempts per month, and that only approximately $35\%$ of internet-exposed SSH servers require anything beyond a password (Kayali et al., 11 Jul 2025). SSH public-key authentication improves on passwords in principle, but the same source characterizes it as vulnerable to key theft, difficult lifecycle management, and poor usability in practice.

In the SSH-Passkeys model, the user authenticates with a passkey held by a WebAuthn authenticator rather than with a password or a manually managed SSH key pair. The authenticator may be a platform authenticator, such as an OS-level mechanism backed by a TPM or equivalent, or a roaming authenticator such as a FIDO2 hardware key. A passkey is a public/private key pair generated and managed by the authenticator, associated with a relying party identifier and origin, and typically protected by local user verification such as biometrics or a PIN (Kayali et al., 11 Jul 2025).

The motivation is not only cryptographic but operational. Traditional SSH keys require users to generate keys, choose algorithms and key sizes, store and back them up, and transfer public keys to servers. The paper reports that only $25\%$ of participants in its SSH-key cohort used a passphrase, and that $20\%$ leaked their private keys. It also identifies privacy problems in common SSH practice, particularly reuse of one public key across many servers, which allows correlation of user identities across administrative domains (Kayali et al., 11 Jul 2025).

By contrast, passkeys are described as offering strong asymmetric cryptography, origin binding, non-exportability, hardware protection, phishing resistance, privacy through per-origin credentials, and optional attestation. SSH-Passkeys are therefore presented as an attempt to reuse the mature WebAuthn/FIDO2 passkey ecosystem for SSH without redesigning SSH itself (Kayali et al., 11 Jul 2025).

2. Architectural integration with SSH

The central architectural move is to place WebAuthn behind PAM. A custom PAM module installed on the SSH server runs a small WebAuthn-capable web server and mediates between the SSH daemon, the user’s browser, the OS WebAuthn subsystem, and the authenticator. OpenSSH continues to use PAM in the ordinary way, so the SSH client sees only PAM text messages and an eventual success or failure. No new SSH authentication method is added at the protocol level; the effect is equivalent to a keyboard-interactive PAM flow (Kayali et al., 11 Jul 2025).

The authentication sequence is as follows. A client connects to the SSH daemon and completes normal SSH negotiation. The SSH daemon invokes PAM, which starts the SSH-Passkeys PAM module. The module launches an embedded web server and returns a listening address to the SSH daemon. The SSH daemon then sends that URL to the user through a PAM_TEXT_INFO message. The user opens the URL in a browser, the page invokes navigator.credentials.get() for authentication or navigator.credentials.create() for registration, the authenticator performs local verification, and the browser posts the WebAuthn response back to the PAM-side server. The module verifies the assertion and returns PAM_SUCCESS or PAM_AUTH_ERR to SSH (Kayali et al., 11 Jul 2025).

This design is explicitly distinguished from existing OpenSSH support for U2F/FIDO keys as key storage. In the paper’s characterization, current support still relies on ssh-keygen, does not manage passkeys as first-class credentials, does not use platform authenticators, and does not provide WebAuthn semantics such as origin binding or attestation (Kayali et al., 11 Jul 2025).

The overall result is a server-side sidecar architecture. The server side comprises the OpenSSH daemon, PAM, the SSH-Passkeys PAM module, and its embedded HTTP(S) challenge server. The client side comprises an ordinary terminal, a browser with WebAuthn support, the OS WebAuthn implementation, and hardware-backed credential storage. A plausible implication is that the design deliberately trades native SSH integration for deployability: it keeps the client and the SSH wire protocol unchanged, but introduces a browser-mediated authentication surface.

3. Registration, credential lifecycle, and identity binding

Registration uses the same general architecture as authentication. The server generates a one-time URL for registration, sent out-of-band to the user. When the user visits that URL, the web server initiates a WebAuthn registration ceremony with navigator.credentials.create(), supplying relying party information and user identity. The authenticator creates a new credential unique to that relying party and user, and the server stores the resulting public key and metadata, binding them to the user’s Unix account (Kayali et al., 11 Jul 2025).

Credential lifecycle management is thus split in a specific way. Creation, secure storage, user verification, and deletion are handled by the authenticator and operating system, while the SSH server stores only the public key and associated metadata. This preserves the ordinary SSH server-side pattern of storing public credentials while removing user handling of private key files (Kayali et al., 11 Jul 2025).

The system’s identity model is shaped by WebAuthn’s relying-party and origin semantics. A passkey is bound to a specific origin, whereas SSH ordinarily identifies remote systems by hostname or IP address and uses host keys under a trust-on-first-use model. The paper notes that a server may have multiple aliases such as worker, worker.local, worker.corp.net, and 192.168.0.5; because passkeys are origin-bound, these aliases must either map to the same relying party or be supported through WebAuthn’s “related origin requests” facility (Kayali et al., 11 Jul 2025).

The threat model centers on the client-server authentication channel. Attackers may attempt password guessing or credential stuffing, steal or exfiltrate files from user devices, operate phishing servers or man-in-the-middle attacks, and compromise servers to obtain stored public keys or logs. The design does not assume that attackers can break modern asymmetric cryptography or extract keys from properly implemented hardware authenticators. Full compromise of client or server operating systems beyond authentication is out of scope or only partly in scope (Kayali et al., 11 Jul 2025).

4. Security properties and analytical position

The security claims of SSH-Passkeys are organized around material protection, phishing resistance, privacy, and policy control. The first property is protection of cryptographic material at rest. In the SSH-Passkeys design, private keys reside inside WebAuthn authenticators and are typically non-exportable, hardware-protected, encrypted at rest, and gated by local verification. This directly addresses the paper’s observation that SSH private keys are often stored unencrypted on disk and that only $25\%$ of its SSH-key cohort used passphrases (Kayali et al., 11 Jul 2025).

A second property is resistance to key leaks and theft. The user study found that $20\%$ of SSH-key users leaked their private key, whereas such leakage is structurally impossible in SSH-Passkeys because the private key never appears in files or terminal output. The paper further states that $47\%$ of all security errors made by SSH-key users involved actions that are impossible by construction under the passkey design (Kayali et al., 11 Jul 2025).

A third property is phishing resistance adapted to SSH. In SSH-Passkeys, registration and authentication occur only for the web origin associated with the server’s PAM-side web service, and the authenticator will not sign challenges for the wrong origin. This is presented as stronger than password-based SSH authentication and as a way of importing the web’s origin checks into SSH login, albeit indirectly through the browser sidecar. The paper contrasts this with SSH’s TOFU model, which is described as brittle because users often skip host key verification and may accept a man-in-the-middle on first use (Kayali et al., 11 Jul 2025).

A fourth property is privacy and unlinkability. WebAuthn requires per-origin credentials, so the same private key is not reused across servers. This prevents the classic SSH public-key correlation problem in which one key reused across many servers allows linking of identities. In the Bonneau et al. framework, SSH-Passkeys score positively on “Unlinkable,” whereas traditional SSH keys do not (Kayali et al., 11 Jul 2025).

The paper also discusses attestation as an optional mechanism for enterprise policy, for example to require trusted authenticator models or user-verification enforcement. In its structured conceptual analysis based on Bonneau et al.’s 25 factors, SSH-Passkeys satisfy $22.5/25$ factors and reach the $97\%$ security percentile among 37 schemes. Fully supported benefits are reported to include resistance to throttled guessing, unthrottled guessing, phishing, leaks from other verifiers, internal observation, and theft of tokens, as well as explicit consent, unlinkability, and no trusted third party (Kayali et al., 11 Jul 2025).

Related passkey research complicates, but does not overturn, these claims. Work on device-bound versus synced credentials argues that the security of synced passkeys is mainly concentrated in the passkey providers, whereas device-bound credentials provide stronger “No-Trusted-Third-Party” and “Resilient-to-Internal-Observation” properties (Büttner et al., 13 Jan 2025). Work on attack vectors against FIDO2 likewise concludes that successful attacks on passkeys require substantial effort and resources and typically depend on compromised authenticators, trust stores, or local endpoints (Berladskyy et al., 22 Apr 2026). This suggests that SSH-Passkeys inherit strong passkey security properties, but also inherit the boundary condition that endpoint compromise remains decisive.

5. Prototype implementation and empirical evaluation

The prototype server-side PAM module is written in C using libpam, installed on Linux, and evaluated on Ubuntu 24.04. It is enabled through /etc/pam.d configuration and UsePAM yes in sshd_config. The embedded web server is a Python Flask application, using the py-webauthn library for WebAuthn server logic, while the browser uses simplewebauthn.js with the navigator.credentials.* APIs. On the client side, the system uses a standard OpenSSH client together with any modern browser supporting WebAuthn and either a platform authenticator or an external FIDO2 token (Kayali et al., 11 Jul 2025).

The user-facing login flow is simple but visibly multi-contextual: ssh user@server, a prompt instructing the user to visit a URL, a browser page that offers either registration or authentication, an OS prompt such as Touch ID, Windows Hello, or a security-key touch, and then continuation of the SSH session. Registration is performed through a one-time onboarding URL (Kayali et al., 11 Jul 2025).

Evaluation took the form of a randomized controlled study with 40 computer science undergraduates from two major research universities, half in Germany and half in the United States. The control group received a one-time password and was instructed to set up ordinary SSH key authentication; the treatment group received a one-time sign-up URL for SSH-Passkeys with otherwise analogous instructions. The infrastructure consisted of Docker deployment with one client environment and two SSH servers, one running vanilla OpenSSH with password and SSH keys and one running OpenSSH with the SSH-Passkeys PAM module (Kayali et al., 11 Jul 2025).

The reported results are summarized below.

Measure	SSH keys control	SSH-Passkeys treatment
Total security errors per participant	6.95	1.15
Critical security errors per participant	2.74	0.10
Private key leakage	20%	0%
Completion time (successful participants)	1306 s	330 s
Success rate within 40 minutes, no critical errors	2/20 = 10%	18/20 = 90%
External help accesses	8.05	0.80
SUS score	52.6	78.9

These differences are described as statistically significant at $p < 0.001$ for total security errors, critical security errors, external help, and SUS score. The control group displayed a long tail of cascading errors, with cross-category correlations up to $35\%$ 0 and overall $35\%$ 1, whereas the SSH-Passkeys group showed weaker correlations at $35\%$ 2, interpreted as more isolated and recoverable errors. The paper also reports self-assessment accuracy of $35\%$ 3 in the SSH-Passkeys group against $35\%$ 4 in the SSH-key group, the latter described as strongly overconfident (Kayali et al., 11 Jul 2025).

The study therefore supports a dual claim. First, SSH keys were shown to be error-prone even among technically competent participants, including direct private-key leakage. Second, SSH-Passkeys reduced both security errors and time-to-authenticate while improving measured usability (Kayali et al., 11 Jul 2025).

The most evident limitation is architectural: running a web server and JavaScript application inside PAM broadens the attack surface. The prototype introduces a Flask server, HTTP parsing, and browser-mediated logic into the SSH authentication path. The paper explicitly identifies this as a concern for high-assurance environments and recommends minimizing functionality and locking down configuration (Kayali et al., 11 Jul 2025).

Further constraints follow from the WebAuthn model. SSH-Passkeys require a modern browser and WebAuthn support on the client machine, and they require HTTP or HTTPS reachability to the embedded PAM-side web server. Mapping SSH server identity to web origins is nontrivial, especially where servers have multiple aliases or operate in air-gapped environments. Device loss and recovery are also unresolved at the prototype level: if a passkey exists on only one authenticator, losing that device may lock the user out, so the paper recommends multiple authenticators or out-of-band recovery rather than built-in syncing (Kayali et al., 11 Jul 2025).

Deployment is intentionally conservative. A system administrator installs the PAM module and its dependencies, updates /etc/pam.d/sshd, ensures UsePAM yes, and decides whether passkeys are mandatory or whether passwords and SSH keys remain available as fallbacks. Registration URLs can then be distributed out-of-band during onboarding. Migration can be gradual, because the server can keep legacy methods active while introducing SSH-Passkeys for selected accounts or environments (Kayali et al., 11 Jul 2025).

Two adjacent research directions clarify where SSH-Passkeys sit in the broader design space. One is an incremental browser-mediated lineage: earlier work on ssh-webagent enabled SSH public-key authentication over HTTP for browser-based SSH clients by introducing a local HTTP-speaking agent without exposing private keys (Anbalagan, 2015). Another is a protocol-redesign lineage: SSH3 reconstructs secure shell as an HTTP/3 application using QUIC, TLS 1.3, and HTTP authorization, making OIDC-mediated passkey use through an identity provider a natural fit (Michel et al., 2023). SSH-Passkeys occupy a distinct middle position: they neither redesign SSH into HTTP nor require a new SSH client, but instead bolt WebAuthn onto stock SSH servers through PAM.

A broader implication emerges from related passkey portability research. TUSH-Key proposes cross-device passwordless enrollment without cloning private keys, using device-specific keys, device IDs, Diffie-Hellman key exchange, and encrypted access tokens (Mitra et al., 2023). This suggests that future SSH-passkey systems might combine the PAM-based deployment strategy of SSH-Passkeys with richer cross-device enrollment models, provided they preserve the paper’s central property that the authenticator, not the user, manages private key material.