Install OpenSSH on Arch Linux when the system needs encrypted remote shell access, SCP/SFTP file transfers, Git over SSH, or secure tunnels from another machine. Arch packages the client and server together as openssh; there is no separate openssh-server package, and the normal server unit is sshd.service.
The practical workflow is package installation, daemon enablement, listener verification, key-based authentication, and targeted hardening before you rely on SSH for remote administration.
Install OpenSSH on Arch Linux
The official Arch openssh package provides ssh, sshd, scp, sftp, ssh-keygen, ssh-copy-id, and related tools from the core repository. Do not assume it is present on every minimal Arch installation.
Update System First
Synchronize the package database and upgrade existing packages to prevent conflicts:
sudo pacman -SyuThese commands use
sudofor tasks that need root privileges. If your user is not in the sudoers file yet, run the commands as root or follow the guide on how to add and manage sudo users on Arch Linux.
Install the openssh Package
Install the package with pacman:
sudo pacman -S opensshIf a command from another distribution mentions openssh-server, translate that intent to openssh on Arch. The same package provides the SSH client and server components.
Verify Installation
Confirm the installed package and the client/server binary ownership:
pacman -Q openssh
pacman -Qo /usr/bin/ssh /usr/bin/sshdRelevant output includes:
openssh 10.3p1-1 /usr/bin/ssh is owned by openssh 10.3p1-1 /usr/bin/sshd is owned by openssh 10.3p1-1
Check the OpenSSH client version separately. Arch is rolling release, so the exact version changes with normal system updates:
ssh -VOpenSSH_10.3p1, OpenSSL 3.6.2 7 Apr 2026
Start and Enable sshd.service
The SSH server listens through the systemd unit sshd.service. Use sshd.service on Arch Linux; commands such as systemctl enable ssh.service come from other distributions and fail on Arch.
Enable and Start the SSH Daemon
Start the daemon now and enable it at boot:
sudo systemctl enable --now sshd.serviceVerify SSH Service Status
Use concise systemd checks for active and boot-enabled state:
systemctl is-active sshd.service
systemctl is-enabled sshd.serviceactive enabled
Verify the SSH Listener
Confirm the daemon is listening on TCP port 22:
ss -tln 'sport = :22'Relevant output includes listeners for IPv4, IPv6, or both depending on the system configuration:
State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 128 0.0.0.0:22 0.0.0.0:* LISTEN 0 128 [::]:22 [::]:*
Normal remote SSH access on current Arch Linux uses
sshd.service. If you see instructions forssh.serviceorsshd.socket, verify they apply to Arch before copying them.
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-addressReplace username with your remote account name and server-address with the IP address or domain name. For example:
ssh joshua@192.168.1.100Connect 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-addressFor more client-side examples, including identity files, remote commands, and port forwarding, use the related SSH command guide for Linux.
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-addressYou 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.
Relevant output includes:
/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-addressManage 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_ed25519Once 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-addressIn 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/configAdd a server alias with custom connection settings:
Host myserver
HostName 192.168.1.100
Port 22
User joshua
IdentityFile ~/.ssh/id_ed25519With 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 joshuaThe 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/configHarden SSH Server Security
Default OpenSSH settings prioritize compatibility. Harden the server in small changes, keep your current session open, and test a new login before closing the session that still works.
Use Drop-In Configuration Files
Arch Linux’s OpenSSH package includes /etc/ssh/sshd_config.d/. Put local server changes in a drop-in file so package updates can keep managing the main /etc/ssh/sshd_config file.
Create a custom security configuration file:
sudo nano /etc/ssh/sshd_config.d/10-security.confDisable Root and Password Logins
After key-based login works, these settings block direct root login and password-style authentication:
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yesPasswordAuthentication no disables normal password login, while KbdInteractiveAuthentication no closes keyboard-interactive prompts that can otherwise behave like password prompts on some configurations.
Before disabling password authentication, verify that your public key is installed in
~/.ssh/authorized_keyson the server and that a second terminal can log in with the key. Otherwise, you can lock yourself out.
Restrict User Access
Limit SSH access to specific users or groups only after confirming those accounts exist. If you omit your own account, the next login attempt can fail even when the key is correct:
getent passwd your-user
getent group sshusersUse one allowlist pattern in the drop-in file, replacing the examples with real local accounts or groups. For a user allowlist:
AllowUsers your-user another-userFor a group allowlist:
AllowGroups sshusersChange Default Port
A custom port can reduce log noise from automated scanners, but it does not replace key-based authentication. Check that the replacement port is unused before changing sshd_config:
ss -tln 'sport = :2222'If the command returns no output, the port is free.
Port 2222Open the new port in your firewall before restarting
sshd.service. Keep port 22 available until you have confirmed a fresh login on the new port.
Add a Login Banner
Display a warning message before authentication by creating a banner file:
sudo nano /etc/issue.sshAdd your warning text:
Unauthorized access is prohibited.
All connections are monitored and logged.Reference the banner file in your SSH configuration:
Banner /etc/issue.sshAdd Fail2Ban When SSH Is Internet-Facing
For public SSH servers, add rate limiting or ban automation after the service is working. Use the dedicated Fail2Ban on Arch Linux guide for the full package install, jail configuration, backend checks, and service-verification workflow.
Test Configuration Changes
Always test the SSH configuration for syntax errors before restarting the service:
sudo sshd -tIf 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.serviceVerify the service restarted successfully:
systemctl is-active sshd.serviceactive
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. If you already use a firewall or plan to enable one, allow the SSH port before applying a deny-by-default policy or changing the SSH port.
Allow SSH with UFW
UFW users can allow the default SSH port with a TCP-specific rule. See the full UFW on Arch Linux guide before enabling UFW on a remote server.
sudo ufw allow 22/tcpFor a custom SSH port, replace 22/tcp with the configured port, such as 2222/tcp.
Allow SSH with Firewalld
Firewalld users can open the built-in SSH service and reload the runtime policy. Use the Firewalld on Arch Linux guide if Firewalld is not installed or enabled yet.
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reloadAllow SSH with nftables or iptables
Direct nftables or iptables rules depend on the table, chain, default policy, and persistence service you already use. Add a TCP allow rule for the active SSH port to your existing ruleset rather than pasting a standalone rule into an unknown firewall layout.
ss -tln 'sport = :22'After applying firewall changes, test a fresh SSH login from another terminal before closing the working session.
Always allow SSH access before enabling or reloading a firewall on a remote server. Blocking port 22 or your custom SSH port can leave the system reachable only through local console, rescue access, or a provider control panel.
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.serviceThe -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.serviceNew log entries appear as they are written. Press Ctrl+C to stop following.
Search for Failed Login Attempts
Filter logs for failed authentication attempts and invalid usernames:
sudo journalctl -u sshd.service | grep -E "Failed|Invalid user"Password-disabled servers may still log invalid users, refused keys, or other pre-authentication failures, so filter for more than Failed password when reviewing attacks.
Update OpenSSH
OpenSSH updates through normal Arch system upgrades. Keep the system current, then confirm the installed package version:
sudo pacman -Syu
pacman -Q opensshIf openssh was upgraded while sshd.service was running, restart the daemon during a safe maintenance window and verify it returns to active state:
sudo systemctl restart sshd.service
systemctl is-active sshd.serviceactive
On remote-only systems, keep an existing SSH session open before restarting the daemon. Open a second terminal and confirm a new login succeeds before closing the original session.
Remove OpenSSH
Remove OpenSSH only when you no longer need inbound or outbound SSH tools on the machine. If you are connected through SSH, use a local console, hypervisor console, rescue console, or another verified access path before stopping the service.
Stopping or removing
sshd.servicecan immediately end remote administration access. Confirm you have a recovery path before continuing.
Preview recursive dependency removal first. Pacman’s preview mode should use -Rs --print; the final cleanup can use -Rns when you want package-owned configuration files removed instead of saved as .pacsave files:
sudo pacman -Rs openssh --printStop the SSH Service
Stop the daemon and prevent it from starting at boot:
sudo systemctl disable --now sshd.serviceRemove the openssh Package
Remove OpenSSH and orphaned dependencies after reviewing the preview:
sudo pacman -Rns opensshThe -Rns flags remove the package, remove unneeded dependencies, and delete package-owned configuration files rather than keeping .pacsave backups.
Remove SSH Configuration Files
OpenSSH host keys and local drop-ins under /etc/ssh control the server identity. If you plan to reinstall OpenSSH and want clients to trust the same host key, back up that directory before deleting anything:
sudo cp -a /etc/ssh "$HOME/ssh-backup"Delete the server configuration only when you are certain those host keys and local settings are no longer needed:
The next command permanently deletes server host keys and local SSH configuration. Do not run it if another package, administrator, or future reinstall needs the existing
/etc/sshidentity.
sudo rm -rf /etc/sshUser key material under ~/.ssh is separate from package removal. Private keys, authorized_keys, client shortcuts, and known-host entries may still be needed for other systems, so remove user SSH directories only after reviewing each account.
Verify Removal
Confirm OpenSSH is no longer installed:
pacman -Q opensshPacman reports that the package is absent:
error: package 'openssh' was not found
Troubleshooting Common Issues
These are the most frequently encountered problems when configuring OpenSSH on Arch Linux.
ssh.service Unit Not Found
Arch uses sshd.service for the OpenSSH server. If you copy commands from Debian, Ubuntu, or generic Linux examples, you may see this error:
Failed to enable unit: Unit ssh.service does not exist
Use the Arch service name instead:
sudo systemctl enable --now sshd.service
systemctl is-active sshd.serviceactive
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 is-active sshd.serviceIf inactive, start the service:
sudo systemctl start sshd.serviceVerify which port SSH is listening on:
ss -tln 'sport = :22'Relevant output showing SSH listening on port 22 for both IPv4 and IPv6:
State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 128 0.0.0.0:22 0.0.0.0:* LISTEN 0 128 [::]:22 [::]:*
If you changed SSH to a non-standard port, replace :22 with your configured port number, such as :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 key file and permissions directly on the server:
ls -ld ~/.ssh ~/.ssh/authorized_keys
ssh-keygen -lf ~/.ssh/authorized_keysRequired 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_keysIf 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-addressThen 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 -tIf the error says no host keys are available, regenerate the host keys and test the configuration again:
sshd: no hostkeys available -- exiting.
sudo ssh-keygen -A
sudo sshd -tView detailed service errors from the systemd journal:
sudo journalctl -xeu sshd.serviceCommon issues include invalid directives, missing host keys, or port conflicts with other services.
Additional Resources
For Arch-specific OpenSSH behavior, consult the Arch Wiki OpenSSH page. It covers advanced topics such as X11 forwarding, SOCKS tunneling, multiplexing, host-key behavior, and server configuration examples.
Upstream OpenSSH references are available from the OpenSSH manual page collection and the sshd_config manual.
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-idConclusion
OpenSSH is now installed on Arch Linux through the official openssh package, with sshd.service handling inbound logins and SSH keys ready for safer authentication. Keep the daemon verified after configuration changes with sudo sshd -t, protect remote access with a tested firewall rule, and use related guides to install Fail2Ban on Arch Linux or configure UFW on Arch Linux when the server is exposed to untrusted networks.
Formatting tips for your comment
You can use basic HTML to format your comment. Useful tags currently allowed in published comments:
<code>command</code>command<strong>bold</strong><em>italic</em><blockquote>quote</blockquote>