Configure SSH for centron Cloud Servers

SSH (Secure Shell) lets you connect to a remote cloud server using a command-line tool or a GUI client. SSH is a network protocol that also powers other tools such as scp and rsync. Scp transfers files between hosts on a network. Rsync can use SSH to move files and directories between a local machine and a remote host. Rsync only copies data that has changed since the previous sync. That makes it ideal for efficiently backing up full projects with minimal overhead.

This guide shows how to set up SSH on a local host and on a remote centron host. It also explains how to use the centron Web Console to avoid locking yourself out by mistake. The guide covers how to:

• Set up the local SSH client for key-based login
• Limit root access and turn off password logins
• Use a different SSH port to reduce unauthorized attempts
• Install and configure fail2ban to mitigate brute-force attacks
• Enable SSH Agent Forwarding for non-root users
• Use SSH tunneling
• Copy files with scp
• Create backups using rsync

This guide uses the OpenSSH ssh command-line client, available on most Unix-like systems, including macOS and Linux. On Windows 10/11, you can use the Windows Subsystem for Linux to access the OpenSSH client.

For the examples in this guide, the centron server FQDN is ap1.example.com. The local macOS host is imac1. The local Debian host is db1.

Note: The SSH commands are identical on macOS and Debian Linux terminals unless stated otherwise.

Prerequisites

You need a centron Account. This guide uses macOS and Debian Linux to demonstrate SSH usage, but most other Linux environments with the OpenSSH client work the same way. First, you create a private/public SSH key pair on your local host, then add the public key to your centron Account. After that, you can auto-install the key when deploying a centron server. If the server already exists, you can add the key later.

You should already be comfortable with:

• Installing command-line tools on macOS with Homebrew (brew) or on Linux with apt.
• Using a firewall (for example UFW) to open or close ports.
• Working in the command line.

Note: Commands that start with $ are run as a regular (non-privileged) user, and commands that start with # are run as root.

Configure the Local SSH Client

1. Generate an SSH Key Pair

Create a modern SSH key pair using this command:

george@imac1:~
$ ssh-keygen -t ed25519 -C "hostname"

The -C comment is often an email address, but it can be any label. Setting it to your hostname helps you track which keys belong to which machine. Save each host’s key pair under a unique filename, and enter a passphrase when asked. To generate a long, strong passphrase, use pwgen:

george@imac1:~
$ pwgen -s 64 1
H7zhGFO6DeMAf1gvMCFOaWcbmlJrcE9VXI1Oj81zlBGN2GFpFhhxw8hT4qyyU4jl

Note: Install pwgen with brew or apt.

Complete example:

george@imac1:~
$ ssh-keygen -t ed25519 -C "ap1"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/Users/george/.ssh/id_ed25519): /Users/george/.ssh/ap1_ed25519
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/george/.ssh/ap1_ed25519.
Your public key has been saved in /Users/george/.ssh/ap1_ed25519.pub.
The key fingerprint is:
SHA256:RHQ9bSUV9TwKahLLr0crwYZvMVIcxJiFbSGO+PDKzr8 ap1
The key's randomart image is:
+--[ED25519 256]--+
|     .O=+ .. ..+*|
|  . o+.* .  o oo.|
| o . .o.o  . o .o|
|  +   .+o . . . .|
|   o  ++So   .   |
|. .  o *+.       |
| o    + =..      |
|o      +.o       |
| o.E. ..o        |
+----[SHA256]-----+

When prompted, paste your passphrase. It won’t be shown as you type. The filename prompt is optional; ~/.ssh/id_ed25519 is the default. Create a distinct key pair per host.

2. Add the Public Key

Sign in to your centron account. Under your account name, open SSH Keys, then click Add SSH Key. Give the key a name, paste your public key (for example ~/.ssh/ap1_ed25519.pub) into the key field, and click Add SSH Key.

Deploy a new Debian 11 server. In the SSH Keys section, select your key. centron will automatically place it for the root user in ~/.ssh/authorized_keys.

Note: After the server starts, allow a few minutes for Cloud-init to finish. Open the View Console window and wait until you see the Cloud-init completion message.

If your server already exists, you can choose Reinstall SSH Keys in the Settings tab to (re)apply your key.

Note: This removes all data and reinstalls the server operating system.

You can also use ssh-copy-id to add your public key to an existing server. This copies the key into ~/.ssh/authorized_keys on your centron host. Make sure ap1.example.com is present in DNS or in /etc/hosts on your local machine. Enter the root password when asked:

george@imac1:~
$ ssh-copy-id -i ~/.ssh/ap1_ed25519 root@ap1.example.com
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/Users/george/.ssh/ap1_ed25519.pub"
The authenticity of host 'ap1.example.com (66.42.117.31)' can't be established.
ECDSA key fingerprint is SHA256:fqAViH4GleZO7oMYkr+Qu92kewU7xzZeeUSmfPDMEOA.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
root@ap1.example.com's password:

Number of key(s) added:        1

Now try logging into the machine, with:   "ssh 'root@ap1.example.com'"
and check to make sure that only the key(s) you wanted were added.

Note: The host authenticity message appears the first time you connect. Type yes to proceed. The sample login command won’t work unless you use the default identity name ~/.ssh/id_ed25519. See the next section for testing a non-default key. If you previously connected via SSH and then reinstalled the server, you may see this warning:

$ ssh-copy-id -i ~/.ssh/ap1_ed25519 root@ap1.example.com
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/Users/george/.ssh/ap1_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed

/usr/bin/ssh-copy-id: ERROR: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
ERROR: @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
ERROR: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
ERROR: IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
 o o o
Just delete the previous ap1 entry in ~/.ssh/known_hosts and run the command again.

3. Verify the Public Key

Run this command to confirm you can log in with your SSH key:

george@imac1:~
$ ssh -i ~/.ssh/ap1_ed25519 root@ap1.example.com
Enter passphrase for key '/Users/george/.ssh/ap1_ed25519': 
Linux ap1 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) x86_64
 o o o
root@ap1:~#

The -i option is unnecessary if you used the default filename id_ed25519. You’ll be prompted for the passphrase each time unless you load the key into ssh-agent. Use ssh-add to store the private key:

george@imac1:~
$ ssh-add -K ~/.ssh/ap1_ed25519
Enter passphrase for /Users/george/.ssh/ap1_ed25519: 
Identity added: /Users/george/.ssh/ap1_ed25519 (ap1)

Note: On macOS, -K saves the passphrase in Keychain so it survives reboots. The Linux version of ssh-add does not support -K. The next section shows how to auto-load keys into ssh-agent after the first SSH session.

macOS and Debian Linux both rely on ssh-agent to cache private keys. On macOS, the agent starts automatically and integrates with Keychain. On Debian, you can start and stop the agent per session by adding these lines:

george@db1:~
$ echo 'eval `ssh-agent` > /dev/null' >> ~/.profile

george@db1:~
$ echo 'eval `ssh-agent -k` > /dev/null' >> ~/.bash_logout

After applying the changes, restart your local Linux terminal. Then load the key:

george@db1:~
$ ssh-add ~/.ssh/ap1_ed25519
Enter passphrase for /home/george/.ssh/ap1_ed25519: 
Identity added: /home/george/.ssh/ap1_ed25519 (ap1)

You can now connect to the server without typing the passphrase again during that terminal session.

4. Create a Local SSH Config File

You can define SSH settings globally and per host in a configuration file. This makes connecting simpler and allows short aliases instead of full FQDNs. Below is an example of ~/.ssh/config for the sample server:

Host *
  AddKeysToAgent yes
  UseKeychain yes
  IdentitiesOnly yes
  AddressFamily inet

Host ap1.example.com ap1
  Hostname ap1.example.com
  Port 22
  User george
  IdentityFile ~/.ssh/ap1_ed25519

Note: On Linux, remove the UseKeychain option.

Host * sets defaults for all connections. AddKeysToAgent pushes private keys into ssh-agent. The macOS-only UseKeychain stores the passphrase in Keychain. IdentitiesOnly restricts authentication to the key specified by IdentityFile. AddressFamily inet forces IPv4. The line Host ap1.example.com ap1 defines two aliases: the FQDN and a short name. The remaining entries declare the remote hostname, SSH port, default user, and key file. If Port isn’t specified, it defaults to 22, but you can set another port if desired. The User value is used when no user is supplied on the command line.

With this config, connect using the short alias:

george@imac1:~
$ ssh root@ap1
Enter passphrase for key '/Users/george/.ssh/ap1_ed25519':
Linux ap1 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) x86_64
 o o o
root@ap1:~#

When you make the initial SSH connection, enter the passphrase once. The key is then loaded into the agent automatically:

george@imac1:~
$ ssh-add -l
256 SHA256:XoidSmFlhy1gx5wiYDMMPYFvNY5xiRdwEi/i61rNVmA ap1 (ED25519)

On macOS, the passphrase is saved in Keychain. To confirm, open the Keychain app, select the default login keychain, and search for ap1. On Linux, the passphrase remains available for the duration of the terminal session.

To connect as the default user on the server, simply run:

george@imac1:~
$ ssh ap1
Linux apnet1 5.10.0-13-amd64 #1 SMP Debian 5.10.106-1 (2022-03-17) x86_64
 o o o
george@ap1:~
$

Note: This example assumes the default user account exists on the server.

Restrict Root Login and Turn Off Password Authentication

Allowing the root user to sign in over SSH is considered unsafe. Instead, use the centron Web Console or connect as a normal user first and then elevate to root. This keeps an audit trail of which standard users accessed root. Before you block root SSH access and disable password-based logins, create a regular user that has sudo rights.

1. Create the Default Regular User

Log in as root, create the user, and assign sudo privileges:

root@ap1:~# adduser george

When asked, set a strong password. Fill out any extra user details as you like. Then add the user to the sudo group:

root@ap1:~# usermod -aG sudo george

Confirm that you can sign in to the new account:

$ ssh ap1
george@ap1.example.com's password: 
Linux ap1 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) x86_64
 o o o
george@ap1:~$

Install your SSH public key for this user:

george@imac1:~
$ ssh-copy-id -i ~/.ssh/ap1_ed25519 ap1

Enter the user password when prompted.

Check that the user can now log in without a password:

george@imac1:~
$ ssh ap1
Linux ap1 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) x86_64
 o o o
george@ap1:~$

Verify that sudo lets you switch to root:

george@ap1:~$ sudo -i

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

[sudo] password for george:
root@ap1:~#

Type your user password when asked. Sudo will cache it for about 15 minutes.

Note: On Debian, this “trust” message appears only the first time you use sudo.

You can see root access performed by a normal user inside /var/log/auth.log:

Apr  5 21:09:34 ap1 sudo:   george : TTY=pts/1 ; PWD=/root ; USER=root ; COMMAND=/bin/bash
Apr  5 21:09:34 ap1 sudo: pam_unix(sudo:session): session opened for user root(uid=0) by george(uid=1000)
Apr  5 21:09:45 ap1 sudo: pam_unix(sudo:session): session closed for user root

You can also become root with su:

george@ap1:~$ su -
Password: 
root@ap1:~#

Note: Here, enter the root password.

This access is also logged in /var/log/auth.log:

Apr  5 21:12:38 ap1 su: (to root) george on pts/1
Apr  5 21:12:38 ap1 su: pam_unix(su-l:session): session opened for user root(uid=0) by george(uid=1000)
Apr  5 21:12:49 ap1 su: pam_unix(su-l:session): session closed for user root

In everyday work, sudo is typically used for single commands that need higher privileges.

Example:

george@ap1:~$ ls -l /root
ls: cannot open directory '/root': Permission denied

george@ap1:~$ sudo ls -l /root
total 4
drwxr-xr-x 2 root root 4096 Apr  5 20:35 orig

And the related log entries in /var/log/auth.log:

Apr  5 21:21:13 ap1 sudo:   george : TTY=pts/1 ; PWD=/home/george ; USER=root ; COMMAND=/usr/bin/ls -l /root
Apr  5 21:21:13 ap1 sudo: pam_unix(sudo:session): session opened for user root(uid=0) by george(uid=1000)
Apr  5 21:21:13 ap1 sudo: pam_unix(sudo:session): session closed for user root

2. Block Root Access and Disable Password Logins

As root, edit /etc/ssh/sshd_config like this:

• Change PermitRootLogin yes to PermitRootLogin no.
• Change #PasswordAuthentication yes to PasswordAuthentication no. If the line is commented, remove the #.

Restart the SSH daemon:

george@ap1:~$ sudo systemctl restart sshd

From another host without SSH key authentication (or after turning it off), try logging in as root and as the user:

george@db1:~
$ ssh root@ap1
root@ap1.example.com: Permission denied (publickey).

george@db1:~
$ ssh george@ap1
george@ap1.example.com: Permission denied (publickey).

Even when key authentication is enabled, root access still fails:

george@imac1:~
$ ssh root@ap1
root@ap1.example.com: Permission denied (publickey).

But the normal user can connect successfully:

george@imac1:~
$ ssh george@ap1
Linux ap1 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) x86_64
 o o o
george@ap1:~$

Set an Alternate SSH Port to Cut Down Unauthorized Attempts

Switching the SSH port typically lowers the volume of random login attempts. You can review such attempts in /var/log/auth.log:

george@ap1:~$ sudo grep sshd /var/log/auth.log | grep root
Apr  6 16:28:42 ap1 sshd[30840]: Disconnected from authenticating user root 43.133.165.86 port 48314 [preauth]
Apr  6 16:31:49 ap1 sshd[30887]: Disconnected from authenticating user root 43.133.165.86 port 48382 [preauth]
Apr  6 16:34:58 ap1 sshd[30895]: Disconnected from authenticating user root 43.133.165.86 port 48448 [preauth]
 o o o

SSH is designed to run on a privileged port (below 1024). You can choose any unused port that isn’t already reserved for another service. Check /etc/services to confirm a port is free. For example, to move SSH to port 522, proceed like this:

If your firewall is enabled, allow port 522:

george@ap1:~$ sudo ufw allow 522/tcp

Note: This example uses UFW, which is enabled by default on a fresh centron Debian/Ubuntu instance.

Change the SSH port to 522 in /etc/ssh/sshd_config and restart the daemon:

/etc/ssh/sshd_config:
< #Port 22
---
> Port 522

george@ap1:~$ sudo systemctl restart sshd

Your current SSH session should stay open. If you get disconnected, use the centron Web Console to reconnect and verify the changes.

Confirm that port 22 no longer accepts connections:

george@imac1:~
$ ssh ap1
ssh: connect to host ap1.example.com port 22: Connection refused

Update your local ~/.ssh/config to use port 522 for this host, then verify login still works:

Host ap1.example.com ap1
  Hostname ap1.example.com
  Port 522
  User george
  IdentityFile ~/.ssh/ap1_ed25519

george@imac1:~
$ ssh ap1
Linux ap1 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) x86_64
 o o o
george@ap1:~$

If a firewall is active, remove access to port 22:

george@ap1:~$ sudo ufw delete allow 22

If you are using the centron Firewall, follow the same steps there as well.

Configure Fail2ban to Limit Brute-Force Attacks

Fail2ban integrates with the firewall installed on your server, for example UFW, and blocks abusive hosts that trigger several failed login attempts within a short window.

Install fail2ban:

george@ap1:~$ sudo apt install fail2ban

Out of the box, SSH protection is enabled:

george@ap1:~$ sudo fail2ban-client status
Status
|- Number of jail:  1
`- Jail list:       sshd

george@ap1:~$ sudo fail2ban-client status sshd
Status for the jail: sshd
|- Filter
|  |- Currently failed:     0
|  |- Total failed: 0
|  `- File list:    /var/log/auth.log
`- Actions
   |- Currently banned:     0
   |- Total banned: 0
   `- Banned IP list:

If you changed your SSH port, you must adjust the fail2ban SSH jail by creating /etc/fail2ban/jail.local:

[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 72.xx.yy.zz

[sshd]
port = 522
findtime = 15m
bantime = 2h
maxretry = 3

This example also demonstrates how to tune the detection interval (findtime), ban duration (bantime), and the maximum retries allowed inside the findtime window before the host is blocked. The DEFAULT section lets you define global rules such as IPs that should never be banned. Setting ignoreip to your own SSH source address prevents accidental lockouts. After saving the file, restart fail2ban:

george@ap1:~$ sudo systemctl restart fail2ban

Note: If you forget to add the ignoreip entry like I did, log in using the centron View Console and run the unban command shown below.

Bans remain active after restarting the service. The status output lists banned IPs:

Status for the jail: sshd
|- Filter
|  |- Currently failed:     2
|  |- Total failed: 167
|  `- File list:    /var/log/auth.log
`- Actions
   |- Currently banned:     3
   |- Total banned: 29
   `- Banned IP list:       36.110.228.254 208.115.245.214 67.52.195.108

You can remove a ban before the timer expires with:

sudo fail2ban-client set sshd unbanip 67.52.195.108
1

Use the status command to confirm the IP is unbanned. You can also check ban and unban history in the fail2ban log:

root@ap1:~# egrep "Ban|Unban" /var/log/fail2ban.log | grep 67.52.195.108
2022-04-11 14:55:15,351 fail2ban.actions        [35842]: NOTICE  [sshd] Ban 67.52.195.108
2022-04-11 15:34:53,087 fail2ban.actions        [53811]: NOTICE  [sshd] Restore Ban 67.52.195.108
2022-04-11 15:47:48,050 fail2ban.actions        [53811]: NOTICE  [sshd] Unban 67.52.195.108

Fail2ban re-applies bans after a restart. The log shows when an IP is unbanned after you run the unban command. This failed/banned login example used SSH port 22. After moving SSH to another port, you usually see fewer failed attempts.

Configure SSH Agent Forwarding for Non-Root Users

SSH agent forwarding lets you reach server B from server A while the private key for server B remains on your local machine. A typical case is logging into server A (the ap1 host) and pulling code from GitHub.com. You don’t need to store your GitHub SSH keys on the remote server, because the remote host forwards the authentication request to the SSH agent on your local system. Agent forwarding must be explicitly enabled for the remote host. The example below uses GitHub and the ap1 server to illustrate setup.

1. Create and Install GitHub SSH Keys

If you haven’t created GitHub keys yet, run:

george@imac1:~
$ ssh-keygen -t ed25519 -C "GitHub"

Store the GitHub keys at ~/.ssh/GitHub and protect them with a strong passphrase.

Add the GitHub private key to your local SSH agent:

george@imac1:~
$ ssh-add -K ~/.ssh/GitHub_ed25519
Enter passphrase for /Users/george/.ssh/GitHub_ed25519:
Identity added: /Users/george/.ssh/GitHub_ed25519 (GitHub)

List keys currently loaded in the agent:

george@imac1:~
$ ssh-add -L
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMjM9PSuyKe3p4gJokzGHzY5mQXq52UDajrY9A2dRfFG GitHub

Install your GitHub public key through the GitHub Settings page.

2. Create the GitHub SSH Agent Forwarding Profile

Add a GitHub host entry to ~/.ssh/config:

Host github.com
  Hostname github.com
  Port 22
  IdentityFile ~/.ssh/GitHub_ed25519

Test the GitHub SSH authentication from your local host:

george@imac1:~
$ ssh git@github.com
Warning: Permanently added the ECDSA host key for IP address '140.82.113.4' to the list of known hosts.
PTY allocation request failed on channel 0
Hi georgew509! You've successfully authenticated, but GitHub does not provide shell access.
Connection to github.com closed.

Note: You can’t open a shell on GitHub through SSH, but the message confirms that authentication works.

Enable SSH agent forwarding for the ap1 host in your local SSH config:

Host ap1.example.com ap1
  Hostname ap1.example.com
  Port 522
  User george
  IdentityFile ~/.ssh/ap1_ed25519
  ForwardAgent yes

Log in to ap1 and verify forwarding is active by connecting to GitHub from there:

george@imac1:~
$ ssh ap1
Linux ap1 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) x86_64
 o o o
george@ap1:~$ ssh git@github.com
 o o o
PTY allocation request failed on channel 0
Hi georgew509! You've successfully authenticated, but GitHub does not provide shell access.
Connection to github.com closed.

The remote server receives the GitHub authentication request and forwards it to the SSH agent on your local host, so the login succeeds. If you try the same thing from a remote host without forwarding enabled, you get:

git@github.com: Permission denied (publickey).

3. SSH Agent Forwarding Does Not Work for the Root Account

Agent forwarding won’t work for root, because direct SSH access for root is disabled:

george@ap1:~$ sudo -i
[sudo] password for george:
root@ap1:~# ssh git@github.com
 o o o
git@github.com: Permission denied (publickey).

By design, the root account cannot forward SSH requests back to your local agent.

How to Use SSH Tunneling (Port Forwarding)

SSH tunneling, also known as port forwarding, lets you build an encrypted SSH path so you can reach a remote service from your local host. You can also set up a reverse SSH tunnel so the remote server can access a service running on your local machine, even if your local host sits behind a NAT router inside a private network.

1. Create an SSH Tunnel

The example below shows an SSH tunnel that allows a local MariaDB client to talk to a remote MariaDB service. The local client uses port 3307 to avoid clashing with any MariaDB instance on the local system. The remote MariaDB daemon listens on port 3306. A remote user named dbadmin with a password exists on the remote database server.

This SSH command opens the MariaDB tunnel between the local host and the ap1 server:

george@imac1:~
$ ssh -L 3307:127.0.0.1:3306 -N ap1

This creates a non-interactive forward tunnel from local port 3307 to the remote endpoint 127.0.0.1:3306. The tunnel runs in the foreground and prints any errors. If you prefer running it in the background, add the -f option.

In a second local shell, install and start the MariaDB client:

george@imac1:~
$ brew install mariadb

george@imac1:~
$ mariadb --host=127.0.0.1 --port=3307 -u dbadmin -p
Enter password:
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 562
Server version: 10.5.15-MariaDB-0+deb11u1 Debian 11

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]>

As shown, the local macOS MariaDB client is now communicating securely with the remote Debian MariaDB server through the tunnel.

2. Create a Reverse SSH Tunnel

This example demonstrates a reverse SSH tunnel so the remote host can access a service on the local system. The local host runs a Hugo web server on port 1313. On the remote host, the Lynx text browser will reach that service through port 8080.

Note: You can follow the Hugo Quick Start guide to set up a basic “Hello, World” Hugo test site.

This SSH command establishes the reverse tunnel between the local machine and the ap1 server:

george@imac1:~
$ ssh -R 8080:127.0.0.1:1313 -N ap1

This creates a non-interactive reverse tunnel from the ap1 remote host on port 8080 back to the local address 127.0.0.1:1313. The SSH process runs in the foreground and shows any errors. On the remote host you can confirm that sshd is listening on port 8080 using:

george@ap1:~$ sudo netstat -lptn | grep 8080
tcp        0      0 127.0.0.1:8080          0.0.0.0:*               LISTEN      59739/sshd: george  
tcp6       0      0 ::1:8080                :::*                    LISTEN      59739/sshd: george

Start the Hugo web server (or another local service) on the local host:

george@imac1:~/Hugo/apnet
$ hugo server -D
Start building sites …
hugo v0.96.0+extended darwin/amd64 BuildDate=unknown
 o o o
Web Server is available at http://localhost:1313/ (bind address 127.0.0.1)
Press Ctrl+C to stop

The Hugo daemon is now listening on 127.0.0.1:1313.

On the ap1 remote host, install Lynx and open the local Hugo site through the tunnel:

george@ap1:~$ sudo apt install lynx

george@ap1:~$ lynx http://127.0.0.1:8080

This launches a text UI in the remote shell that shows the Hugo content.

If the Hugo service is not running, the local terminal that holds the tunnel prints:

connect_to 127.0.0.1 port 1313: failed.

3. Disabling Tunneling for the Root User

Because SSH access is disabled for root, root also cannot create SSH tunnels:

george@imac1:~
$ ssh -L 3307:127.0.0.1:3306 -N root@ap1
root@ap1.example.com: Permission denied (publickey).

Use scp to Copy Files Between Hosts

Scp securely transfers files between hosts and uses SSH as the transport. If you defined a remote alias in ~/.ssh/config, you can reference remote paths as alias:. Here is the sample local configuration for ap1:

Host ap1.example.com ap1
  Hostname ap1.example.com
  Port 522
  User george
  IdentityFile ~/.ssh/ap1_ed25519
  ForwardAgent yes

This configuration provides two aliases for the same host: a full and a short version.

This scp command copies a local file into the remote home directory of user george, inside ~/backup:

$ scp logo.png ap1:backup
logo.png

george@imac1:~/tmp
$ ssh ap1 "ls backup"
logo.png

This scp command copies the file and changes its name on the destination:

$ scp logo.png ap1:myfile
logo.png 

george@imac1:~/tmp
$ ssh ap1 "ls -lR ~/"
/home/george/:
total 12
drwxr-xr-x 2 george george 4096 Apr 13 20:50 backup
-rw-r--r-- 1 george george 8134 Apr 13 20:58 myfile

/home/george/backup:
total 8
-rw-r--r-- 1 george george 8134 Apr 13 20:55 logo.png

Use scp to copy remote data back to your local host:

george@imac1:~
$ scp ap1:backup/logo.png .
logo.png

Use Rsync to Backup Files and Folders

Rsync can use SSH to move files and directories between machines. It relies on the same alias format defined in your SSH config. Rsync uses SSH whenever the source or destination includes a single colon (:). You can use it to back up a user’s home filesystem, for example:

george@imac1:~/tmp
$ rsync -av --delete ap1:/home/george .
receiving file list ... done
george/
george/.bash_history
george/.bash_logout
george/.bashrc
george/.profile
george/myfile
george/.ssh/
george/.ssh/authorized_keys
george/.ssh/known_hosts
george/backup/
george/backup/logo.png

sent 210 bytes  received 23286 bytes  15664.00 bytes/sec
total size is 22576  speedup is 0.96

The options mean:

• -a: archive mode
• -v: more verbose output
• --delete: remove files from the destination that no longer exist on the source

Another practical option is --exclude=PATTERN, which prevents copying any files or folders matching a given pattern.

Rsync only transfers changes since the last run:

george@imac1:~/tmp
$ rsync -av --delete ap1:/home/george .
receiving file list ... done

sent 16 bytes  received 320 bytes  672.00 bytes/sec
total size is 22576  speedup is 67.19

In this run, remote and local content matched, so rsync did not need to copy anything. For more backup patterns and usage, consult the rsync manual. One important detail is the final folder name in the path: in this example, the george directory and everything inside it are copied. If the last directory ends with a trailing slash (/), rsync copies only the directory’s contents instead of the folder itself.