2018年公网双机SSH/SFTP服务高强度密码学配置问询

Got it, let's break down the most cryptographically strict sshd_config settings for 2018, focusing exclusively on the protocol, encryption, handshake, and crypto algorithm bits you asked about. We'll skip over key management, firewalls, and password policies as requested.

These configurations eliminate all legacy, vulnerable, or weak algorithms that were known to be risky in 2018, sticking to only the most robust options available at the time.

Core Protocol Lockdown #

First, we ditch the ancient and insecure SSHv1 entirely—only SSHv2 is acceptable:

Protocol 2

Key Exchange (KEX) Algorithms #

KEX is how the two hosts establish a shared secret. In 2018, curve25519 was the gold standard for its speed and security, followed by large ECDH curves and strong DH groups. We cut out any KEX using SHA1 or small moduli:

KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256

• curve25519-sha256@libssh.org: Preferred lightweight, high-security elliptic curve KEX
• ECDH with NIST P-521/P-384/P-256: Strong elliptic curve alternatives
• diffie-hellman-group-exchange-sha256: Fallback for systems that don't support ECC, using SHA256 for hashing

Host Key Algorithms #

Host keys authenticate the server to the client. We prioritize Ed25519 (the most secure and efficient) and ECDSA, then RSA with SHA2 signatures (avoiding the old SHA1-based ssh-rsa):

HostKeyAlgorithms ssh-ed25519,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256,rsa-sha2-512,rsa-sha2-256

• ssh-ed25519: EdDSA-based host key, fast and resistant to many attacks
• ECDSA variants: Strong elliptic curve options
• RSA with SHA2 signatures: Legacy RSA support but using modern hashing (no SHA1)

Encryption Ciphers #

We focus on Authenticated Encryption with Associated Data (AEAD) algorithms first—these provide both encryption and integrity in a single step, which is more secure than separate encryption + MAC. We also include strong CTR-mode AES as a fallback:

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

• chacha20-poly1305@openssh.com: Fast AEAD cipher, great for systems without AES-NI
• AES-GCM variants: Secure AEAD ciphers with hardware acceleration support
• AES-CTR: Strong block cipher mode, a reliable fallback if AEAD isn't supported

Message Authentication Codes (MACs) #

Even with AEAD ciphers, we lock down MACs to use only SHA2-based algorithms, prioritizing Encrypt-Then-MAC (ETM) mode which is more secure than the old MAC-then-Encrypt approach:

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256

• ETM variants: Encrypt first, then authenticate—prevents tampering attacks that exploit MAC-then-Encrypt flaws
• SHA2-based MACs: No SHA1 or weaker hashes allowed

Final Checks #

After updating your /etc/ssh/sshd_config, always validate the configuration before restarting the daemon:

sshd -t

If no errors are returned, restart the SSH service (command varies by distro):

# Systemd-based systems (like Ubuntu 18.04, CentOS 7)
systemctl restart sshd

# SysVinit systems
service ssh restart

Make sure your client SSH configs match these algorithms too—otherwise, you might get connection failures. Since you control both machines, updating the client ~/.ssh/config with the same algorithm lists will ensure compatibility.

内容的提问来源于stack exchange，提问作者Vlastimil Burián