Openssh

When the SSH agent is running, the ssh-add command can be used to load a SSH key. The SSH agent then will request a password when needed, and load the key details in memory. Adding the SSH key just requires the path to the private key. ssh-add ~/.ssh/id_ed25519 When the key is loaded, use the -l or -L option to show the identities that the SSH agent has. ssh-add -l

The ProxyJump defines a bastion host (jump host, jump server, jump box) to use. Values Value Meaning none Disable ProxyJump functionality HOST Define the hostname of the bastion host [USER]HOST[:PORT] Define one or more parameters of the bastion host URI Define parameters in URI format Hostname Format: hostname User Format: user@hostname Port Format: hostname:port Command-line usage ssh -J bastion destinationsystem These parameters can also be specified in the format as a URI .

The ForwardAgent option specifies if SSH agent forwarding is allowed or not. ForwardAgent values Value Meaning Yes Agent forwarding is allowed No (default) Agent forwarding is not allowed PATH Path to the agent socket $VARIABLE Environment variable that stores the path 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.

The agent forwarding feature in SSH allows using your local SSH agent to be reached through an existing SSH connection. This way you don’t have to store copies of your private keys on intermediate systems to use them for authentication. While SSH agent forward simplifies things, it also introduces a new risk related to Unix domain socket. If a user on the intermediate system can access the related socket, then it may abuse this connection back to the SSH agent to authenticate on your behalf.

The ssh-agent command is started manually using eval $(ssh-agent). This will initiate the SSH agent and make it available for clients, such as ssh, to use it. To confirm that the agent is running is by looking at the SSH_AUTH_SOCK environment variable. Automatic start of SSH agent Gnome Keyring SSH Agent When using Gnome, it typically comes with its SSH agent as part of Keyring. This will automatically load any files in ~/.

The ssh-agent command starts the SSH agent, a helper utility to store private keys when using public key authentication. The ssh-agent process is usually started at the the beginning of a login session and then can be connected to by a SSH client. Clients can detect the environment variable named SSH_AUTH_SOCK. Related settings on the client IdentityAgent

Disable usage of SSH agent identities

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.

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.

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 Value Automatically save new host keys Action if host key changed yes No Refuse ask No, ask Refuse accept-new Yes Refuse no | off Yes Connect 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.

Disable check for host authenticity

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.

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) ~?

Use an escape sequence to terminate a connection that is stuck

Remove a passphrase from existing SSH key

How to see the available SSH keys in the OpenSSH authentication agent

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.