Using OpenSSH Client Utilities

Connecting to Another System Using the ssh Command

By default, each time you use the OpenSSH utilities to connect to a remote system, you must provide a username and password. When you connect to an OpenSSH server for the first time, the OpenSSH client prompts you to confirm that you're connected to the correct system.

Use the ssh command to log into a remote system or to run a command on a remote system:

ssh [options] [user@]host [command]

In the command, host is the name of the remote OpenSSH server to which you want to connect.

For example, you would log in to host04 by using the same username as is on the local system:

ssh host04

The remote system prompts you for the password on that system.

To connect as a different user, specify the username and @ symbol before the remote host name, for example:

ssh joe@host04

To run a command on the remote system, specify the command as an argument:

ssh joe@host04 ls ~/.ssh

The ssh command logs you in, runs the command, and then closes the connection.

Example 5-1 Example of Connecting to a System

The following examples show how you would connect to a remote host, host04. You would need to confirm the command action before establishing the connection.

ssh host04

The authenticity of host ‘host04 (192.0.2.104)’ can’t be
established.
RSA key fingerprint is 65:ad:38:b2:8a:6c:69:f4:83:dd:3f:8f:ba:b4:85:c7.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘host04,192.0.2.104’ (RSA) to the
list of known hosts.

When you type yes to accept the connection to the server, the client adds the server’s public host key to the $HOME/.ssh/known_hosts file. When you next connect to the remote server, the client compares the key in this file to the one that the server supplies. If the keys don't match, you see a warning such as the following:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@       WARNING: POSSIBLE DNS SPOOFING DETECTED!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The RSA host key for host has changed,
and the key for the according IP address IP_address
is unchanged. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
Offending key for IP in /home/user/.ssh/known_hosts:10
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is fingerprint
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:53
RSA host key for host has changed and you have requested strict checking.
Host key verification failed.

Unless the remote server’s host key has changed for a known reason, such as an upgrade of either the SSH software or the server, avoid connecting to that machine until you have contacted its administrator about the situation.

For more information, see the ssh(1) manual page.

Setting SSH Client Configuration Options For a Host

You can set up Host entries in the $HOME/.ssh/config file on a client system. Often usernames don't align on different systems. Sometimes you might choose to use a different key pair to the usual key pair for a particular remote system. To connect more easily with the correct credentials, you can add a host entry similar to the following example:

Host server1
  Hostname server1.example.com
  User remote_user
  IdentityFile ~/.ssh/id_rsa_example

With the provided configuration entry, the user can run:

ssh server1

The SSH client performs a connection to the remote server server1.example.com with the username remote_user and uses the private key file at ~/.ssh/id_rsa_example.

This configuration entry lets you connect with the correct credentials each time you want to connect. Without the configuration entry, you would need to enter the following:

ssh -i ~/.ssh/id_rsa_example remote_user@server1.example.com

You can use the $HOME/.ssh/config file to store other configuration options for any system that you connect to. For example, if you use the ForwardAgent or ProxyJump options often, consider adding entries for these for each host where you use them. See the ssh_config(5) manual page for more information.

Copying Files Between Systems Using the scp and sftp Commands

Using scp

Note:

Secure Copy Protocol (scp) is deprecated in Oracle Linux 9. If you're using Oracle Linux 9, use the secure file transfer (SFTP) utility instead. See the Security section under the Deprecated Features chapter in Oracle Linux 9: Release Notes for Oracle Linux 9.

With the scp command, you can copy files or directories between systems. scp establishes a connection, copies the files, and then closes the connection.

The following examples show how you can use the scp command.

Uploading a local file to a remote system
```
scp [options] local_file [user @]host[: remote_file]
```
For example:
- Copy testfile to the home directory on host04.
```
scp testfile host04
```
- Copy testfile to the same directory but change its name to new_testfile.
```
scp testfile host04:new_testfile
```
Downloading a file from a remote system to the local system
```
scp [options] [user@]host[:remote_file] local_file
```
Copying files recursively

The -r option recursively copies the contents of directories.

For example, to copy the directory remdir and its contents from the home directory on remote host04 to the local home directory, you would type:
```
scp -r host04:~/remdir ~
```

Using sftp

The sftp command is a secure alternative to the ftp command that's used to transfer files between systems. Unlike the scp command, the sftp command enables you to browse the file system on the remote server before copying any files.

To open an FTP connection to a remote system over SSH, use the following command:

sftp [options] [user@]host

For example, you would open an FTP connect to the system, host04, as follows:

sftp host04

Connecting to host04...
guest@host04’s password: password
sftp>

Type sftp commands at the sftp> prompt.

In the following example, the put command is used to upload the file newfile from the local system to the remote system, then the ls command is used to list it:

sftp> put newfile
Uploading newfile to /home/guest/newfile
foo                                           100% 1198     1.2KB/s   00:01    
sftp> ls newfile
newfile

Type help or ? to display a list of available commands. Type bye, exit, or quit to close the connection and exit the sftp interactive session.

For more information, see the ssh(1) and sftp(1) manual pages.

Using the SSH Key Agent to Remember Passphrases

Use the SSH Key Agent to enter the passphrases for any of the SSH keys a single time throughout the login session. In this manner, you avoid the poor security practice of creating SSH keys without passphrases.

After you log in, check that the agent is started:
```
ps -ef|grep -i ssh-agent
```
Run the ssh-add command to add any of the ssh keys to the agent:
```
ssh-add $HOME/.ssh/id_rsa
```
The command prompts you for the key passphrase. The passphrase applies through the entire login session. If you use the key to connect to another system, the prompt for a passphrase no longer appears.

Note:

The error message Could not open a connection to your authentication agent indicates that the agent might not be running. Start it with the eval $(ssh-agent -s) command.
Repeat the command for each key that you want to add.
After adding the keys to the agent, you can open SSH connections to any systems that have the paired public key configured in the authorized_hosts file, without being prompted for a passphrase. This behavior applies also to any scripts that are run as the user.

Using SSH Agent Forwarding for Access Through a Bastion Host

Caution:

Enable agent forwarding with caution. Users with escalated privileges on the remote host can access the agent through the forwarded SSH session. Although malicious users can't access the keys directly they can hijack the agent session and use the keys in the agent to connect to other systems. If you're connecting to a system that might have untrustworthy users then avoid using agent forwarding.

SSH Agent Forwarding is a powerful tool that can help you keep private keys centralized and safe. Avoid copying private keys to other systems as much as possible. SSH Agent Forwarding lets you connect to a remote system and then use the SSH client on that system to connect to another system by using the same key based authentication but without you needing to copy the private key to the host that you first connected to.

Server-side Configuration

Change the /etc/ssh/sshd_config file to configure SSH Agent forwarding. On the server, verify the AllowAgentForwarding parameter, which activates SSH agent forwarding and is enabled by default.

Client Configuration

To enable this functionality you must use the ForwardAgent option when you make a connection to an intermediate system in the chain of hosts that you connect to. You must also have the private key already loaded into the SSH Agent on the primary client host. See Using the SSH Key Agent to Remember Passphrases .

To use SSH Agent Forwarding:

Check that the SSH Agent is running and that the SSH key is loaded. Run the following command on the client system to see what keys the agent has loaded:
```
ssh-add -L
```
Connect to a host using the ForwardAgent=yes option:
```
ssh -o ForwardAgent=yes server1.example.com
```
Use the SSH client on the remote host to connect to another server that has the public key configured in its authorized_keys:
```
ssh server2.example.com
```

Consider adding the ForwardAgent option to a Host configuration entry in the $HOME/.ssh/config file if you use this option often for a particular server. See Setting SSH Client Configuration Options For a Host for more information.

Using ProxyJump For Access Through a Bastion Host

SSH Agent forwarding lets you connect from one server to the next using key-based authentication without copying the private key to each server in the chain. This approach raises some security concerns because users with the appropriate privileges on the remote server could hijack the agent and use it to connect to other systems without requiring authentication.

A more secure approach to jumping from one server to the next is to use the ProxyJump option in the OpenSSH client. The ProxyJump option functions similarly to an SSH tunnel or port forward in the sense that it proxies all traffic straight through the bastion or jump host. Unlike port forwarding, ProxyJump option doesn't require server-side configuration. You only need to have SSH access to the bastion or jump host.

Consider that internal.example.com is a host on an internal network that you don't have direct access to. bastion.example.com is a host that's connected to the internal network and is also accessible to the client system. To connect to internal.example.com, you can use the ProxyJump option to connect directly through bastion.example.com. For example:

ssh -o 'ProxyJump=bastion.example.com' internal.example.com

If you constantly connect to internal.example.com, you can set the ProxyJump option for that host inside the $HOME/.ssh/config file. See Setting SSH Client Configuration Options For a Host.

Using X11 Forwarding to Load Remote Graphical Applications

X11 forwarding lets a user start graphical applications installed on a remote Linux system so that they display within the desktop environment of the local system. The remote system doesn't need to have an X11 server or graphical desktop environment running, but the local system must have an X11 compatible service running.

Server-side Configuration

Change the /etc/ssh/sshd_config file to enable X11 forwarding. On the server, verify the following parameters:

X11Forwarding

Allows X11 forwarding. When omitted, the default is no. To enable X11 forwarding, add an entry that sets the value for this parameter to yes.
If you edit the configuration file, you must restart the service for the change to take effect:
```
sudo systemctl restart ssh
```
The remote system must also be able to run X11 applications and authenticate X11 sessions. The xorg-x11-xauth package is required for this purpose.
```
dnf install xorg-x11-xauth
```
If you have never run a graphical application on the remote server, the first time that you connect to the remote server using X11 forwarding, a warning message is displayed:
```
/usr/bin/xauth: file /home/user/.Xauthority does not exist
```
You can ignore this warning as the .Xauthority file is automatically created.

Client Configuration

Use the -X option with the SSH client when you connect to a remote server:
```
ssh -X user@server1.example.com
```
Run a graphical application over the SSH connection by typing the command directly from the SSH terminal. You might opt to run the process in the background so that the terminal remains available to you. For example:
```
gedit &
```

Setting Up Port Forwarding Over SSH

SSH port forwarding creates an encrypted SSH tunnel between a client and a server system.

Three types of SSH port forwarding are available:

Local Port Forwarding: Forwards a port from the client to the SSH server and then to the destination port.
Dynamic Port Forwarding: Creates a SOCKS proxy server for communications across a range of ports.
Reverse Port Forwarding: Forwards a port from the server to the client and then to the destination port.

Why Use Port Forwarding?

Port forwarding lets remote servers to access devices within a private local-area network (LAN) and conversely.

You can use port forwarding to access a service that's not exposed to the public network interface. You might set up a local port forward to access a service (such as a database) on a remote server. The database on the server isn't exposed to the public network interface, but you could create a tunnel from a local machine to the internal database server port. You can then connect to localhost and all traffic would get forwarded across the SSH tunnel to the remote database.

You can use reverse port forwarding to give someone outside the local network access to an internal service. For example, you might want to show a fellow developer a web application that you have developed on the local machine. Because the machine doesn't have a public IP, the other developer can't access the application over the internet. However, if you have access to a remote SSH server, you can set up reverse port forwarding to provide the developer access.

Server-side Configuration

Edit the /etc/ssh/sshd_config file to configure SSH port forwarding. On the server, at a minimum verify the following parameters:

AllowTCPForwarding

Allows TCP port forwarding. When omitted, the default is yes which enables single TCP port forwards and SOCKS proxying
AllowStreamLocalForwarding

Allows forwarding of UNIX domain sockets. When omitted, the default is yes.

Local Port Forwarding

To create a direct TCP forward tunnel, use the ssh -L option:

ssh -L [bind_address:]port:destination:destination_port [user@]remote_ssh_server

bind_address is optional and assigns a local interface to listen for connections. If omitted, ssh only binds on the loopback interfaces. To bind on all interfaces, you can use “0.0.0.0” or “::”.
port - The local port number. You can use any port number greater than 1024.
destination - The IP or hostname of the destination machine. If the destination is on the remote server itself, you can use localhost.
destination_port - Port on the destination machine.
[user@]remote_ssh_server - The remote SSH user and server IP address.

For example:

ssh -L 8080:localhost:8888 user@192.168.1.20

This would open an SSH connection to the remote server at 192.168.1.20 and open a tunnel to the localhost port 8888.

Dynamic Port Forwarding

Use dynamic port forwarding to have the SSH client listen on a specified binding port and act as a SOCKS proxy server. You don't need to specify a destination host as all incoming connections on the specified port forward through the tunnel to a dynamic port on the destination machine.

To create a dynamic port forward, use the ssh -D option.

ssh -D [bind_address:]port [user@]remote_ssh_server

Reverse Port Forwarding

A reverse tunnel forwards any connection received on the remote SSH server to the local client network.

To create a reverse port forward, use the ssh -R option.

For local port reverse forwarding:

ssh -R [bind_address:]port:destination:destination_port [user@]remote_ssh_server

For dynamic port reverse forwarding:

ssh -R [bind_address:]port [user@]remote_ssh_server