Secure OpenSSH

IT牛人.117 2016-02-10 18:30

I’ve been continuously learning OpenSSH (since 2006) and closely following its changes since version 6.7.

I personally consider start using Public Key Authentication and Host-based Authentication a milestone from a beginner to intermediate (experienced, power user, whatever appropriate).

NOTE : TCP Forwarding (SSH Tunneling), Agent Forwarding, X11 Forwarding are considered advanced.

To understandRoaming through the OpenSSH client: CVE-2016-0777 and CVE-2016-0778better, I started readingOpenSSH manualto learn how its implementation works internally.

I once thought I had done an excellent job hardening OpenSSH server and client configurations until I came across this articleSecure Secure Shell. It simply blew my mind. I didn’t regain my confidence until RTFM again ;-D

Below is a sample~/.ssh/config->Gistinspired bystribika’s post, with comments.

My personal ssh client configuration file has never been so long ;-D

# User ssh configuration file ~/.ssh/config
# Gist
# man ssh_config for more information
# Inspired by the blog post below to fight the NSA

# Github needs diffie-hellman-group-exchange-sha1 some of the time but not always
# Host
    # KexAlgorithms,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1

Host *
    # key exchange algorithms
    # client authentication
    PasswordAuthentication no
    ChallengeResponseAuthentication no
    PubkeyAuthentication yes
    # host key algorithms the client wants to use in order of preference
    # symmetric ciphers in order of preference
    # Message Authentication Code algorithms in order of preference for data integrity protection
    ServerAliveInterval 30
    # Speed up SSH session creation
    # by sharing multiple sessions over a single etwork connection
    # reuse already established TCP connection
    # ControlMaster auto
    # ControlPath ~/.ssh/sockets/%r@%h-%p
    # ControlPersist 600
    # Disable roaming explicitly anyway for good
    UseRoaming no

I don’t really understand why OpenSSH includes broken/weak algorithms, at least disable them by default for security sake. Fortunately users can specify unbroken (yet) algorithms to use in server/client configuration files.

NOTE : Remember to make necessary changes to thesshd_configon server side to make things work.sshguardis strongly recommended for Linux servers running in the cloud with public IPs.

Last but not least, there isNO perfect security, we have to stay alert and keep learning / adopting new best practices. Thanks to Edward Snowden, who raised our security awareness and skills to an all new high level ;-D

Trust me, OpenSSH Manual is worth reading if you are interested in knowing more about OpenSSH. Below is something I didn’t know before RTFM

  • For SSH protocol 2, Forward Secrecy (PFS) is provided through a Diffie-Hellman key agreement. This key agreement results in a shared session key (ephemeral).

  • OpenSSH supports the use of certificate for authentication (optionCertificateFile).

  • OpenSSH certificates consist of a public key, some identity information, zero or more principal (user or host) names and a set of options that are signed by a Certification Authority (CA) key. They are different, and much simpler format to the X.509 certificates used in SSL/TLS.

  • Verifying host key can be done using DNS and SSHFP resource record. UseVerifyHostKeyDNSto configure.

  • SSH-based VPN

  • ssh -Q {cipher,cipher-auth,mac,kex,key,key-plain,key-cert,protocol-version}to query supported algorithms

  • ssh -o VisualHostKey=yesto display a ASCII art graph of the host key

  • sshdAuthentication internals


  1. OpenSSH Manual (RTFM)
  2. Secure Secure Shell
  3. Security Guidelines Openssh - MozillaWiki
  4. SSH implementation comparison
  5. SSH: Best practices
  6. OpenSSH @ Wikibooks
  7. O’Reilly - SSH, The Secure Shell: The Definitive Guide

[返回] [原文链接]