Everything You Never Knew about SSH

Outline

• Introduction to SSH
• SSH key generation and management

• File transfer

  • sshfs
  • scp/rsync
  • -C
  • Interactive w/ base64

• X-Forwarding
• As a SOCKS proxy
• SSH relaying

• SSH Server configuration

  • Disabling root login
  • Disabling insecure ciphers
  • Configuring ports

• Reverse SSH tunnels

Basic SSH Topics

• SSH's original and still primary use case was remote console access over the wire.

  • Can also be used as a tunnel for other arbitrary protocols.

• SSH Keys are used as an alternative to passwords to authenticate users.

  • Public/private key cryptography. The you keep a private key locally and send the public key to machine you would like to log in to.

  • Key can be generated with ssh-keygen

    • Private key goes in ~/.ssh/id_rsa (this is a secret)
    • Public key goes in ~/.ssh/id_rsa.pub (this can be shared)
    • You can use other paths, but these are the default.
    • SSH allows you to have more than one public/private key pair if you so choose.
    • Identity file (private key) can be specified with -i if you have more than one key.

  • Setup key-based login to a remote machine using ssh-copy-id
  • Password-less keys are great for automation, for example a CI server that needs clone a git repository over SSH.

• A remote file system can be mounted over SSH using sshfs.

  • This requires FUSE.
  • Not the most performant, but handy for using a local editor to work on remote code, or for small file transfers via a GUI file manager.

  • Example sshfs -o Port=222 username@remotehost:/remotepath ~/mnt/remotehost.

    • Unmount with fusermount -u ~/mnt/remotehost.

• Non-interactive file transfers can be accomplished using rsync.

  • In the past, scp was used. rsync has superseded it and is better, faster, and more featurefull.

  • Useful options:

    • --compress (-z)
    • --recursive (-r)
    • --verbose (-v)

    • --update (-u)

      • Skip files which already exist on the destination.

    • --human-readable (-h)

      • Human-readable output (use SI units instead of bytes).
      • Also causes progress to be shown in real-time.

  • Example: rsynz -rzvuh user@remote:/path/to/thing ./some/path

• Sometimes, you want to transfer a small file or text snippet over an interactive SSH session you have already open.

  • Easy: just use base64, copy the result, then use base64 -d on the other end to decode.
  • Does not scale well to large files, but has the benefit of not requiring a new session to be opened.

• X-Forwarding.

  • Like RDP on NT systems, Linux's display system (xorg) allows applications to be run from a remote host via X-forwarding. This will cause a remote application to appear as if a local one within your desktop session.
  • -X (to enforce security) or -Y to trust the remote for X forwarding.
  • It is a good idea to combine this with -C.
  • Example: ssh -C -Y username@remote

• SOCKS Proxies can be used to tunnel web traffic through other hosts. This is useful on hostile networks (where someone may be snooping your traffic) or on networks that employ "web filters" to censor internet traffic.

  • Establish a proxy with ssh -D 12345 someuser@remote.

    • Relay 12345 with your desired port.

  • Configure your web browser to use localhost on the port you selected in the last step as a SOCKS version 5 proxy.

Advanced Topics

• Sometimes you have SSH access to a gateway system, and that system has SSH access to a target system, but you do not have directs SSH access from your local system to the target, usually due to a firewall.

  • In one-off cases, you can just SSH into the gateway then SSH from there to the target.
  • In cases where you need to make this connection on a regular basis, you should use a relay.

  • You can really one-off with ssh -t user@gatway ssh user@target

    • Source_1

  • You can configure this permanently with ~/.ssh/config:

    Host somename
          User          someuser
          HostName      target_host
          IdentityFile  ~/.ssh/some_identity
          ProxyCommand ssh -AW %h:%p someuser@gateway_host

    • Source_2

• SSH Server configuration (/etc/ssh/sshd_config)

  • man sshd_config
  • PermitRootLogin
    • Root login should be disabled - you should always log in as a non-root user and use sudo or sudo -i. Set PermitRootLogin to no.
    • If you must enable root login for some reason, you should disable password authentication and connect only via key-based authentication.
    • This is important because many bad actors trawl for open SSH ports and attempt to login as the root account by brute forcing it's password.
  • Ciphers
    • It can happen that an SSH cipher may be broken. From that point on, most distributions will disable it by default in sshd_config. However existing installations may leave it enabled.
    • It is dangerous to explicitly specify a cipher whitelist, as this will prevent updates to your SSH server from updating the list of allowed ciphers.
    • You can disable a single cipher while still allowing future updates to openssh to install and add newer, more secure ciphers by adding the line Ciphers -ciphername.
      • For example: Ciphers -arcfour* would disable all variants of the arcfour cipher, which is known to be insecure.
      • You can list what ciphers are currently enabled using sudo sshd -T | grep -i cipher.
      • Most current distros will keep the list of enabled ciphers limited to those known to be secure. If you administrate a system, you should keep an eye out for security advisories indicating that a cipher has been broken and disable it if so. These techniques can also be useful for hardening systems which can no longer be updated (legacy deployments).

  • By default, SSH servers use port 22.
    • You can use other arbitrary ports, or even more than one at the same time!
    • You might want to use a different port to prevent automated brute-force attacks (though these are not likely to succeed, they can leave lots of failed login attempts in your server's logs). In some networking situations, you may not be able to use port 22, for example if your ISP firewalls low port numbers (I have heard reports that some residential ISPs do this).
    • As long a you disable (or use key based) root authentication, and use strong passwords (or ideally key-based login only) for all user accounts, it is not necessary to use an alternative port from a security perspective. If you don't do these things anyway, you best hope any hypothetical attacker does not know what nmap is!

    • On the server side, you can provide a list of ports for sshd to listen on by adding a line Port [portnumber] for every such port. As an example:

      Port 22
      Port 222
      Port 2222

    • Ports 222 and 2222 are common alternate ports, but any arbitrary port can be used.
    • On the client side, just use the argument -p [portnumber] while logging in. For example: ssh -p 222 username@hostname.

• Reverse SSH tunneling
  • Sometimes you have a case (for example, a NATed network where you don't have the ability to port forward) where you have a host that can SSH out, but cannot receive incoming SSH connections from elsewhere (i.e. other LANs, the Internet, etc.).
  • The solution is a reverse-SSH tunnel. In this case, the inaccessible host (call it target) opens a connection to the source machine (call it source) which are are attempting to log into it from.
  • On target, run ssh -R 12345:localhost:22 someuser@source.
  • On source, run ssh someuser@localhost -p 12345.
  • You can use ports other than 12345 naturally.
  • The port 22 from the first command should be whatever port target 's SSH server is set to listen on.
  • The disadvantage is that you must have shell access and an SSH server running on both source and target.
  • One possible workaround would be to have a script on target that perpetually keeps a tunnel open via a password-less SSH key, or which opens such a tunnel is response to a canary (i.e. a certain word appear on on a certain HTTP webpage).
  • Your IT admin may not like this, since you are effectively punching a hole through their firewall.

Further Reading

• If you find yourself trapped in a restrictive network, you can do clever things to tunnel your way out via SSH (which you can then use to establish a SOCKS proxy, if you so desire).
  • You can tunnel SSH over an HTTP connection using tools such as corkscrew .
  • You can also tunnel over DNS (DNS Tunneling Made Easy ).
• If you run a server exposed to the public, you might want to use a tool such as fail2ban to automatically ban IP addresses after too many failed login attempts. ( How To Protect SSH with Fail2Ban on Ubuntu 14.04 )