SSH

The ProxyJump defines a bastion host (jump host, jump server, jump box) to use.

Values

Hostname

Format: hostname

The ForwardAgent option specifies if SSH agent forwarding is allowed or not.

ForwardAgent values

Security caution

Agent forwarding should not be used if not strictly needed. Any user that can access the agent’s socket stored in SSH_AUTH_SOCK may have access through the forwarded connection. While key material may not be accessible, the keys can still be used to authenticate to any of the identities that are active in the SSH agent.

The IdentityAgent option specifies what UNIX-domain socket to use to communicate with the authentication agent. When configured, it overrides the environment variable SSH_AUTH_SOCK and provides the option to select a specific agent.

Besides the option to define a socket, the location of the socket can also be provided by the SSH_AUTH_SOCK environment variable. In that case the value should defined as “SSH_AUTH_SOCK” (without quotes). If the value starts with a ‘$’, it indicates that another enviroment variable is to be used.

Configuration files

• /etc/ssh/ssh_config
• ~/.ssh/config

Configuration settings

The client knows a lot of individual settings that may be configured in a configuration file or via the command-line.

IdentityAgent

Configure the socket to use for the SSH agent.

See IdentityAgent

Port

Defines the port to be used. By default, the SSH server is configured with port 22 (TCP).

ProxyJump

Defines a bastion host (jump host, jump server, jump box) to connect to the destination system.

For the SSH client there are typically two places where configuration files are stored: in the home directory of the user and a global configuration file.

User configuration

• Location: ~/.ssh/config

This file is stored in the home directory of an user. It is optional and by default no file is available.

System-wide configuration

• Location: /etc/ssh/ssh_config
• Overrides via: /etc/ssh/ssh_config.d/*.conf

The default settings are in the ssh_config file. The system administrator may add customizations to this file, but typically it is advised to override settings using a separate configuration file. This way settings are not being overwritten by accident when a new package is released.

The SSH client won’t connect to a system when it sees that host key changed since the initial connection it made. This helps against MitM attacks. The client knows when the host key is different by comparing it with the related values in the ~/.ssh/known_hosts file.

Values

When connecting to many different systems, the accept-new value can help reducing the manual step to accept keys.

One of the common methods to authenticate with a SSH server is using the combination of a username and password. With the option PasswordAuthentication we can define if we want to use this type of authentication. While yes is the default, it might be useful to disable it for hosts that require public key authentication. This way we instruct the client to only try that.

Why change your SSH port?

Systems that are available via the internet and can’t be fully protected with a firewall, they might benefit from running on a different TCP port than the default 22. This way automated scanners will less likely probe your system(s), as they don’t know what port you use for SSH.

Changing your SSH port won’t make a system more secure in itself, and therefore is often called security through obscurity. At the same, it may help in reducing noise in your logs, making it easier to monitor. This in itself slighly improves security, as system administrators typically start to ignore log files if they are flooded with authentication failures.

Configure a Message of the Day

The MOTD is typically stored in /etc/motd or a related directory, such as /etc/update-motd.d or /etc/motd.d/. The related message or messages are then displayed after a user is logged in.

Another option is that the MOTD is displayed using the PAM configuration. To see if this is the case, perform a grep in your PAM configuration directory.

grep -ir motd /etc/pam.d | grep -v ":#"

Escape sequences are a patterns of keys that are recognized to send special instructions.

To see the ones that are supported, press tilde (~) followed by a question mark (?).

Supported escape sequences:
 ~.   - terminate connection (and any multiplexed sessions)
 ~B   - send a BREAK to the remote system
 ~C   - open a command line
 ~R   - request rekey
 ~V/v - decrease/increase verbosity (LogLevel)
 ~^Z  - suspend ssh
 ~#   - list forwarded connections
 ~&   - background ssh (when waiting for connections to terminate)
 ~?   - this message
 ~~   - send the escape character by typing it twice
(Note that escapes are only recognized immediately after newline.)

Important: you may need to press enter first before sending the escape sequence.

The configuration of SSH happens on both the client and server side.

An important part of system administration is a secure connection to it. With SSH we can achieve this easily. At the same time, there is a lot more to this protocol and set of commands. In this section all articles and configuration are collected.

SSH or Secure Shell is a popular protocol for doing system administration on Linux systems. Sometimes you may need to know what version you are running to know if some specific configuration options are available. In this article we have a look at the available options.

Local OpenSSH version

The easiest way to find the installed OpenSSH version is using the ssh -V command. This works when being logged in to the system itself.

Rsync is still one of the most popular tools to synchronize files between two systems. Although it has a few caveats when dealing with special files, it can do its job very well. In this explainer we will show how to use it in combination with SSH and at the same restrict SSH access to only allow the rsync job to run.

In this article we refer to system01 having the original files and it wants to send them to the receiving system (system02)

SSH or Secure Shell is the popular protocol for doing system administration on Linux systems. It runs on most systems, often with its default configuration. As this service opens up a potential gateway into the system, it is one of the steps to hardening a Linux system. This article covers the SSH security tips to secure the OpenSSH service and increase the defenses of the system.

OpenSSH security

OpenSSH is under development by the security fanatics from the OpenBSD project. Every new piece of functionality is created with care, especially when it comes to security. Although there were some vulnerabilities, OpenSSH is fairly secure by default. There are still some steps left that can be improved. During research for the security auditing tool Lynis, we looked also at the available OpenSSH settings. Besides the tests that are now in Lynis, this article is one of the other results of that research.

Learn how to use Ed25519 keys instead of the older types

Linux systems are usually managed remotely with SSH (secure shell). Still many administrators are using passwords, instead of keys. Keys not only boost security, it also makes managing systems much easier. Instead of entering your password for each server, you only have to do it once per session. When managing several systems per day, you will be wondering why you ever used password based authentication before.

Generating the SSH key

Depending on your desktop platform, we first have to create a key pair. This will consist of a public and private key, which are both needed to work. The private key is private and should remain private. While not mandatory, it is very wise to protect it with a password. The public key will be configured on the remote system. This key is not secret at all, therefore it can safely stored on another machine, or even shared with others. Since people still make the mistake of sharing the private key, reassure yourself what key you are sharing at any given time.

SSH daemon

The OpenSSH daemon is named sshd and typically this is also the process visible in a process listing. The main listener usually has a full path visible, while active SSH sessions get their own child process.

Configuration files

• /etc/ssh/sshd_config
• /etc/ssh/sshd_config.d/*.conf

The configuration file sshd_config is the primary file for the settings. Any settings in a configuration file specified in /etc/ssh/sshd_config.d will overwrite those listed in the primary configuration file.