Key Architecture Takeaways

• ›
  Next-Gen Elliptic Curve Cryptography: Ed25519 keys operate on Curve25519, providing a 128-bit security level (~3072-bit RSA equivalent) with compact 68-character strings and microsecond signature generation.
• ›
  Zero-Secret Transmission Protocol: The private key never leaves the client machine. The server issues a random challenge nonce that the client signs mathematically, proving ownership without revealing credentials.
• ›
  Immunity to Password Guessing Botnets: Disabling password authentication stops 100% of automated dictionary scanners and credential stuffing attempts targeting port 22.
• ›
  Strict POSIX Permission Enforcement: OpenSSH StrictModes strictly denies access if ~/.ssh or authorized_keys are group- or world-writable, preventing lateral file tampering.

OpenSSH Asymmetric Handshake & Cryptographic Tunnel

Public key authentication replaces passwords with an asymmetric mathematical proof of identity.

<Callout type="benchmark" title="Why Ed25519 Outclasses Legacy RSA"> Historically, SSH keys were generated as 2048-bit or 4096-bit RSA keys. RSA relies on the computational difficulty of factoring large integers. However, RSA signature creation is computationally intensive, generates bulky public/private key files, and is vulnerable to side-channel cache timing attacks if not carefully implemented.

Ed25519 uses Twisted Edwards curves (Curve25519). Key generation and signing are orders of magnitude faster, immune to side-channel timing attacks, and generate compact public keys that easily fit on a single terminal line without wrapping. </Callout>

OpenSSH Directory Hierarchy & Permission Layout

OpenSSH enforces strict POSIX file mode boundaries. If any directory in the path is writable by another user or group, sshd will reject authentication.

Step-by-Step Implementation Guide

<Steps> <Step title="Generate Ed25519 Keypair on Client Workstation"> On your local laptop or client terminal, generate a modern Ed25519 keypair. Provide a valid email or employee identifier in the -C comment flag:

<Step title="Safely Distribute Public Key to Remote Server"> Never use scp to blindly replace the remote ~/.ssh/authorized_keys file, as doing so wipes out all existing administrators' keys. Use ssh-copy-id, which safely appends your public key in atomic mode:

<Step title="Audit Remote File Permissions (StrictModes Enforcement)"> Log in to the remote server and verify the POSIX permissions on both the directory and the authorized keys file:

Expected output:

drwx------ 2 technhit technhit 4096 Oct 25 10:00 /home/technhit/.ssh
    -rw------- 1 technhit technhit  104 Oct 25 10:00 /home/technhit/.ssh/authorized_keys
    ```
    If permissions are looser (such as `0775` or `0664`), immediately tighten them:
    `chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys`
  </Step>

  <Step title="Harden OpenSSH Daemon to Terminate Password Login">
    Create a clean drop-in configuration file in `/etc/ssh/sshd_config.d/` to permanently disable password-based logins, reject direct root password auth, and rate limit brute-force connection attempts:

    <CodeTabs>
      <div label="/etc/ssh/sshd_config.d/99-hardened.conf" filename="/etc/ssh/sshd_config.d/99-hardened.conf">

ini # ============================================================================== # TechNHIT Enterprise OpenSSH Hardening Configuration # Path: /etc/ssh/sshd_config.d/99-hardened.conf # ==============================================================================

Enable cryptographic public key authentication PubkeyAuthentication yes

Completely disable password authentication PasswordAuthentication no KbdInteractiveAuthentication no

Restrict root account access (allow only public keys, or disable entirely) PermitRootLogin prohibit-password

Disable empty passwords PermitEmptyPasswords no

Disconnect after 3 failed attempts MaxAuthTries 3

Disable insecure X11 forwarding X11Forwarding no

Enforce strict file mode audits on user home directories StrictModes yes

Limit concurrent unauthenticated sessions to prevent SSH DoS MaxStartups 10:30:100

</div>
    </CodeTabs>
  </Step>

  <Step title="Validate sshd Configuration Syntax & Reload Service">
    Before restarting the SSH daemon, ALWAYS run a syntax test to ensure there are no formatting errors that could lock you out:

    <TerminalBlock
      command="sudo sshd -t"
      title="Dry-Run OpenSSH Syntax Test"
      os="Remote Linux Server"
    />

    Once the syntax test returns clean (exit code 0), reload the service:

    <TerminalBlock
      command="sudo systemctl reload ssh"
      title="Zero-Downtime Daemon Reload"
      os="Remote Linux Server"
    />

    <Callout type="benchmark" title="Fail-Safe Connection Check">
      **CRITICAL**: DO NOT close your current SSH terminal window! Open a separate terminal window on your local machine and attempt to connect:
      `ssh -i ~/.ssh/id_ed25519 technhit@10.10.10.50`
      If the connection succeeds without prompting for a system password, your configuration is validated. If something went wrong, your original administrative terminal is still open to correct the configuration.
    </Callout>
  </Step>

  <Step title="Verify Ingress with Verbose Diagnostics">
    Confirm that the connection handshake is using Ed25519 and that password authentication is rejected:

    <TerminalBlock
      command="ssh -v -i ~/.ssh/id_ed25519 technhit@10.10.10.50 'echo SSH_HARDENING_SUCCESSFUL'"
      title="Verify Handshake in Verbose Diagnostic Mode"
      os="Client Workstation"
    />
  </Step>
</Steps>

---

## Verification & Rollback Strategy

<Bookmark
  title="OpenSSH Security Documentation & Manuals"
  url="https://www.openssh.com/manual.html"
  description="Comprehensive reference for sshd_config parameters, StrictModes enforcement, and modern key exchange algorithms."
  author="OpenBSD Project"
/>

<Callout type="tip" title="Client SSH Config Aliasing (~/.ssh/config)">
To avoid typing `-i ~/.ssh/id_ed25519` and port specifications every time, add an alias to your local `~/.ssh/config`:

ini Host prod-node HostName 10.10.10.50 User technhit IdentityFile ~/.ssh/id_ed25519 Port 22 `` Now, simply typing ssh prod-node` connects instantly with full cryptographic verification. </Callout>