Secure Shell - ArchWiki

# Secure Shell

Related articles

- SSH keys
- Pam abl
- fail2ban
- sshguard
- Sshfs
- Syslog-ng
- SFTP chroot

Secure Shell (SSH) is a network protocol that allows data to be exchanged over a secure channel between two computers. Encryption provides confidentiality and integrity of data. SSH uses public-key cryptography to authenticate the remote computer and allow the remote computer to authenticate the user, if necessary.

SSH is typically used to log into a remote machine and execute commands, but it also supports tunneling, forwarding arbitrary TCP ports and X11 connections; file transfer can be accomplished using the associated SFTP or SCP protocols.

An SSH server, by default, listens on the standard TCP port 22. An SSH client program is typically used for establishing connections to an sshd daemon accepting remote connections. Both are commonly present on most modern operating systems, including Mac OS X, GNU/Linux, Solaris and OpenVMS. Proprietary, freeware and open source versions of various levels of complexity and completeness exist.

(Source: Wikipedia:Secure Shell)

## OpenSSH

OpenSSH (OpenBSD Secure Shell) is a set of computer programs providing encrypted communication sessions over a computer network using the ssh protocol. It was created as an open source alternative to the proprietary Secure Shell software suite offered by SSH Communications Security. OpenSSH is developed as part of the OpenBSD project, which is led by Theo de Raadt.

OpenSSH is occasionally confused with the similarly-named OpenSSL; however, the projects have different purposes and are developed by different teams, the similar name is drawn only from similar goals.

### Installing OpenSSH

Install openssh from the official repositories.

### Configuring SSH

#### Client

The SSH client configuration file is `/etc/ssh/ssh_config` or `~/.ssh/config`.

It is no longer needed to explicitly set `Protocol 2`, it is commented out in the default configuration file. That means `Protocol 1` will not be used as long as it is not explicitly enabled. (source: http://www.openssh.org/txt/release-5.4)

#### Daemon

The SSH daemon configuration file can be found and edited in `/etc/ssh/sshd_config`.

To allow access only for some users add this line:

    AllowUsers    user1 user2

To allow access only for some groups:

    AllowGroups   group1 group2

To disable root login over SSH, change the PermitRootLogin line into this:

    PermitRootLogin no

To add a nice welcome message edit the file `/etc/issue` and change the Banner line into this:

    Banner /etc/issue

Tip:

- You may want to change the default port from 22 to any higher port (see security through obscurity). Even though the port ssh is running on could be detected by using a port-scanner like nmap, changing it will reduce the number of log entries caused by automated authentication attempts. To help select a port review the list of TCP and UDP port numbers. You can also find port information locally in `/etc/services`. Select an alternative port that is not already assigned to a common service to prevent conflicts.
- Disabling password logins entirely will greatly increase security, see SSH keys#Disabling password logins for more information.

#### VirtualBox

This article or section is a candidate for merging with VirtualBox#Access a guest server.

Notes: This section does not really belong here, merging into VirtualBox will give the reader more context. (Discuss)

To communicate between the VirtualBox guest and host, the server port must be forwarded under Settings > Network. When connecting from the client/host, connect to the IP address of the client/host machine, as opposed to the connection of the other machine. This is because the connection will be made over a virtual adapter.

### Managing the sshd daemon

The SSH daemon comes with different systemd unit files.

You can start the daemon for immediate usage and/or enable it for next startup as described in systemd#Using units:

    # systemctl start sshd.service
    # systemctl enable sshd.service

Warning: Systemd is an asynchronous starting process. If you bind the SSH daemon to a specific IP address `ListenAddress 192.168.1.100` it may fail to load during boot since the default sshd.service unit file has no dependency on network interfaces being enabled. When binding to an IP address, you will need to add `After=network.target` to a custom sshd.service unit file. See Systemd#Editing provided unit files.

Alternatively to the service used above, the SSH daemon supports socket activation. Using it implies that systemd listens on the SSH socket and will only start the daemon process for an incoming connection:

    # systemctl start sshd.socket
    # systemctl enable sshd.socket

If you use a different port than the default 22 with socket activation, you have to set "ListenStream" in the unit file. Copy `/lib/systemd/system/sshd.socket` to `/etc/systemd/system/sshd.socket` to keep your unit file from being overwritten on upgrades. In `/etc/systemd/system/sshd.socket` change "ListenStream" the appropriate port.

Warning: Using `sshd.socket` effectively negates the `ListenAddress` setting, so using the default sshd.socket will allow connections over any address. To achieve the effect of setting `ListenAddress`, you must create a custom unit file and modify ListenStream (i.e. `ListenStream=192.168.1.100:22` is equivalent to `ListenAddress 192.168.1.100`). You must also add `FreeBind=true` under `[Socket]` or else setting the IP address will have the same drawback as setting `ListenAddress`: the socket will fail to start if the network is not up in time.
Tip: When using socket activation neither `sshd.socket` nor the daemon's regular `sshd.service` allow to monitor connection attempts in the log, but executing `# journalctl /usr/bin/sshd` does.

### Connecting to the server

To connect to a server, run:

    $ ssh -p port user@server-address

### Protecting SSH

Allowing remote log-on through SSH is good for administrative purposes, but can pose a threat to your server's security. Often the target of brute force attacks, SSH access needs to be limited properly to prevent third parties gaining access to your server.

- Use non-standard account names and passwords
- Only allow incoming SSH connections from trusted locations
- Use fail2ban or sshguard to monitor for brute force attacks, and ban brute forcing IPs accordingly

#### Protecting against brute force attacks

Brute forcing is a simple concept: One continuously tries to log in to a webpage or server log-in prompt like SSH with a high number of random username and password combinations. You can protect yourself from brute force attacks by using an automated script that blocks anybody trying to brute force their way in, for example fail2ban or sshguard.

Alternatively, brute force attacks can be made infeasible by forcing public key authentication, by adding the following setting to `sshd_config`:

    PasswordAuthentication no

Before effecting this setting, make sure that all accounts which require SSH access have public key authentication set up in the corresponding `authorized_keys` files.

#### Limit root login

It is generally considered bad practice to allow the root user to log in without restraint over SSH. There are two methods by which SSH root access can be restricted for increased security.

##### Deny

Sudo selectively provides root rights for actions requiring these without requiring authenticating against the root account. This allows locking the root account against access via SSH and potentially functions as a security measure agaist brute force attacks, since now an attacker must guess the account name in additition to the password.

SSH can be configured to deny remote logins with the root user by editing the "Authentication" section in `/etc/ssh/sshd_config`. Simply change `#PermitRootLogin yes` to `no` and uncomment the line:

    /etc/ssh/sshd_config

    PermitRootLogin no
    ...

Next, restart the SSH daemon:

    # systemctl restart sshd

You will now be unable to log in through SSH under root, but will still be able to log in with your normal user and use su or sudo to do system administration.

##### Restrict

Some automated tasks such as remote, full-system backup require full root access. To allow these in a secure way, instead of disabling root login via SSH, it is possible to only allow root logins for selected commands. This can be achieved by editing `~root/.ssh/authorized_keys`, by prefixing the desired key, e.g. as follows:

    command="/usr/lib/rsync/rrsync -ro /" ssh-rsa …

This will allow any login with this specific key only to execute the command specified between the quotes.

The increased attack surface created by exposing the root user name at login can be compensated by adding the following to `sshd_config`:

    PermitRootLogin forced-commands-only

This setting will not only restrict the commands which root may execute via SSH, but it will also disable the use of passwords, forcing use of public key authentication for the root account.

A slightly less restrictive alternative will allow any command for root, but makes brute force attacks infeasible by enforcing public key authentication. For this option, set:

    PermitRootLogin without-password

## Other SSH clients and servers

Apart from OpenSSH, there are many SSH clients and servers avaliable.

### Dropbear

Dropbear is a SSH-2 client and server. dropbear is available in the official repositories.

The commandline ssh client is named dbclient.

### SSH alternative: Mobile Shell - responsive, survives disconnects

From the Mosh website:

Remote terminal application that allows roaming, supports intermittent connectivity, and provides intelligent local echo and line editing of user keystrokes. Mosh is a replacement for SSH. It is more robust and responsive, especially over Wi-Fi, cellular, and long-distance links.

Install mosh from the official repositories or the latest revision mosh-git in the AUR.

## Tips and tricks

### Encrypted SOCKS tunnel

This is highly useful for laptop users connected to various unsafe wireless connections. The only thing you need is an SSH server running at a somewhat secure location, like your home or at work. It might be useful to use a dynamic DNS service like DynDNS so you do not have to remember your IP-address.

#### Step 1: start the connection

You only have to execute this single command to start the connection:

    $ ssh -TND 4711 user@host

where `user` is your username at the SSH server running at the `host`. It will ask for your password, and then you are connected! The `N` flag disables the interactive prompt, and the `D` flag specifies the local port on which to listen on (you can choose any port number if you want). The `T` flag disables pseudo-tty allocation.

It is nice to add the verbose (`-v`) flag, because then you can verify that it is actually connected from that output.

#### Step 2: configure your browser (or other programs)

The above step is completely useless if you do not configure your web browser (or other programs) to use this newly created socks tunnel. Since the current version of SSH supports both SOCKS4 and SOCKS5, you can use either of them.

- For Firefox: Edit > Preferences > Advanced > Network > Connection > Setting:
  Check the Manual proxy configuration radio button, and enter `localhost` in the SOCKS host text field, and then enter your port number in the next text field (`4711` in the example above).

Firefox does not automatically make DNS requests through the socks tunnel. This potential privacy concern can be mitigated by the following steps:

1. Type about:config into the Firefox location bar.
2. Search for network.proxy.socks_remote_dns
3. Set the value to true.
4. Restart the browser.

- For Chromium: You can set the SOCKS settings as environment variables or as command line options. I recommend to add one of the following functions to your `.bashrc`:

    function secure_chromium {
        port=4711
        export SOCKS_SERVER=localhost:$port
        export SOCKS_VERSION=5
        chromium &
        exit
    }

OR

    function secure_chromium {
        port=4711
        chromium --proxy-server="socks://localhost:$port" &
        exit
    }

Now open a terminal and just do:

    $ secure_chromium

Enjoy your secure tunnel!

### X11 forwarding

X11 forwarding is a mechanism that allows graphical interfaces of X11 programs running on a remote system to be displayed on a local client machine. For X11 forwarding the remote host doesn't need to have a full X11 system installed, however it needs at least to have xauth installed. xauth is a utility that maintains `Xauthority` configurations used by server and client for authentication of X11 session (source).

Warning: X11 forwarding has important security implications which should be at least acknowledged by reading relevant sections of `ssh`, `sshd_config` and `ssh_config` manual pages. See also a short writeup

#### Setup

On the remote system:

- install xorg-xauth and xorg-xhost from the official repositories
- in `/etc/ssh/sshd_config`:
  - verify that `AllowTcpForwarding` and `X11UseLocalhost` options are set to yes, and that `X11DisplayOffset` is set to 10 (those are the default values if nothing has been changed, see `man sshd_config`)
  - set `X11Forwarding` to yes
- then restart the sshd daemon.

On the client's side, enable the `ForwardX11` option by either specifying the `-X` switch on the command line for opportunistic connections, or by setting `ForwardX11` to yes in openSSH client's configuration file.

Tip: You can enable the `ForwardX11Trusted` option (`-Y` switch on the command line) if GUI is drawing badly or you receive errors; this will prevent X11 forwardings from being subjected to the X11 SECURITY extension controls. Be sure you have read the warning at the beginning of this section if you do so.

#### Usage

Log on to the remote machine normally, specifying the `-X` switch if ForwardX11 wasn't enabled in the client's configuration file:

    $ ssh -X user@host

If you receive errors trying to run graphical applications, try ForwardX11Trusted instead:

    $ ssh -Y user@host

You can now start any X program on the remote server, the output will be forwarded to your local session:

    $ xclock

If you get "Cannot open display" errors try the following command as the non root user:

    $ xhost +

The above command will allow anybody to forward X11 applications. To restrict forwarding to a particular host type:

    $ xhost +hostname

where hostname is the name of the particular host you want to forward to. See `man xhost` for more details.

Be careful with some applications as they check for a running instance on the local machine. Firefox is an example: either close the running Firefox instance or use the following start parameter to start a remote instance on the local machine:

    $ firefox -no-remote

If you get "X11 forwarding request failed on channel 0" when you connect (and the server `/var/log/errors.log` shows "Failed to allocate internet-domain X11 display socket"), make sure package xorg-xauth is installed. If its installation is not working, try to either:

- enable the `AddressFamily any` option in `sshd_config` on the server, or
- set the `AddressFamily` option in `sshd_config` on the server to inet.

Setting it to inet may fix problems with Ubuntu clients on IPv4.

For running X applications as other user on the SSH server you need to `xauth add` the authentication line taken from `xauth list` of the SSH logged in user.

### Forwarding other ports

In addition to SSH's built-in support for X11, it can also be used to securely tunnel any TCP connection, by use of local forwarding or remote forwarding.

Local forwarding opens a port on the local machine, connections to which will be forwarded to the remote host and from there on to a given destination. Very often, the forwarding destination will be the same as the remote host, thus providing a secure shell and, e.g. a secure VNC connection, to the same machine. Local forwarding is accomplished by means of the `-L` switch and it is accompanying forwarding specification in the form of `<tunnel port>:<destination address>:<destination port>`.

Thus:

    $ ssh -L 1000:mail.google.com:25 192.168.0.100

will use SSH to login to and open a shell on 192.168.0.100, and will also create a tunnel from the local machine's TCP port 1000 to mail.google.com on port 25. Once established, connections to localhost:1000 will connect to the Gmail SMTP port. To Google, it will appear that any such connection (though not necessarily the data conveyed over the connection) originated from 192.168.0.100, and such data will be secure as between the local machine and 192.168.0.100, but not between 192.168.0.100, unless other measures are taken.

Similarly:

    $ ssh -L 2000:192.168.0.100:6001 192.168.0.100

will allow connections to localhost:2000 which will be transparently sent to the remote host on port 6001. The preceding example is useful for VNC connections using the vncserver utility--part of the tightvnc package--which, though very useful, is explicit about its lack of security.

Remote forwarding allows the remote host to connect to an arbitrary host via the SSH tunnel and the local machine, providing a functional reversal of local forwarding, and is useful for situations where, e.g., the remote host has limited connectivity due to firewalling. It is enabled with the `-R` switch and a forwarding specification in the form of `<tunnel port>:<destination address>:<destination port>`.

Thus:

    $ ssh -R 3000:irc.freenode.net:6667 192.168.0.200

will bring up a shell on 192.168.0.200, and connections from 192.168.0.200 to itself on port 3000 (remotely speaking, localhost:3000) will be sent over the tunnel to the local machine and then on to irc.freenode.net on port 6667, thus, in this example, allowing the use of IRC programs on the remote host to be used, even if port 6667 would normally be blocked to it.

Both local and remote forwarding can be used to provide a secure "gateway," allowing other computers to take advantage of an SSH tunnel, without actually running SSH or the SSH daemon by providing a bind-address for the start of the tunnel as part of the forwarding specification, e.g. `<tunnel address>:<tunnel port>:<destination address>:<destination port>`. The `<tunnel address>` can be any address on the machine at the start of the tunnel, `localhost`, `*` (or blank), which, respectively, allow connections via the given address, via the loopback interface, or via any interface. By default, forwarding is limited to connections from the machine at the "beginning" of the tunnel, i.e. the `<tunnel address>` is set to `localhost`. Local forwarding requires no additional configuration, however remote forwarding is limited by the remote server's SSH daemon configuration. See the `GatewayPorts` option in `sshd_config(5)` for more information.

### Multiplexing

The SSH daemon usually listens on port 22. However, it is common practice for many public internet hotspots to block all traffic that is not on the regular HTTP/S ports (80 and 443, respectively), thus effectively blocking SSH connections. The immediate solution for this is to have `sshd` listen additionally on one of the whitelisted ports:

    /etc/ssh/sshd_config

    Port 22
    Port 443

However, it is likely that port 443 is already in use by a web server serving HTTPS content, in which case it is possible to use a multiplexer, such as sslh, which listens on the multiplexed port and can intelligently forward packets to many services.

### Speeding up SSH

You can make all sessions to the same host use a single connection, which will greatly speed up subsequent logins, by adding these lines under the proper host in `/etc/ssh/ssh_config`:

    Host examplehost.com
      ControlMaster auto
      ControlPersist yes
      ControlPath ~/.ssh/socket-%r@%h:%p

See the `ssh_config(5)` manual page for full description of these options.

Another option to improve speed is to enable compression with the `-C` flag. A permanent solution is to add this line under the proper host in `/etc/ssh/ssh_config`:

    Compression yes

Warning: `man ssh` states that "Compression is desirable on modem lines and other slow connections, but will only slow down things on fast networks". This tip might be counterproductive depending on your network configuration.

Login time can be shortened by using the `-4` flag, which bypasses IPv6 lookup. This can be made permanent by adding this line under the proper host in `/etc/ssh/ssh_config`:

    AddressFamily inet

Changing the ciphers used by SSH to less cpu-demanding ones can improve speed. In this respect, the best choices are arcfour and blowfish-cbc.

Warning: Please do not do this unless you know what you are doing; arcfour has a number of known weaknesses.

To use alternative ciphers, run SSH with the `-c` flag:

    $ ssh -c arcfour,blowfish-cbc user@server-address

To use them permanently, add this line under the proper host in `/etc/ssh/ssh_config`:

    Ciphers arcfour,blowfish-cbc

### Mounting a remote filesystem with SSHFS

Please refer to the Sshfs article to use sshfs to mount a remote system - accessible via SSH - to a local folder, so you will be able to do any operation on the mounted files with any tool (copy, rename, edit with vim, etc.). Using sshfs instead of shfs is generally preferred as a new version of shfs has not been released since 2004.

### Keep alive

Your ssh session will automatically log out if it is idle. To keep the connection active (alive) add this to `~/.ssh/config` or to `/etc/ssh/ssh_config` on the client.

    ServerAliveInterval 120

This will send a "keep alive" signal to the server every 120 seconds.

Conversely, to keep incoming connections alive, you can set

    ClientAliveInterval 120

(or some other number greater than 0) in `/etc/ssh/sshd_config` on the server.

### Saving connection data in ssh config

Whenever you want to connect to a ssh server, you usually have to type at least its address and the username. To save that typing work for servers you regularly connect to, you can use the personal `~/.ssh/config` or the global `/etc/ssh/ssh_config` files as shown in the following example:

    ~/.ssh/config

    Host myserver
        HostName 123.123.123.123
        Port 12345
        User bob
    Host other_server
        HostName test.something.org
        User alice
        CheckHostIP no
        Cipher blowfish

Now you can simply connect to the server by using the name you specified:

    $ ssh myserver

To see a complete list of the possible options, check out ssh_config's manpage on your system or the ssh_config documentation on the official website.

### Autossh - automatically restarts SSH sessions and tunnels

When a session or tunnel cannot be kept alive, for example due to bad network conditions causing client disconnections, you can use Autossh to automatically restart them. Autossh can be installed from the official repositories.

Usage examples:

    $ autossh -M 0 -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" username@example.com

Combined with sshfs :

    $ sshfs -o reconnect,compression=yes,transform_symlinks,ServerAliveInterval=45,ServerAliveCountMax=2,ssh_command='autossh -M 0' username@example.com: /mnt/example

Connecting through a SOCKS-proxy set by Proxy_settings :

    $ autossh -M 0 -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" -NCD 8080 username@example.com

With the `-f` option autossh can be made to run as a background process. Running it this way however means the passphrase cannot be entered interactively.

The session will end once you type `exit` in the session, or the autossh process receives a SIGTERM, SIGINT of SIGKILL signal.

#### Run Autossh automatically at boot via systemd

If you want to automatically start autossh, it is now easy to get systemd to manage this for you. For example, you could create a systemd unit file like this:

    [Unit]
    Description=AutoSSH service for port 2222
    After=network.target

    [Service]
    Environment="AUTOSSH_GATETIME=0"
    ExecStart=/usr/bin/autossh -M 0 -NL 2222:localhost:2222 -o TCPKeepAlive=yes foo@bar.com

    [Install]
    WantedBy=multi-user.target

Here `AUTOSSH_GATETIME=0` is an environment variable specifying how long ssh must be up before autossh considers it a successful connection, setting it to 0 autossh also ignores the first run failure of ssh. This may be useful when running autossh at boot. Other environment variables are available on the manpage. Of course, you can make this unit more complex if necessary (see the systemd documentation for details), and obviously you can use your own options for autossh, but note that the `-f` implying `AUTOSSH_GATETIME=0` does not work with systemd.

Then place this in, for example, /etc/systemd/system/autossh.service. Afterwards, you can then enable your autossh tunnels with, e.g.:

    $ systemctl start autossh

(or whatever you called the service file)

If this works OK for you, you can make this permanent by running

    $ systemctl enable autossh

That way autossh will start automatically at boot.

It is also easy to maintain several autossh processes, to keep several tunnels alive. Just create multiple .service files with different names.

## Changing SSH port number with socket activation (sshd.socket)

Create the file `/etc/systemd/system/sshd.socket.d/port.conf` with:

    [Socket]
    # Disable default port
    ListenStream=
    # Set new port
    ListenStream=12345

systemd will automatically listen on the new port after a reload:

    systemctl daemon-reload

## Troubleshooting

### Checklist

This is a first-steps troubleshooting checklist. It is recommended to check these issues before you look any further:

1. The client and server `~/.ssh` folder and its content should be accessible by its user:

      $ chmod 700 /home/USER/.ssh
      $ chmod 600 /home/USER/.ssh/*

2. Check that all files within client's and server's `~/.ssh` folder are owned by its user:

      $ chown -R USER: ~/.ssh

3. Check that the client's public e.g. `id_rsa.pub` key row is in the server's `authorized_keys` file.

4. Check you did not limit SSH access via `AllowUsers` in `/etc/ssh/sshd_config` (space separated).

#### Cleanup outdated keys (optional)

5. Delete old/invalid key rows in server's `~/.ssh/authorized_keys` file.

6. Delete old/invalid private and public keys within the clients `~/.ssh` folder.

#### Recommendations

7. Keep as less keys as possible in user's `~/.ssh/authorized_keys` file on the server.

### SSH connection left hanging after poweroff/reboot

SSH connection hangs after poweroff or reboot if systemd stop network before sshd. To fix that problem, comment and change the `After` statement:

    /usr/lib/systemd/system/systemd-user-sessions.service

    #After=remote-fs.target
    After=network.target

### Connection refused or timeout problem

#### Is your router doing port forwarding?

SKIP THIS STEP IF YOU ARE NOT BEHIND A NAT MODEM/ROUTER (eg, a VPS or otherwise publicly addressed host). Most home and small businesses will have a NAT modem/router.

The first thing is to make sure that your router knows to forward any incoming ssh connection to your machine. Your external IP is given to you by your ISP, and it is associated with any requests coming out of your router. So your router needs to know that any incoming ssh connection to your external IP needs to be forwarded to your machine running sshd.

Find your internal network address.

    ip a

Find your interface device and look for the inet field. Then access your router's configuration web interface, using your router's IP (find this on the web). Tell your router to forward it to your inet IP. Go to [1] for more instructions on how to do so for your particular router.

#### Is SSH running and listening?

    $ ss -tnlp

If the above command do not show SSH port is open, SSH is NOT running. Check `/var/log/messages` for errors etc.

#### Are there firewall rules blocking the connection?

Iptables may be blocking connections on port `22`. Check this with:

    # iptables -nvL

and look for rules that might be dropping packets on the `INPUT` chain. Then, if necessary, unblock the port with a command like:

    # iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT

For more help configuring firewalls, see firewalls.

#### Is the traffic even getting to your computer?

Start a traffic dump on the computer you are having problems with:

    # tcpdump -lnn -i any port ssh and tcp-syn

This should show some basic information, then wait for any matching traffic to happen before displaying it. Try your connection now. If you do not see any output when you attempt to connect, then something outside of your computer is blocking the traffic (e. g., hardware firewall, NAT router etc.).

#### Your ISP or a third party blocking default port?

Note: Try this step if you know you are not running any firewalls and you know you have configured the router for DMZ or have forwarded the port to your computer and it still does not work. Here you will find diagnostic steps and a possible solution.

In some cases, your ISP might block the default port (SSH port 22) so whatever you try (opening ports, hardening the stack, defending against flood attacks, et al) ends up useless. To confirm this, create a server on all interfaces (0.0.0.0) and connect remotely.

If you get an error message comparable to this:

    ssh: connect to host www.inet.hr port 22: Connection refused

That means the port is not being blocked by the ISP, but the server does not run SSH on that port (See security through obscurity).

However, if you get an error message comparable to this:

    ssh: connect to host 111.222.333.444 port 22: Operation timed out

That means that something is rejecting your TCP traffic on port 22. Basically that port is stealth, either by your firewall or 3rd party intervention (like an ISP blocking and/or rejecting incoming traffic on port 22). If you know you are not running any firewall on your computer, and you know that Gremlins are not growing in your routers and switches, then your ISP is blocking the traffic.

To double check, you can run Wireshark on your server and listen to traffic on port 22. Since Wireshark is a Layer 2 Packet Sniffing utility, and TCP/UDP are Layer 3 and above (see IP Network stack), if you do not receive anything while connecting remotely, a third party is most likely to be blocking the traffic on that port to your server.

##### Diagnosis via Wireshark

Install Wireshark with the wireshark-cli package, available in the official repositories.

And then run it using,

    tshark -f "tcp port 22" -i NET_IF

where NET_IF is the network interface for a WAN connection (see `ip a` to check). If you are not receiving any packets while trying to connect remotely, you can be very sure that your ISP is blocking the incoming traffic on port 22.

##### Possible solution

The solution is just to use some other port that the ISP is not blocking. Open the `/etc/ssh/sshd_config` and configure the file to use different ports. For example, add:

    Port 22
    Port 1234

Also make sure that other "Port" configuration lines in the file are commented out. Just commenting "Port 22" and putting "Port 1234" will not solve the issue because then sshd will only listen on port 1234. Use both lines to run the SSH server on both ports.

Restart the server `systemctl restart sshd.service` and you are almost done. You still have to configure your client(s) to use the other port instead of the default port. There are numerous solutions to that problem, but let us cover two of them here.

#### Read from socket failed: connection reset by peer

Recent versions of openssh sometimes fail with the above error message, due to a bug involving elliptic curve cryptography. In that case add the following line to `~/.ssh/config`:

    HostKeyAlgorithms ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss

With openssh 5.9, the above fix does not work. Instead, put the following lines in `~/.ssh/config`:

    Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
    MACs hmac-md5,hmac-sha1,hmac-ripemd160

See also the discussion on the openssh bug forum.

### "[your shell]: No such file or directory" / ssh_exchange_identification problem

One possible cause for this is the need of certain SSH clients to find an absolute path (one returned by `whereis -b [your shell]`, for instance) in `$SHELL`, even if the shell's binary is located in one of the `$PATH` entries.

### "Terminal unknown" or "Error opening terminal" error message

With ssh it is possible to receive errors like "Terminal unknown" upon logging in. Starting ncurses applications like nano fails with the message "Error opening terminal". There are two methods to this problem, a quick one using the $TERM variable and a profound one using the terminfo file.

#### Workaround by setting the $TERM variable

After connecting to the remote server set the $TERM variable to "xterm" with the following command.

`TERM=xterm`

This method is a workaround and should be used on ssh servers you do seldomly connect to, because it can have unwanted side effects. Also you have to repeat the command after every connection, or alternatively set it in ~.bashrc .

#### Solution using terminfo file

A profound solution is transferring the terminfo file of the terminal on your client computer to the ssh server. In this example we cover how to setup the terminfo file for the "rxvt-unicode-256color" terminal. Create the directory containing the terminfo files on the ssh server, while you are logged in to the server issue this command:

`mkdir -p ~/.terminfo/r/`

Now copy the terminfo file of your terminal to the new directory. Replace `rxvt-unicode-256color` with your client's terminal in the following command and `ssh-server` with the relevant user and server adress.

`$ scp /usr/share/terminfo/r/rxvt-unicode-256color ssh-server:~/.terminfo/r/`

After logging in and out from the ssh server the problem should be fixed.

## See also

- A Cure for the Common SSH Login Attack
- Defending against brute force ssh attacks
- OpenSSH key management, Part 1 and Part 2 on IBM developerWorks
- Secure Secure Shell

Category:

- Secure Shell