How to disable SSH timeout
SSH clients will automatically be disconnected from the server and prompt the below message after being idle or inactive for a while.
To avoid this we give you 2 options:
Option 1:
The fastest configuration directly in the terminal is the following:
ssh -o ConnectTimeout=10 iodocs.com
ssh -o ConnectTimeout=10 10.0.0.23
Option 2:
This is due to the SSH servers’ configuration (often by default) to avoid hanging sessions and free up resources. These are the related options in the SSH server configuration;
Edit ssh config.
sudo nano /etc/ssh/ssh_configTCPKeepAlive
Whether or not to send TCP “alive” message to the connecting clients to test for connection issues. Defaults to yes.
ClientAliveInterval
A timeout interval to send encrypted alive message to clients if no data has been received from connection. Defaults to 0 (not sending any message).
ClientAliveCountMax
Number of times to send the encrypted alive message before disconnecting clients if no response are received. Defaults to 3.
If you have administrative access to the SSH servers, you can change the options so that you will not easily be disconnected. Edit the SSH server configuration file (normally in /etc/ssh/sshd_config for Unix based operating systems) and set the related options as the followings (uncomment or add if necessary);
uncomment or add if necessary
TCPKeepAlive no
ClientAliveInterval 30
ClientAliveCountMax 100What it basically means is that the server will not send the TCP alive packet to check if the client’s connection is working, yet will still send the encrypted alive message every 30 seconds but will only disconnect after 24 hours of inactivity. Be sure to restart the SSH service after the reconfiguration. The following command would work for most Unix based servers;
sudo service sshd restartIf you don’t have administrative access to the server, you can configure the SSH client to send the alive message to the server instead. The key here is the ServerAliveInterval option for the SSH client.
You can do this by updating /etc/ssh/ssh_config (applying the setting to every user in the system) or in ~/.ssh/config (single user). Set the following option to have the client send the alive packet every 30 seconds to the server;
ServerAliveInterval 30The other alternative is to manually set the ServerAliveInterval option every time you’re connecting to a server by using the -o ServerAliveInterval= prefix as the following example;
ssh -o ServerAliveInterval=30 [email protected]
All congiguration:
sshd_config — OpenSSH SSH daemon configuration file
DESCRIPTION
sshd(8) reads configuration data from /etc/ssh/sshd_config (or the file specified with -f on the command line). The file contains keyword-argument pairs, one per line. For each keyword, the first obtained value will be used. Lines starting with ‘#’ and empty lines are interpreted as comments. Arguments may optionally be enclosed in double quotes (“) in order to represent arguments containing spaces.
The possible keywords and their meanings are as follows (note that keywords are case-insensitive and arguments are case-sensitive):
AcceptEnv
Specifies what environment variables sent by the client will be copied into the session’s environ(7). See SendEnv in ssh_config(5) for how to configure the client. The TERM environment variable is always sent whenever the client requests a pseudo-terminal as it is required by the protocol. Variables are specified by name, which may contain the wildcard characters ‘*’ and ‘?’. Multiple environment variables may be separated by whitespace or spread across multiple AcceptEnv directives. Be warned that some environment variables could be used to bypass restricted user environments. For this reason, care should be taken in the use of this directive. The default is not to accept any environment variables.
AddressFamily
Specifies which address family should be used by sshd(8). Valid arguments are any (the default), inet (use IPv4 only), or inet6 (use IPv6 only).
AllowAgentForwarding
Specifies whether ssh-agent(1) forwarding is permitted. The default is yes. Note that disabling agent forwarding does not improve security unless users are also denied shell access, as they can always install their own forwarders.
AllowGroups
This keyword can be followed by a list of group name patterns, separated by spaces. If specified, login is allowed only for users whose primary group or supplementary group list matches one of the patterns. Only group names are valid; a numerical group ID is not recognized. By default, login is allowed for all groups. The allow/deny directives are processed in the following order: DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups.
See PATTERNS in ssh_config(5) for more information on patterns.
AllowStreamLocalForwarding
Specifies whether StreamLocal (Unix-domain socket) forwarding is permitted. The available options are yes (the default) or all to allow StreamLocal forwarding, no to prevent all StreamLocal forwarding, local to allow local (from the perspective of ssh(1)) forwarding only or remote to allow remote forwarding only. Note that disabling StreamLocal forwarding does not improve security unless users are also denied shell access, as they can always install their own forwarders.
AllowTcpForwarding
Specifies whether TCP forwarding is permitted. The available options are yes (the default) or all to allow TCP forwarding, no to prevent all TCP forwarding, local to allow local (f
rom the perspective of ssh(1)) forwarding only or remote to allow remote forwarding only. Note that disabling TCP forwarding does not improve security unless users are also denied shell access, as they can always install their own forwarders.
AllowUsers
This keyword can be followed by a list of user name patterns, separated by spaces. If specified, login is allowed only for user names that match one of the patterns. Only user names are valid; a numerical user ID is not recognized. By default, login is allowed for all users. If the pattern takes the form USER@HOST then USER and HOST are separately checked, restricting logins to particular users from particular hosts. HOST criteria may additionally contain addresses to match in CIDR address/masklen format. The allow/deny directives are processed in the following order: DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups.
See PATTERNS in ssh_config(5) for more information on patterns.
AuthenticationMethods
Specifies the authentication methods that must be successfully completed for a user to be granted access. This option must be followed by one or more comma-separated lists of authentication method names, or by the single string any to indicate the default behaviour of accepting any single authentication method. If the default is overridden, then successful authentication requires completion of every method in at least one of these lists.
For example, “publickey,password publickey,keyboard-interactive” would require the user to complete public key authentication, followed by either password or keyboard interactive authentication. Only methods that are next in one or more lists are offered at each stage, so for this example it would not be possible to attempt password or keyboard-interactive authentication before public key.
For keyboard interactive authentication it is also possible to restrict authentication to a specific device by appending a colon followed by the device identifier bsdauth, pam, or skey, depending on the server configuration. For example, “keyboard-interactive:bsdauth” would restrict keyboard interactive authentication to the bsdauth device.
If the publickey method is listed more than once, sshd(8) verifies that keys that have been used successfully are not reused for subsequent authentications. For example, “publickey,publickey” requires successful authentication using two different public keys.
Note that each authentication method listed should also be explicitly enabled in the configuration.
The available authentication methods are: “gssapi-with-mic”, “hostbased”, “keyboard-interactive”, “none” (used for access to password-less accounts when PermitEmptyPassword is enabled), “password” and “publickey”.
AuthorizedKeysCommand
Specifies a program to be used to look up the user’s public keys. The program must be owned by root, not writable by group or others and specified by an absolute path. Arguments to AuthorizedKeysCommand accept the tokens described in the TOKENS section. If no arguments are specified then the username of the target user is used.
The program should produce on standard output zero or more lines of authorized_keys output (see AUTHORIZED_KEYS in sshd(8)). If a key supplied by AuthorizedKeysCommand does not successfully authenticate and authorize the user then public key authentication continues using the usual AuthorizedKeysFile files. By default, no AuthorizedKeysCommand is run.
AuthorizedKeysCommandUser
Specifies the user under whose account the AuthorizedKeysCommand is run. It is recommended to use a dedicated user that has no other role on the host than running authorized keys commands. If AuthorizedKeysCommand is specified but AuthorizedKeysCommandUser is not, then sshd(8) will refuse to start.
AuthorizedKeysFile
Specifies the file that contains the public keys used for user authentication. The format is described in the AUTHORIZED_KEYS FILE FORMAT section of sshd(8). Arguments to AuthorizedKeysFile accept the tokens described in the TOKENS section. After expansion, AuthorizedKeysFile is taken to be an absolute path or one relative to the user’s home directory. Multiple files may be listed, separated by whitespace. Alternately this option may be set to none to skip checking for user keys in files. The default is “.ssh/authorized_keys .ssh/authorized_keys2”.
AuthorizedPrincipalsCommand
Specifies a program to be used to generate the list of allowed certificate principals as per AuthorizedPrincipalsFile. The program must be owned by root, not writable by group or others and specified by an absolute path. Arguments to AuthorizedPrincipalsCommand accept the tokens described in the TOKENS section. If no arguments are specified then the username of the target user is used.
The program should produce on standard output zero or more lines of AuthorizedPrincipalsFile output. If either AuthorizedPrincipalsCommand or AuthorizedPrincipalsFile is specified, then certificates offered by the client for authentication must contain a principal that is listed. By default, no AuthorizedPrincipalsCommand is run.
AuthorizedPrincipalsCommandUser
Specifies the user under whose account the AuthorizedPrincipalsCommand is run. It is recommended to use a dedicated user that has no other role on the host than running authorized principals commands. If AuthorizedPrincipalsCommand is specified but AuthorizedPrincipalsCommandUser is not, then sshd(8) will refuse to start.
AuthorizedPrincipalsFile
Specifies a file that lists principal names that are accepted for certificate authentication. When using certificates signed by a key listed in TrustedUserCAKeys, this file lists names, one of which must appear in the certificate for it to be accepted for authentication. Names are listed one per line preceded by key options (as described in AUTHORIZED_KEYS FILE FORMAT in sshd(8)). Empty lines and comments starting with ‘#’ are ignored.
Arguments to AuthorizedPrincipalsFile accept the tokens described in the TOKENS section. After expansion, AuthorizedPrincipalsFile is taken to be an absolute path or one relative to the user’s home directory. The default is none, i.e. not to use a principals file – in this case, the username of the user must appear in a certificate’s principals list for it to be accepted.
Note that AuthorizedPrincipalsFile is only used when authentication proceeds using a CA listed in TrustedUserCAKeys and is not consulted for certification authorities trusted via ~/.ssh/authorized_keys, though the principals= key option offers a similar facility (see sshd(8) for details).
Banner
The contents of the specified file are sent to the remote user before authentication is allowed. If the argument is none then no banner is displayed. By default, no banner is displayed.
ChallengeResponseAuthentication
Specifies whether challenge-response authentication is allowed. All authentication styles from login.conf(5) are supported. The default is yes.
ChrootDirectory
Specifies the pathname of a directory to chroot(2) to after authentication. At session startup sshd(8) checks that all components of the pathname are root-owned directories which are not writable by any other user or group. After the chroot, sshd(8) changes the working directory to the user’s home directory. Arguments to ChrootDirectory accept the tokens described in the TOKENS section.
The ChrootDirectory must contain the necessary files and directories to support the user’s session. For an interactive session this requires at least a shell, typically sh(1), and basic /dev nodes such as null(4), zero(4), stdin(4), stdout(4), stderr(4), and tty(4) devices. For file transfer sessions using SFTP no additional configuration of the environment is necessary if the in-process sftp-server is used, though sessions which use logging may require /dev/log inside the chroot directory on some operating systems (see sftp-server(8) for details).
For safety, it is very important that the directory hierarchy be prevented from modification by other processes on the system (especially those outside the jail). Misconfiguration can lead to unsafe environments which sshd(8) cannot detect.
The default is none, indicating not to chroot(2).
