SSH is the secure encrypted replacement for telnet. The default service port is 22. It provides a means for users to obtain remote shell aka command-line access to a server. It comprises of both client and server components; every open source Linux and BSD distribution comes supplied with ssh, even Mac OS X, though Windows workstations and servers must install third-party software.
Using ssh to connect to a remote server is pretty straight forward:
alice@local$ ssh remote.example.com Last login: Tue Mar 22 15:39:54 2016 from local.example.org NetBSD 6.1.5 (GENERIC) Welcome to NetBSD! alice@remote$
The client attempts to login using the user's ID on the remote machine, prompting for a password or private key passphrase. To login as a different user on the remote machine:
alice@local$ ssh firstname.lastname@example.org email@example.com's password: Last login: Tue Mar 22 15:41:27 2016 from local.example.org NetBSD 6.1.5 (GENERIC) Welcome to NetBSD! billy@remote$
Using ssh with a public/private key
Using ssh ensures the user's password is transmitted between the local and remote machines encrypted. However, an open ssh server can still be port scanned; black hats will make attempts to access an account using common user names with bad and insecure password choices. On a Unix type of machine, have a look at /var/log/authlog to see which services hackers are attempting to break into, typically ssh, FTP, IMAP, and POP.
If /var/log/authlog shows evidence of attemps to discovery accounts on other services, consider disabling plain text password over all clear text services and use STARTTLS at a mininum; consider forcing users to switch to default on encryption such as FTP over SSL, SFTP (FTP over SSH), IMAPS, POPS, and SMTPS.
For ssh, the administrator could disable password logins and force the use of public/private keys. Using a public/private key ensures that only the holder of the private key can remotely login. For optimum security a users' private key should itself be encrypted with a passphrase to prevent a key's use in case the user's workstation is compromised or stolen. To use a public/private key, the user must first create them:
$ cd $ mkdir .ssh $ chmod 700 .ssh $ cd .ssh $ ssh-keygen -b 2048 Generating public/private rsa key pair. Enter file in which to save the key (/home/alice/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/alice/.ssh/id_rsa. Your public key has been saved in /home/alice/.ssh/id_rsa.pub. The key fingerprint is: bd:5a:96:a3:54:5e:11:19:21:62:93:c0:23:06:78:c9 firstname.lastname@example.org The key's randomart image is: +--[ RSA 2048]----+ | o.o ...+.. ++ | |. E o o..o ... | | . . . . . | | . . | | S o . | | o + | | . B | | . = . | | o | +-----------------+ $
The user can now give the public key, /home/alice/.ssh/id_rsa.pub, to the administrator of remote.example.com to append to their remote account's /home/alice/.ssh/authorized_keys file. Or if they still have ssh login access with a password, the user can copy the public key to the remote machine and install it themselves. To login, the user simply logins as before, being prompted for their private key's passphrase if required.
How to force public/private key logins.
The system administrator can disable password authentication in favour of only public key authentication by adding these (OpenSSH) options to the sshd configuration. As root user:
# cat >>/etc/ssh/sshd_config ChallengeResponseAuthentication no PasswordAuthentication no RSAAuthentication yes PubkeyAuthentication yes ^D # pkill -HUP sshd
The above still permits KbdInteractiveAuthentication, which allow password authentication only when typed, not scripted or saved. This can be handy in the event of a mistake. However, to disable simple append KbdInteractiveAuthentication no to the sshd_config file and restart sshd; note any mistakes will require access to the machine's console to correct.
Hamper port scanning.
It is possible to avoid almost all port scanning attempts and attacks on port 22 by simply changing the sshd port to a different, typically large, port number. It will not prevent attacks on the new port, but can discard the bulk of scanners who test only default ports. As root user:
# sed -e's/^#\(Port .*22\)/&/; s/^Port.*/#Port 29802/' /etc/ssh/sshd_config >sshd_tmp # mv sshd_tmp /etc/ssh/sshd_config # pkill -HUP sshd
This will require ssh users to use the -p option (-P for scp) to specify a port number. For example:
alice@local$ ssh -p 29802 remote.example.com Last login: Tue Mar 22 15:39:54 2016 from local.example.org NetBSD 6.1.5 (GENERIC) Welcome to NetBSD! alice@remote$
An ssh client can support one or more of the following port forwarding variants (aka poor man's tunnel).
Note that ssh port forwarding options (-D, -L, -R) do not support UDP. OpenSSH does support tun (layer 3) and tap (layer 2) virtual devices, which allows for a VPN over SSH with some extra effort. See -w option of man ssh and Tunnel option in man 5 ssh_config.
The use of the word tunnel is not entirely correct. The SSH features employed here are more correctly referred to as port forwarding. A proper tunnel would be a bi-direction virtual private network, VPN, between two points, that pass all forms of IP traffic (IMCP, TCP, UDP) through an encrypt channel. Port forwarding only passes through (tunnels) one or more specific service ports over the encrypted channel provided by SSH, which is fine for most simple use cases, but less efficient the more ports being forwarded.
Forward tunnels using ssh
ssh supports a nice feature of being able to tunnel other network connections over the secure channel. This is useful when you need to encrypt another applications network traffic and/or by-pass local network restrictions. For example all ISPs and hotels these days block port 25 outbound from their network to prevent abuse by virus infected computers. By setting up a tunnel, one can skirt around the restriction (assuming the ssh port 22 are not blocked locally).
alice@local$ ssh -f -n -N -T -L port:desthost:destport remote.example.com
The -L creates the forward tunnel by listening on port of the local machine for connections, passing them through encrypted to the remote machine, which in turn connects unencrypted to the final destination desthost:destport. The remaining options place the process into the background, -f, and the others disable several facilities that aren't required for a background tunnel-only setup. For example to tunnel SMTP through a firewall:
alice@local$ ssh -f -n -N -T -L 25123:mail.someplace.com:25 remote.example.com
Reverse tunnels using ssh
ssh also supports reverse tunnels. This is particularly useful when there is a need, such as remote administration by ssh or VNC, to get into a machine or network with a dynamic IP address, or behind a firefall and/or NAT. A machine in the difficult to reach network creates a reverse tunnel to a known host with a static IP address outside of its network.
alice@local$ ssh -f -n -N -T -R port:desthost:destport remote.example.com
The options are pretty much the same as for a forward tunnel, except replace -L with -R. However, the listening port is opened on the remote.example.com server and the local machine passes incoming connections to desthost:destport within the restricted network. Users can then connect to remote.example.com:port to reach particular service within that network.
For example a system administrator can create a reverse tunnel for remote access back into their network:
root@local# ssh -f -n -N -T -R 33980:localhost:22 email@example.com
Root's public key is placed into Alice's ~/.ssh/authorized_keys file on remote.example.com to allow the connection from the restricted network. If the tunnel was created to deal with dynamic IP address resets, then a monitoring script will be needed to restart the connection when the tunnel connection is disconnected periodically. Users can then tunnel into their accounts:
billy@somplace$ ssh -p33980 remote.example.com
Dynamic Port Forwarding
ssh has support for the SOCKS protocol that provides dynamic port forwarding, which is useful to cross restrictive firewalls of ISPs, work place, hotels, conference centers, etc. It allows a machine on the inside of a firewall to use a remote server on the outside to make connections to sites and services.
When enabled, the ssh client functions as a local SOCKS server. Local applications can connect to the SOCKS port, typically 1080, and pass connection requests over the secure channel to a remote server, which in turn makes the actual connections to the requested destinations. Use the -D option.
alice@local$ ssh -f -n -N -T -D 1080 remote.example.com
The client application that connects to the SOCKS port must be SOCKS capable, like most web browsers and IRC clients. Otherwise a SOCKS wrapper, like DeleGate will be required to encapsulate application connections in the SOCKS protocol.
- Cygwin : Free Unix tool chain for Windows, which provides a OpenSSH client/server package.
- DeleGate multi-purpose application level gateway and proxy server.
- kitty : Free, open source ssh and telnet client for Windows based on putty.
- OpenSSH : Open source SSH client & server provided with Linux & BSD distributions.
- putty : Free, open source ssh and telnet client for Windows.
- SecureCRT : Commercial SSH client for Windows.
- UltraVNC : Free Virtual Network Connection server and client software for Windows.
- VPN over SSH