↓ Skip to main content
Le Site de François
  1. Index/

SSH (Secure Shell)

Security Networking Cryptography Remote-Access Linux Pki

SSH (Secure Shell) is a cryptographic protocol, standardised in RFC 4251–4254, that provides a secure channel over an unsecured network for remote login, remote command execution, file transfer (via SFTP and SCP), and general TCP port forwarding. It replaced the plaintext protocols it was designed to obsolete — Telnet, rlogin, rsh, rcp — by providing mutual authentication and full session encryption. SSH is the universal administrative access mechanism for Linux servers, network devices, and embedded systems, and the transport layer for Git over SSH, Ansible, Fabric, and most configuration management tooling. The protocol stack has three layers: SSH-TRANS (the transport layer — handles the initial key exchange, server authentication, and establishes the encrypted channel), SSH-AUTH (the authentication protocol — authenticates the client to the server using one of several methods), and SSH-CONN (the connection protocol — multiplexes the encrypted channel into multiple logical channels for sessions, port forwards, and X11 forwarding).

The handshake establishes the session’s cryptographic parameters through a key exchange that provides forward secrecy: both sides negotiate an algorithm (curve25519-sha256 is the modern default, using X25519 ECDH), exchange key shares, and derive session keys without those keys ever being transmitted. The server then authenticates itself to the client by signing the session identifier with its host key — the long-term identity key that the server administrator generates (ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key) and that clients record in ~/.ssh/known_hosts on first connection. The known_hosts model is Trust On First Use (TOFU): the first connection to a host records the host key fingerprint, and subsequent connections verify it matches — preventing impersonation after the first contact but not during it. The alternative — SSH certificates — replaces TOFU with a proper PKI: a CA signs host keys with ssh-keygen -s ca_key -I host_id -h host_key.pub, producing a ssh_host_ed25519_key-cert.pub that clients verify against the CA’s public key configured in known_hosts as @cert-authority * ssh-ed25519 AAAA.... Clients no longer need per-host entries; the CA signature is the trust anchor. The same CA mechanism works for client authentication: ssh-keygen -s ca_key -I user_id -n username user_key.pub issues a user certificate that the server trusts via TrustedUserCAKeys /etc/ssh/trusted_cas in sshd_config, with validity periods, source IP restrictions, and permitted command restrictions (-O options) embedded in the certificate itself — the basis for short-lived SSH certificate issuance used by Vault (vault ssh -mode=ca) and SPIFFE-adjacent tooling.

Client authentication methods are the operational centre of SSH security in this glossary’s context. Public key authentication — the dominant secure method — requires the client to prove possession of the private key corresponding to a public key listed in the server’s ~/.ssh/authorized_keys; the proof is a signature over the session identifier, so the private key never leaves the client. Private keys should always be passphrase-protected at rest and stored in an SSH agent (ssh-agent, gpg-agent, or a hardware token’s agent interface) so the passphrase is entered once per session rather than per connection. Certificate authentication (described above) is preferable at scale because it eliminates authorized_keys management across a fleet — adding or revoking access is a CA operation rather than an authorized_keys edit on every server. FIDO2/hardware token authentication (sk key types: ecdsa-sk, ed25519-sk) binds the private key to a hardware security key (YubiKey, SoloKey) so that authentication requires both the key file and physical presence of the hardware token — providing a second factor without a separate OTP step, since the token’s resident credential never leaves its hardware. Password authentication should be disabled in sshd_config (PasswordAuthentication no) on any Internet-facing host; it is vulnerable to brute force and credential stuffing even with fail2ban mitigation. In the PAM and bastion context, SSH is the transport that PAM platforms record, gate, and inject credentials into; the bastion host model is fundamentally an SSH jump host (ProxyJump bastion.example.com in the client’s ~/.ssh/config, or ssh -J bastion target), and modern PAM platforms replace raw SSH access with a brokered session that records the full terminal transcript. The PQC transition affects SSH at two points: key exchange (the mlkem768x25519-sha256 hybrid group is available in OpenSSH 9.9+) and host/user key algorithms (ML-DSA host keys and user keys are under active IETF standardisation as the post-quantum replacement for Ed25519 and ECDSA in SSH certificates and authorized_keys).

Related

TLS (Transport Layer Security)

Security Cryptography Networking Tls Pki Protocol
TLS (Transport Layer Security) is the protocol that establishes an encrypted, integrity-protected, and authenticated channel between two parties over an untrusted network. It is the successor to SSL (which is deprecated and broken) and the mechanism behind HTTPS, gRPC, LDAPS, SMTPS, database connections, and most other encrypted transport in modern infrastructure. The current version is TLS 1.3 (RFC 8446, 2018); TLS 1.2 remains in wide use but TLS 1.0 and 1.1 are deprecated by RFC 8996. The fundamental security properties TLS provides are: confidentiality (a passive observer cannot read the session content), integrity (an active attacker cannot modify session content without detection), and server authentication (the client can verify it is talking to the intended server rather than an impersonator). Client authentication is optional in standard TLS and is provided by mTLS.

WireGuard

Networking Security Vpn Cryptography Linux Kernel
WireGuard is a VPN protocol and implementation designed by Jason Donenfeld, merged into the Linux kernel in 5.6 (2020) and subsequently ported to Windows, macOS, iOS, Android, and BSD. Its defining characteristic is radical simplicity: the reference Linux kernel implementation is approximately 4,000 lines of code, compared to tens of thousands for IPsec’s XFRM subsystem and hundreds of thousands for OpenVPN. This simplicity is a deliberate security property — a smaller codebase has a smaller attack surface, is easier to audit, and is less likely to contain implementation vulnerabilities. WireGuard achieves this by making every design decision that allows optionality to be eliminated: there is no algorithm negotiation, no handshake negotiation, no cipher suite selection. The cryptographic suite is fixed: X25519 for key exchange, ChaCha20-Poly1305 for authenticated encryption, BLAKE2s for hashing and key derivation (via a custom HKDF-like construction), and Curve25519 for the static key pairs that identify peers. Peers are identified exclusively by their 32-byte Curve25519 public key, making WireGuard a public-key routed VPN: there are no usernames, passwords, certificates, or CAs; access control is entirely a function of which public keys are listed in each peer’s configuration.

FIDO (Fast IDentity Online) / FIDO2

Security Authentication Cryptography Pki Webauthn Mfa Zero-Trust
FIDO2 is the current generation of authentication standards produced jointly by the FIDO Alliance and the W3C, combining two specifications: WebAuthn (Web Authentication API, W3C Level 3, 2025) and CTAP2 (Client to Authenticator Protocol 2, FIDO Alliance). Its defining security property is origin binding: every FIDO2 credential is generated and used with a cryptographic binding to the specific Relying Party ID (RP ID — typically the registering domain’s origin) encoded into every authentication assertion. An authenticator will refuse to produce an assertion for evil.com using a credential registered with bank.com, even if the phishing site presents an identical login page and intercepts the WebAuthn call — the origin check is enforced inside the authenticator, not in JavaScript, and cannot be bypassed by a man-in-the-middle who controls the network or the browser DOM. This property is what makes FIDO2 phishing-resistant by construction, whereas TOTP, SMS OTP, and push-notification MFA are all interceptable by a real-time phishing proxy. FIDO2 is the direct successor to FIDO U2F (Universal 2nd Factor), which provided phishing resistance as a second factor only; FIDO2 extends the model to full passwordless primary authentication.