OpenSSH provides secure, encrypted remote access to Linux servers, replacing insecure protocols like Telnet with strong authentication and encrypted data transmission. When you install OpenSSH on Fedora, you gain the ability to administer remote servers, transfer files securely using SCP or SFTP, and create encrypted tunnels for applications like Docker or database connections. By the end of this guide, you will have a production-ready SSH server with firewall integration, key-based authentication, and hardened security settings.
This guide covers the complete OpenSSH installation process on Fedora, from package installation through service configuration, firewall setup, and security hardening. You will also learn essential SSH commands for connecting to remote systems and troubleshooting common connection issues.
Update Fedora Packages Before SSH Installation
Updating your Fedora system packages before installing SSH is crucial to maintaining system compatibility and preventing conflicts. As a result, this ensures that all your system components are up to date.
Run the following command in the terminal to update your packages:
sudo dnf upgradeThis command upgrades all packages to their latest versions, ensuring your system is current.
Install OpenSSH Server on Fedora
Before installing, first check whether your Fedora system already has the OpenSSH server installed. To do this, use the following command to search for the OpenSSH server package:
rpm -qa | grep openssh-serverIf this command returns output similar to the example below, your system already has the OpenSSH server installed:
openssh-server-10.0p1-5.fc43.x86_64
However, if you see no output, proceed to install it using the command below.
Use this command to install the OpenSSH server:
sudo dnf install openssh-serverAfter installation completes, verify the installed version:
ssh -VThe output displays your OpenSSH version:
OpenSSH_10.0p1, OpenSSL 3.2.2 4 Jun 2024
Enable and Start the SSH Service
Once the OpenSSH server is installed, the next step is to enable the SSHD service so the SSH daemon starts automatically with each system boot. In turn, this ensures consistent remote access whenever your server restarts.
To begin, enable SSHD using this command:
sudo systemctl enable sshd.serviceUpon success, the system displays output confirming the service enables at boot:
Created symlink /etc/systemd/system/multi-user.target.wants/sshd.service → /usr/lib/systemd/system/sshd.service.
After enabling the service, you can then start the SSH server with:
sudo systemctl start sshd.serviceFinally, to verify that the SSH server is running correctly, check its status:
systemctl status sshd.serviceThe output should indicate the service is active and running:
● sshd.service - OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; preset: disabled)
Active: active (running) since Wed 2025-11-27 10:30:00 UTC; 5min ago
Docs: man:sshd(8)
man:sshd_config(5)
Main PID: 1234 (sshd)
Tasks: 1 (limit: 4915)
Memory: 2.1M
CPU: 45ms
CGroup: /system.slice/sshd.service
└─1234 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"
Using SSH to Connect to a Remote System
Once your SSH server is running and accessible, you can connect from client systems using various authentication methods. The examples below demonstrate common connection scenarios including password authentication, key-based login, and custom port connections.
Connect with Password Authentication
After setting up SSH, you can initiate a connection to a remote server. For a password-based authentication, use the following syntax:
ssh username@remote_serverHere, replace username with your actual username and remote_server with the server’s IP address or hostname. Upon executing this command, the system prompts you to enter your password for authentication.
On first connection, SSH asks you to verify the server’s fingerprint:
The authenticity of host 'remote_server (192.168.1.100)' can't be established. ED25519 key fingerprint is SHA256:abc123def456ghi789jkl012mno345pqr678stu901vwx234yz. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Type yes to accept the fingerprint and SSH adds the server to your known hosts file before prompting you for your password.
Connect with Public Key Authentication
For enhanced security, SSH also supports public key authentication. Moreover, this method provides better security than password authentication because it uses cryptographic keys. Execute the command:
ssh -i /path/to/private_key username@remote_serverHere, replace /path/to/private_key with the path to your private key file, username with your username, and remote_server with the server’s IP address or hostname. This method bypasses the need for password entry, leveraging the private key for authentication.
Connect to Custom SSH Port
By default, SSH uses port 22 for connections. However, if the remote server listens on a different port, specify it using the -p option:
ssh -p 2222 username@remote_serverChange 2222 to the actual port number used by the remote server.
Transfer Files with SCP and SFTP
SCP (Secure Copy Protocol) provides a secure method for transferring files between systems via SSH. To copy a file from your local system to a remote server, use this command:
scp /path/to/local/file username@remote_server:/path/to/remote/directoryAdapt /path/to/local/file to the local file’s path, username to your username, remote_server to the server’s IP or hostname, and /path/to/remote/directory to the target directory on the remote server. This command securely copies the file to the specified directory on the remote server.
Although SCP remains widely used, SFTP (SSH File Transfer Protocol) is recommended for new workflows due to better error handling and more reliable transfer resumption. Use
sftp username@remote_serverfor interactive file transfers or tools like FileZilla that support SFTP protocol.
Configure SSH Settings on Fedora
For configuration changes, Fedora recommends using drop-in configuration files in the /etc/ssh/sshd_config.d/ directory rather than editing the main configuration file directly. This approach prevents conflicts during package updates and makes it easier to manage custom settings.
Before making configuration changes, consider backing up your current SSH configuration with
sudo cp -r /etc/ssh /etc/ssh.backupso you can restore settings if needed.
After making any configuration changes, always test the configuration syntax before restarting the service:
sudo sshd -tIf the configuration is valid, the command produces no output. However, the system displays any syntax errors. Once validated, restart the SSH service to apply changes:
sudo systemctl restart sshd.serviceDisable GSSAPI Authentication
Consider disabling GSSAPI authentication for enhanced performance, as it can slow down SSH connection times. Create a drop-in configuration file:
sudo nano /etc/ssh/sshd_config.d/01-disable-gssapi.confAdd the following line:
GSSAPIAuthentication noThis modification prevents GSSAPI authentication, which can reduce delays during SSH connection setup. After saving the file, test and restart the SSH service:
sudo sshd -t && sudo systemctl restart sshd.serviceAdjust SSH Session Timeouts
To manage SSH session timeouts, create a drop-in configuration file:
sudo nano /etc/ssh/sshd_config.d/02-session-timeout.confAdd these lines:
ClientAliveInterval 300
ClientAliveCountMax 2Essentially, this configuration sends a keep-alive message every 300 seconds (5 minutes) and terminates the session after two failed responses, helping maintain active sessions while closing inactive ones. Afterward, test and restart the service:
sudo sshd -t && sudo systemctl restart sshd.serviceDisable Root Login
Disabling root login is a critical security practice to defend against brute-force attacks. Before disabling root login, ensure you have a non-root user with sudo privileges. If you need to create one, see our guide on how to add a user to sudoers on Fedora. Create a drop-in configuration file:
sudo nano /etc/ssh/sshd_config.d/03-disable-root-login.confInclude this line:
PermitRootLogin noAs a result, this setting disables remote root login, significantly enhancing your system’s security. Next, test and restart the service:
sudo sshd -t && sudo systemctl restart sshd.serviceUse Public Key Authentication
Public key authentication offers a more secure alternative to password-based methods. To begin, first generate an SSH key pair. Modern systems support Ed25519 keys, which provide better security and performance than RSA:
ssh-keygen -t ed25519If you need compatibility with older systems that do not support Ed25519, use RSA with 4096-bit key length:
ssh-keygen -t rsa -b 4096Then, transfer your public key to the remote server:
ssh-copy-id user@remote_serverReplace user with your username and remote_server with the server’s IP or hostname. After copying the key, you can then enable public key authentication and disable password authentication for maximum security. To proceed, create a drop-in configuration file:
sudo nano /etc/ssh/sshd_config.d/04-key-auth.confAdd these lines:
PubkeyAuthentication yes
PasswordAuthentication noTest the configuration and restart the SSH service to apply changes. Ensure you can log in with your key before closing your current session.
Restrict SSH Access to Specific Users or Groups
To limit SSH access to certain users or groups, create a drop-in configuration file:
sudo nano /etc/ssh/sshd_config.d/05-restrict-users.confAdd these lines:
AllowUsers user1 user2
AllowGroups group1 group2Replace user1 user2 with the allowed usernames and group1 group2 with the allowed group names. Importantly, this restriction enhances security by limiting SSH access to only the specified accounts. Then, test and restart the service:
sudo sshd -t && sudo systemctl restart sshd.serviceChange the Default SSH Port
Changing the default SSH port (22) can reduce unauthorized access attempts. Create a drop-in configuration file:
sudo nano /etc/ssh/sshd_config.d/06-change-port.confAdd this line:
Port 2222Replace 2222 with your chosen port, ideally between 1024 and 65535, ensuring another service does not use it. Equally important, after changing the port, update your firewall rules to allow the new port and remove the old one:
sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --reloadThis step adds an extra layer of security by obscuring the SSH port from automated attacks.
Create SSH Client Configuration File
Simplify connections to frequently accessed servers by creating an SSH client configuration file. This file stores connection details so you can connect using short aliases instead of typing full connection strings each time.
Create or edit the SSH config file:
nano ~/.ssh/configAdd host entries for your servers:
Host webserver
HostName 192.168.1.100
User admin
Port 22
IdentityFile ~/.ssh/id_ed25519
Host devbox
HostName dev.example.com
User developer
Port 2222
IdentityFile ~/.ssh/dev_keyOnce you save the file, you can connect using just the alias:
ssh webserverThis approach eliminates the need to remember IP addresses, usernames, ports, and key locations for each server. In addition, set appropriate permissions on the config file:
chmod 600 ~/.ssh/configConfigure Firewalld for SSH Access
Firewalld serves as the default firewall management tool on Fedora. If you have not yet configured Firewalld, refer to our guide on how to install Firewalld on Fedora before proceeding with these SSH-specific rules.
Allow Your IP Address in Firewalld
Maintaining uninterrupted access is critical in a Fedora-based VPS or remote server environment. For this reason, allowing your IP address before adjusting Firewalld settings is essential, especially for remote system connections. Otherwise, overlooking this step could result in losing server access after applying firewall changes.
First, verify your current firewall zone:
sudo firewall-cmd --get-default-zoneThe output will typically show:
public
To allow your specific IP address in Firewalld, run the following command:
sudo firewall-cmd --permanent --add-source=Replace <your_ip_address> with your actual IP address. This step is crucial to maintain your access uninterrupted.
Add SSH Service to Firewalld
Once you have safely allowed your IP address, add the SSH service to Firewalld to permit incoming SSH connections:
sudo firewall-cmd --add-service=ssh --permanentThis command adds SSH to the list of services that Firewalld allows through the firewall.
Reload Firewalld to Apply Changes
After making the necessary changes, apply them by reloading Firewalld:
sudo firewall-cmd --reloadAs a result, reloading Firewalld activates the new settings without interrupting the current network connectivity.
Verify SSH Access Through Firewall
To ensure that SSH is correctly configured and allowed in Firewalld, execute:
sudo firewall-cmd --list-servicesYou should see ssh in the output:
cockpit dhcpv6-client ssh
This confirms that the firewall allows SSH through and your remote SSH sessions remain secure and accessible.
Troubleshoot Common SSH Problems
Fix Connection Refused Errors
If you receive a “Connection refused” error when trying to connect, either the SSH service may not be running or the firewall blocks access. To diagnose this, first check the SSH service status:
systemctl status sshd.serviceIf the service is inactive, you will see:
● sshd.service - OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
Active: inactive (dead)
Start the service:
sudo systemctl start sshd.serviceIf the service is running, verify which port SSH is listening on:
sudo ss -tlnp | grep sshdYou should see output showing the listening port:
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1234,fd=3))
If the service is listening, check firewall rules:
sudo firewall-cmd --list-servicesIf ssh is not in the list, add it using the firewall configuration steps earlier in this guide.
Fix Permission Denied (Publickey) Errors
This error typically occurs when public key authentication fails. To resolve it, first verify that your public key exists on the remote server:
ssh user@remote_server "cat ~/.ssh/authorized_keys"Then, check that your local key matches an entry in the authorized_keys file. If not, copy your key again:
ssh-copy-id user@remote_serverVerify file permissions on the remote server. The .ssh directory must be 700 and authorized_keys must be 600:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keysResolve Host Key Verification Failures
When a server’s host key changes, SSH prevents connection for security reasons. In this case, you will see this error:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Before removing the old key, first verify with the server administrator that the host key change is legitimate. Once confirmed, you can safely remove the old key:
ssh-keygen -R remote_serverAfterward, reconnect to accept the new host key.
Fix SELinux SSH Connection Denials
If SSH connections fail on Fedora with SELinux enforcing, check for denials. For more information about managing SELinux on Fedora, see our guide on how to disable SELinux on Fedora. To check for SSH-related denials, run:
sudo ausearch -m avc -ts recent | grep sshdIf you changed the SSH port, you must update the SELinux policy:
sudo semanage port -a -t ssh_port_t -p tcp 2222Replace 2222 with your custom port. Next, verify the port is added:
sudo semanage port -l | grep sshYou should see output showing both the default and custom ports:
ssh_port_t tcp 2222, 22
This confirms SELinux will allow SSH connections on your custom port.
Identify Configuration Syntax Errors
After making configuration changes, always test before restarting the service:
sudo sshd -tIf there are errors, you will see output like:
/etc/ssh/sshd_config.d/01-disable-gssapi.conf line 2: Bad configuration option: GSSAPIAuthenticationn /etc/ssh/sshd_config.d/01-disable-gssapi.conf: terminating, 1 bad configuration options
Fix the syntax error (in this example, a typo in the option name) and test again. Notably, a successful test produces no output.
Quick Reference: Essential SSH Commands
Here are the most frequently used SSH commands for quick reference:
| Task | Command |
|---|---|
| Check SSH service status | systemctl status sshd.service |
| Start SSH service | sudo systemctl start sshd.service |
| Stop SSH service | sudo systemctl stop sshd.service |
| Restart SSH service | sudo systemctl restart sshd.service |
| Test SSH configuration | sudo sshd -t |
| Connect to remote server | ssh username@remote_server |
| Connect with specific key | ssh -i /path/to/key username@remote_server |
| Connect on custom port | ssh -p 2222 username@remote_server |
| Copy file to remote server | scp file.txt username@remote_server:~/ |
| Generate SSH key | ssh-keygen -t ed25519 |
| Copy public key to server | ssh-copy-id username@remote_server |
| Check listening ports | sudo ss -tlnp | grep sshd |
| View firewall services | sudo firewall-cmd --list-services |
| Check SELinux SSH ports | sudo semanage port -l | grep ssh |
Conclusion
Your Fedora system now runs a hardened SSH server with key-based authentication, drop-in configuration files, and Firewalld integration. The SSH client configuration file simplifies connections to multiple servers, while SELinux policies protect custom port configurations. To strengthen your security further, implement Fail2ban with Firewalld to automatically block brute-force login attempts.