How to Install OpenSSH on Arch Linux

OpenSSH enables encrypted remote access to Linux systems, replacing unencrypted protocols like Telnet. Whether you manage headless servers, transfer files between machines, or tunnel network connections through secure channels, OpenSSH handles these tasks while encrypting all traffic and supporting key-based authentication. By the end of this guide, you will have a working SSH client and server on Arch Linux with public key authentication configured and security hardening applied.

This guide walks through installing OpenSSH from the official repositories, enabling the SSH daemon with systemd, connecting to remote systems, generating and deploying SSH keys for passwordless login, hardening server configuration against common attacks, and cleanly removing OpenSSH when no longer needed. Each section includes verification commands with expected output so you can confirm your setup works correctly. If you need to configure sudo privileges for SSH users on Arch Linux, complete that first to ensure proper access control.

Install OpenSSH

The openssh package provides both the client and server components. Arch Linux repositories maintain the latest stable OpenSSH release through rolling updates.

Update System First

Synchronize the package database and upgrade existing packages to prevent conflicts:

sudo pacman -Syu

Install the openssh Package

Install OpenSSH using pacman:

sudo pacman -S openssh

This installs all OpenSSH components including the SSH client (ssh), server daemon (sshd), secure file transfer utilities (scp, sftp), and key generation tools.

Verify Installation

Confirm OpenSSH is installed and check the version:

ssh -V

Example output:

OpenSSH_10.x, OpenSSL 3.x.x

Your version numbers will reflect the current Arch Linux packages. Since Arch uses a rolling release model, you always receive the latest stable OpenSSH release without waiting for distribution version upgrades.

Start and Enable the SSH Server

The SSH server runs as a systemd service called sshd.service. Starting the service allows incoming SSH connections, and enabling it ensures the service starts automatically at boot.

Start the SSH Daemon

Start the SSH server immediately:

sudo systemctl start sshd

Enable SSH at Boot

Configure the SSH server to start automatically when the system boots:

sudo systemctl enable sshd

You can combine both operations with the --now flag:

sudo systemctl enable sshd --now

Verify SSH Service Status

Check that the SSH daemon is running:

systemctl status sshd

Expected output showing active status:

● sshd.service - OpenSSH Daemon
     Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; preset: disabled)
     Active: active (running) since [date]; [duration] ago
   Main PID: [pid] (sshd)
      Tasks: 1 (limit: 4605)
     Memory: 1.2M
        CPU: 15ms
     CGroup: /system.slice/sshd.service
             └─[pid] "sshd: /usr/bin/sshd -D [listener] 0 of 10-100 startups"

[date] archlinux systemd[1]: Started OpenSSH Daemon.
[date] archlinux sshd[[pid]]: Server listening on 0.0.0.0 port 22.
[date] archlinux sshd[[pid]]: Server listening on :: port 22.

The output confirms the SSH daemon is listening on port 22 for both IPv4 and IPv6 connections.

Earlier OpenSSH versions (before 8.0p1-3) included sshd.socket for systemd socket activation, but this was removed due to denial-of-service vulnerabilities. Use sshd.service instead, which provides better reliability and restart behavior.

Connect to a Remote System

The SSH client lets you connect to remote systems from your local machine. You need the remote server’s IP address or hostname, a username, and either a password or SSH key.

Basic SSH Connection

Connect to a remote server using username and hostname:

ssh username@server-address

Replace username with your remote account name and server-address with the IP address or domain name. For example:

ssh joshua@192.168.1.100

Connect to Non-Standard Port

If the remote server uses a different port than the default port 22, specify it with the -p flag:

ssh -p 2222 username@server-address

First Connection Host Key Verification

When connecting to a server for the first time, SSH displays the server’s host key fingerprint and asks you to verify it:

The authenticity of host '192.168.1.100 (192.168.1.100)' can't be established.
ED25519 key fingerprint is SHA256:abcd1234efgh5678ijkl9012mnop3456qrst7890uvwx1234yz56.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Type yes to accept and add the host key to your ~/.ssh/known_hosts file. This key verifies the server’s identity for future connections.

Configure SSH Keys for Passwordless Authentication

SSH keys provide more secure authentication than passwords and enable passwordless logins. You generate a key pair on your local machine, then copy the public key to remote servers.

Generate an SSH Key Pair

Create a new ED25519 key pair (recommended for modern systems):

ssh-keygen -t ed25519 -C "your_email@example.com"

The command prompts you for a file location (press Enter to accept the default ~/.ssh/id_ed25519) and an optional passphrase for additional security:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/username/.ssh/id_ed25519): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/username/.ssh/id_ed25519
Your public key has been saved in /home/username/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:abcd1234efgh5678ijkl9012mnop3456qrst7890uvwx1234yz56 your_email@example.com

For systems requiring RSA keys (older SSH servers), use:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

ED25519 keys are shorter, faster, and more secure than RSA keys. Use ED25519 unless you need to connect to legacy systems that do not support it.

Copy Public Key to Remote Server

Use ssh-copy-id to install your public key on the remote server:

ssh-copy-id username@server-address

You will be prompted for the remote user’s password one final time. After successful authentication, the tool appends your public key to the remote ~/.ssh/authorized_keys file.

Expected output:

/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
username@server-address's password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'username@server-address'"
and check to make sure that only the key(s) you wanted were added.

Test Key-Based Authentication

Connect to the remote server without entering a password:

ssh username@server-address

Manage Passphrases with ssh-agent

If you set a passphrase on your SSH key, use ssh-agent to store it for your current terminal session. This prevents repeated prompts while maintaining security. Start the agent and add your private key:

eval $(ssh-agent -s)
ssh-add ~/.ssh/id_ed25519

Once added, you can connect to remote servers immediately without re-entering the passphrase until you close your terminal or kill the agent process.

Transfer Files with SCP and SFTP

OpenSSH includes tools for secure file transfers using the same encryption as your SSH shell session. These examples demonstrate basic syntax for the most common tasks.

Upload and Download Files with SCP

Copy a local file to a remote server:

scp /path/to/local/file.txt username@server-address:/home/username/

Download a file from an SSH server to your local machine:

scp username@server-address:/home/username/remote-file.txt ./

To transfer an entire directory, add the -r (recursive) flag: scp -r ./directory/ username@server-address:~/.

Manage Remote Files with SFTP

Start an interactive file transfer session:

sftp username@server-address

In the SFTP prompt, use commands like ls to list remote files, put to upload, get to download, and exit or bye to disconnect.

Configure SSH Client Settings

The SSH client configuration file lets you define default options and create shortcuts for frequently accessed servers. Configuration applies per-user in ~/.ssh/config.

Create Client Configuration File

Create or edit the SSH client configuration file:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/config

Add a server alias with custom connection settings:

Host myserver
    HostName 192.168.1.100
    Port 22
    User joshua
    IdentityFile ~/.ssh/id_ed25519

With this configuration, the command ssh myserver automatically uses the specified hostname, port, username, and key file.

Add Global Client Options

Define default options that apply to all SSH connections by adding them before any Host sections:

# Global defaults
ServerAliveInterval 60
ServerAliveCountMax 3
AddKeysToAgent yes

# Server-specific settings
Host myserver
    HostName 192.168.1.100
    User joshua

The ServerAliveInterval option sends keepalive packets every 60 seconds to prevent idle disconnections.

Set Configuration File Permissions

SSH requires restrictive permissions on the configuration file:

chmod 600 ~/.ssh/config

Harden SSH Server Security

Default SSH configurations prioritize compatibility over security. Applying hardening measures reduces the attack surface and protects against common threats. Always test configuration changes before disconnecting your current session.

Use Drop-In Configuration Files

Arch Linux’s OpenSSH configuration supports drop-in files in /etc/ssh/sshd_config.d/. This approach keeps custom settings separate from the main configuration file and simplifies updates.

Create a custom security configuration file:

sudo nano /etc/ssh/sshd_config.d/10-security.conf

Disable Root Login

Prevent direct root logins over SSH by requiring users to log in with regular accounts and escalate privileges with sudo:

PermitRootLogin no

This forces attackers to guess both a username and password instead of just the root password.

Disable Password Authentication

Force public key authentication and disable password-based logins to eliminate brute-force password attacks:

PasswordAuthentication no
AuthenticationMethods publickey

Before disabling password authentication, verify that your SSH key is installed in ~/.ssh/authorized_keys on the server and that you can log in successfully using the key. Otherwise, you will lock yourself out of the system.

Restrict User Access

Limit SSH access to specific users or groups. To allow only certain users:

AllowUsers joshua admin

To allow all members of a group:

AllowGroups sshusers

Change Default Port

Moving SSH from the default port 22 to a higher port reduces automated scanning and brute-force attempts. Choose an unused port above 1024:

Port 2222

Check that the chosen port is not already in use:

sudo ss -tuln | grep 2222

If the command returns no output, the port is free.

Changing the SSH port reduces log noise from automated attacks but does not replace proper authentication security. Always use SSH keys and disable password authentication regardless of which port you choose.

Add a Login Banner

Display a warning message before users authenticate. Create a banner file:

sudo nano /etc/issue.ssh

Add your warning text:

Unauthorized access is prohibited.
All connections are monitored and logged.

Reference the banner file in your SSH configuration:

Banner /etc/issue.ssh

Install Fail2Ban for Intrusion Prevention

Hardening the service is the first step, but proactive defense protects against high-volume brute-force attacks. Fail2Ban monitors your SSH logs and automatically bans abusive IP addresses using your firewall:

sudo pacman -S fail2ban

Create a local configuration file to enable the SSH jail:

sudo nano /etc/fail2ban/jail.local

Add the following configuration to enable checking for SSH attacks:

[sshd]
enabled = true

Start and enable the Fail2Ban service:

sudo systemctl enable fail2ban --now

Test Configuration Changes

Always test the SSH configuration for syntax errors before restarting the service:

sudo sshd -t

If the configuration is valid, the command produces no output. If there are errors, it displays the problem location:

/etc/ssh/sshd_config.d/10-security.conf line 5: Bad configuration option: InvalidOption

Apply Configuration Changes

After confirming the configuration is valid, restart the SSH service:

sudo systemctl restart sshd

Verify the service restarted successfully:

systemctl status sshd

Keep your current SSH session open when testing configuration changes. Open a second terminal window and attempt a new SSH connection to verify the settings work as expected. Only close your original session after confirming you can reconnect successfully.

Configure Firewall for SSH

Arch Linux does not enable a firewall by default, but if you use iptables, nftables, or a firewall manager like ufw, you must allow SSH traffic before remote connections will work.

Allow SSH with iptables

For systems using iptables directly:

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables-save | sudo tee /etc/iptables/iptables.rules
sudo systemctl enable iptables

If you changed SSH to a custom port, replace 22 with your configured port number.

Allow SSH with nftables

For systems using nftables:

sudo nft add rule inet filter input tcp dport 22 accept

Save the ruleset to persist across reboots:

sudo nft list ruleset | sudo tee /etc/nftables.conf
sudo systemctl enable nftables

Allow SSH with UFW

If you installed ufw (available in the Arch repositories), allow SSH before enabling the firewall:

sudo ufw allow ssh
sudo ufw enable

Always allow SSH access before enabling a firewall on a remote server. Blocking port 22 (or your custom SSH port) while connected remotely will lock you out of the system.

View SSH Logs

SSH logs help troubleshoot connection issues and monitor authentication attempts. Arch Linux uses systemd’s journal for all service logs.

View Recent SSH Activity

Display the most recent SSH daemon log entries:

sudo journalctl -xeu sshd

The -x flag adds explanatory messages from the systemd catalog, and -e jumps to the end of the log.

Follow SSH Logs in Real-Time

Monitor SSH connections as they occur:

sudo journalctl -fu sshd

This displays new log entries as they are written. Press Ctrl+C to stop following.

Search for Failed Login Attempts

Filter logs to show only failed authentication attempts:

sudo journalctl -u sshd | grep "Failed password"

This reveals brute-force attack patterns and helps identify compromised user accounts.

Remove OpenSSH

When you no longer need SSH access, remove OpenSSH to eliminate the attack surface. Stopping and disabling the service before removal prevents connection attempts during uninstallation.

Stop and Disable the SSH Service

Stop the running SSH daemon and prevent it from starting at boot:

sudo systemctl stop sshd
sudo systemctl disable sshd

Remove the openssh Package

Uninstall OpenSSH and remove orphaned dependencies:

sudo pacman -Rns openssh

The -Rns flags perform a complete removal: -R removes the package, -n (nosave) deletes configuration files instead of creating .pacsave backups, and -s (recursive) removes dependencies that are no longer required by other packages.

Remove SSH Configuration Files

The pacman removal deletes most configuration files, but host keys and custom configurations in /etc/ssh may remain. To completely remove all SSH server configuration:

The following command permanently deletes the SSH server configuration directory, including host keys and any custom sshd_config settings. If you plan to reinstall OpenSSH later and want to preserve the same host keys, back up /etc/ssh first with sudo cp -r /etc/ssh ~/ssh-backup.

sudo rm -rf /etc/ssh

User SSH keys stored in ~/.ssh directories are not removed by package uninstallation or the command above. These keys may still be valid for authenticating to other servers. If you want to delete SSH keys for security reasons, manually remove each user’s ~/.ssh directory with rm -rf ~/.ssh. This permanently deletes private keys, public keys, client configuration, and known host fingerprints.

Verify Removal

Confirm OpenSSH is no longer installed:

pacman -Qi openssh

Expected output:

error: package 'openssh' was not found

Troubleshooting Common Issues

These are the most frequently encountered problems when configuring OpenSSH on Arch Linux.

Connection Refused Error

If SSH connections fail with “Connection refused,” the SSH daemon is not running or not listening on the expected port.

Check the service status:

systemctl status sshd

If inactive, start the service:

sudo systemctl start sshd

Verify which port SSH is listening on:

sudo ss -tuln | grep :22

Expected output showing SSH listening on port 22 for both IPv4 and IPv6:

tcp   LISTEN 0      128          0.0.0.0:22        0.0.0.0:*
tcp   LISTEN 0      128             [::]:22           [::]:*

If you changed SSH to a non-standard port, replace :22 with your configured port number (for example, grep :2222).

Permission Denied (Publickey)

The error “Permission denied (publickey)” means the server rejected your SSH key. This typically happens when the key is missing from the server, the key permissions are wrong, or the client is offering a different key than expected.

First, debug from the client side by adding verbose output to see which keys your client is offering:

ssh -vvv username@server-address 2>&1 | grep -E "Offering|Trying"

This shows which key files your client is sending. Verify the key file matches what you installed on the server.

If you still have password access or console access to the server, check the authorized_keys file and permissions directly on the server:

cat ~/.ssh/authorized_keys
ls -la ~/.ssh

Required permissions for SSH to accept keys:

drwx------ 2 username username 4096 [date] .ssh
-rw------- 1 username username  [size] [date] authorized_keys

Fix incorrect permissions:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

If you disabled password authentication and lost key access, you need physical console access, a rescue boot environment, or cloud provider console (if applicable) to regain access. This is why the hardening section recommends testing key authentication before disabling passwords.

Host Key Verification Failed

When a server’s host key changes, SSH displays a warning and refuses to connect:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

This occurs when you reinstall the server’s operating system, regenerate host keys, or if someone is intercepting the connection (man-in-the-middle attack).

If you know the host key changed legitimately (such as after reinstalling the server), remove the old key:

ssh-keygen -R server-address

Then reconnect and accept the new host key.

SSH Service Fails to Start

If the SSH daemon fails to start, check for configuration syntax errors:

sudo sshd -t

View detailed error messages from the systemd journal:

sudo journalctl -xeu sshd

Common issues include invalid directives, missing host keys, or port conflicts with other services.

Additional Resources

For comprehensive OpenSSH documentation specific to Arch Linux, consult the Arch Wiki OpenSSH page. The Arch Wiki covers advanced topics including X11 forwarding, SOCKS tunneling, SSH multiplexing, and automated hardening with tools like ssh-audit.

Additional security hardening guidance is available from the Mozilla Infosec Team OpenSSH guidelines and SSH Hardening Guides at ssh-audit.com.

You can also consult the manual pages for detailed command options and configuration parameters:

man ssh
man sshd
man sshd_config
man ssh-keygen
man ssh-copy-id

Conclusion

You now have a functional SSH setup on Arch Linux. Installing OpenSSH with sudo pacman -S openssh, enabling the service with sudo systemctl enable sshd --now, and generating SSH keys with ssh-keygen -t ed25519 form the foundation for secure remote administration. Hardening the server configuration by disabling password authentication, restricting root login, and using SSH keys protects against common attack vectors. Always test configuration changes with sudo sshd -t before restarting the service, and keep your SSH keys backed up securely.