How to Install OpenSSH on Fedora Linux

Last updated Saturday, March 14, 2026 3:11 pm 11 min read

Remote administration on Fedora gets much easier once SSH is ready before you need emergency console access. To install SSH on Fedora, you only need the OpenSSH server package, the sshd.service unit, and a quick check that firewalld plus SELinux still match your port choices.

Fedora Workstation usually already includes the client tools from openssh-clients, while inbound SSH depends on openssh-server. The steps below cover package checks, installation, enablement, firewalld, key-based authentication, custom ports, troubleshooting, and clean removal.

Install SSH on Fedora

Update Fedora and Check the OpenSSH Packages

Start with a normal package refresh so Fedora pulls the latest metadata and security fixes before you touch the SSH stack.

sudo dnf upgrade --refresh

These commands use sudo for system changes. If your account does not have sudo access yet, follow the guide to add a user to sudoers on Fedora first.

Fedora splits the SSH packages by role, so check what is already installed before you add anything. The client commands come from openssh-clients, while inbound SSH uses openssh-server.

rpm -q openssh-clients openssh-server

If both packages are present, RPM prints each installed build:

openssh-clients-10.0p1-6.fc43.x86_64
openssh-server-10.0p1-6.fc43.x86_64

When openssh-server is missing, RPM instead prints package openssh-server is not installed. That tells you the client tools may already exist, but Fedora is not ready to accept inbound SSH connections yet.

Install and Enable the OpenSSH Server

Install openssh-server if it is missing, then enable the daemon immediately so it survives reboots.

Install OpenSSH Server on Fedora with sudo dnf install openssh-server, then enable SSH on Fedora with sudo systemctl enable --now sshd.service.

sudo dnf install openssh-server
sudo systemctl enable --now sshd.service

Fedora uses sshd.service for the SSH daemon. There is no parallel ssh.service unit, so use the full Fedora unit name in every service command.

Check the daemon state right away so you know the service started cleanly.

systemctl status sshd.service --no-pager

A healthy service looks like this on Fedora 43:

● sshd.service - OpenSSH server daemon
     Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Sat 2026-03-14 14:56:19 AWST; 1min 28s ago
 Invocation: 3df38c8d6ba645f0849da452845cfb7a
       Docs: man:sshd(8)
             man:sshd_config(5)
   Main PID: 858 (sshd)
      Tasks: 1 (limit: 4569)
     Memory: 13.8M (peak: 19.4M)
        CPU: 538ms

Verify the SSH Client Tools and Listener

Fedora keeps the client-side commands in openssh-clients, so verify both the command version and the listening socket after installation.

ssh -V

The client reports its upstream OpenSSH version string:

OpenSSH_10.0p2, OpenSSL 3.5.4 30 Sep 2025

That version string can differ slightly from the RPM revision you saw earlier, which is normal on Fedora. The package metadata tracks Fedora’s build revision, while ssh -V prints the bundled OpenSSH release and OpenSSL library version.

Confirm that sshd is actually listening on port 22 before you move on to firewall rules or key-based logins.

sudo ss -tlnp | grep sshd

You should see the daemon bound to both IPv4 and IPv6 on port 22:

LISTEN 0      128          0.0.0.0:22        0.0.0.0:*    users:(("sshd",pid=858,fd=6))
LISTEN 0      128             [::]:22           [::]:*    users:(("sshd",pid=858,fd=7))

Configure Firewalld for SSH on Fedora

Fedora Workstation often uses the FedoraWorkstation zone, while Server and minimal installs usually default to public. Some Workstation setups already allow the ssh service, so verify the current rule before adding another one.

Check the Active Zone and SSH Rule

Start by asking firewalld which zone is active and whether that zone already allows the built-in ssh service.

sudo firewall-cmd --get-default-zone
sudo firewall-cmd --query-service=ssh

On the Fedora 43 Workstation VM used for verification, the output looked like this:

FedoraWorkstation
yes

A yes result means firewalld already allows SSH in the active zone. If firewall-cmd is missing on your system, install it with the guide to install firewalld on Fedora, then come back to these checks.

Allow the SSH Service When the Rule Is Missing

If the previous command returned no, add the service permanently and reload the active zone.

sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

List the active services afterward so you can confirm the zone now includes SSH.

sudo firewall-cmd --list-services

The verified Workstation output included SSH alongside the desktop defaults:

dhcpv6-client samba-client ssh

Connect with the Fedora SSH Client

Once the daemon is running, Fedora’s client tools let you test the connection, copy files, and reuse the same package set for other hosts. If a Server or minimal image does not have the client commands yet, install openssh-clients.

Find the Fedora IP Address for SSH

Check the active interface first so you know which IPv4 or IPv6 address the remote client should target.

ip -br addr

On the Fedora 43 VM used for verification, the active network interface looked like this:

lo               UNKNOWN        127.0.0.1/8 ::1/128
enp0s3           UP             192.168.50.254/24 fdde:514e:2780:cbca:7d48:89a9:8774:677c/64 fe80::d982:fa50:4632:add2/64

Use the address from your active interface, not the loopback entry on lo. On Workstation and Server systems alike, the interface name is often something like enp0s3, ens3, or wlp....

Open a Remote SSH Session to Fedora

Use your account name and the target server IP address or hostname to start a normal SSH session. If this Fedora system is missing the client tools, add them first.

sudo dnf install openssh-clients
ssh username@server-ip

On the first connection, SSH asks you to trust the server fingerprint before it adds the host key to ~/.ssh/known_hosts.

The authenticity of host 'server-ip (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

If you moved SSH to a non-default port, add it with -p, for example ssh -p 2222 username@server-ip. For more day-to-day flags and connection patterns, see the SSH command guide for Linux.

Transfer Files with SFTP or SCP on Fedora

The same openssh-clients package also provides sftp for interactive transfers and scp for direct copy operations.

sftp username@server-ip
scp ./local-file.txt username@server-ip:~/

Review Recent SSH Logins on Fedora

Fedora writes SSH activity to the systemd journal, so journalctl is the quickest way to review recent logins, disconnects, and authentication problems.

sudo journalctl -u sshd --no-pager -n 5

The Fedora 43 VM returned these recent SSH events:

Mar 14 14:59:35 fedora sshd-session[2290]: Accepted publickey for joshua from 192.168.50.16 port 65462 ssh2: ED25519 SHA256:OpkX6xgwZB/wYqQgLdcjqOJAo3rQ/xK7p/cEFjr+VLA
Mar 14 14:59:36 fedora sshd-session[2292]: Accepted publickey for joshua from 192.168.50.16 port 65463 ssh2: ED25519 SHA256:OpkX6xgwZB/wYqQgLdcjqOJAo3rQ/xK7p/cEFjr+VLA
Mar 14 14:59:36 fedora sshd-session[2290]: pam_unix(sshd:session): session opened for user joshua(uid=1000) by joshua(uid=0)
Mar 14 14:59:36 fedora sshd-session[2292]: pam_unix(sshd:session): session opened for user joshua(uid=1000) by joshua(uid=0)
Mar 14 14:59:36 fedora sshd-session[2292]: pam_lastlog2(sshd:session): SQL error: database is locked

Harden SSH on Fedora

Fedora 43 includes Include /etc/ssh/sshd_config.d/*.conf in the main server configuration, so small drop-in files are the safest way to harden SSH without rewriting the vendor defaults.

Disable Direct Root Login

Write a dedicated drop-in that blocks direct root logins while keeping the rest of Fedora’s shipped SSH configuration intact.

printf '%s\n' 'PermitRootLogin no' | sudo tee /etc/ssh/sshd_config.d/01-disable-root-login.conf > /dev/null

This uses tee because a plain > redirection would still run in your unprivileged shell and fail to write a root-owned file.

Test the syntax before you restart the daemon so you do not lock yourself out with a broken directive.

sudo sshd -t

A successful syntax check prints no output. Once that passes, restart the daemon.

sudo systemctl restart sshd.service

Switch to SSH Keys and Disable Password Logins

Generate a modern Ed25519 key pair on the client machine, then copy the public key to the Fedora host before you disable password authentication.

ssh-keygen -t ed25519
ssh-copy-id username@server-ip

After you confirm key-based logins work, place the authentication policy in a second drop-in file.

printf '%s\n' 'PubkeyAuthentication yes' 'PasswordAuthentication no' | sudo tee /etc/ssh/sshd_config.d/02-key-auth.conf > /dev/null

Test and restart again after you add the drop-in. Keep your current SSH session open until a fresh login succeeds with the key.

sudo sshd -t
sudo systemctl restart sshd.service

Restrict SSH Access to Specific Users on Fedora

If several local accounts exist on the system, narrow SSH access to the users who actually need remote logins.

printf '%s\n' 'AllowUsers joshua adminuser' | sudo tee /etc/ssh/sshd_config.d/04-allow-users.conf > /dev/null

Replace the example usernames with the real accounts that should keep SSH access. Test the daemon config again, then restart sshd so the allow list takes effect.

sudo sshd -t
sudo systemctl restart sshd.service

Change the SSH Port on Fedora

If you move SSH away from port 22, update the daemon config, firewalld, and SELinux together. Firewalld controls network access, while SELinux decides whether sshd is allowed to bind the new port at all.

printf '%s\n' 'Port 2222' | sudo tee /etc/ssh/sshd_config.d/03-custom-port.conf > /dev/null
sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload
sudo semanage port -a -t ssh_port_t -p tcp 2222

Verify that SELinux now labels the new port for SSH traffic before you restart the daemon.

sudo semanage port -l | grep '^ssh_port_t'

After adding port 2222 on the Fedora 43 test VM, SELinux showed both the default and custom port:

ssh_port_t                     tcp      2222, 22

Only restart sshd and test ssh -p 2222 username@server-ip after both firewalld and SELinux are updated. Keep port 22 open until the new login works from a second terminal.

Once SSH is stable, brute-force protection is the logical next layer. Pair this setup with the guide to install Fail2Ban with firewalld on Fedora if the server is reachable from untrusted networks.

Troubleshoot SSH on Fedora

Fix the ssh.service Unit Not Found Error

This is one of the easiest Fedora SSH mistakes to spot. The OpenSSH daemon does not use the Debian-style ssh.service name on Fedora.

Unit ssh.service could not be found.

Switch to the correct unit name and rerun the status check.

systemctl status sshd.service --no-pager

Fix Connection Refused Errors

A refused connection usually means nothing is listening on the port you tried, or you pointed the client at the wrong port.

ssh: connect to host localhost port 23: Connection refused

Check the service state first, then confirm that sshd is listening where you expect.

systemctl is-active sshd.service
sudo ss -tlnp | grep sshd

If the service is inactive, start it with sudo systemctl start sshd.service. If you changed the port, make sure the client uses the same value and that firewalld plus SELinux were both updated for that new port.

Fix Permission Denied Publickey Errors

Key-based logins fail most often because the file permissions are too open or the wrong public key was copied to the server.

Permission denied (publickey).

Reset the ownership and permissions on the server-side SSH directory, then confirm the correct key is present in authorized_keys.

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

The chmod command guide covers those permission patterns in more detail if you want a deeper breakdown.

Catch SSH Syntax Errors Before a Restart

Always run a syntax check after you change the daemon configuration. That is the fastest way to catch a typo before a restart fails.

sudo sshd -t

When a directive is invalid, sshd prints the file and line number. This is the exact format captured from a temporary broken config on the Fedora 43 VM:

/tmp/tmp.FUY15c0HCm: line 133: Bad configuration option: BadDirective
/tmp/tmp.FUY15c0HCm: terminating, 1 bad configuration options

Fix the reported directive, rerun sudo sshd -t, and only restart the daemon after the command returns no output.

Fix Custom Port Logins That Still Fail Under SELinux

If firewalld allows the new port but logins still fail, check whether SELinux still restricts sshd to port 22.

sudo semanage port -l | grep '^ssh_port_t'
sudo ausearch -m avc -ts recent | grep sshd

When the custom port is missing from the ssh_port_t list, add it with sudo semanage port -a -t ssh_port_t -p tcp 2222 and restart sshd again.

If you want more ways to filter those diagnostic commands, the grep command guide covers the patterns used here.

Remove OpenSSH Server on Fedora

Remove the Server Package

If you are currently connected to this Fedora machine over SSH, remove the server package from a local console or another out-of-band session. Stopping sshd during package removal will cut off the active remote login.

If you no longer want Fedora to accept inbound SSH connections, remove only the server package first. This leaves the client tools in place so you can still use ssh, scp, and sftp from the local machine.

sudo dnf remove openssh-server

Check the package state afterward so you know the server build is actually gone.

rpm -q openssh-server

After a successful removal, RPM reports package openssh-server is not installed.

package openssh-server is not installed

Remove Any Custom SSH Drop-In Files You Added

The next command only removes the custom hardening files created in this guide. It does not touch Fedora’s shipped SSH drop-ins such as 40-redhat-crypto-policies.conf or 50-redhat.conf.

sudo rm -f /etc/ssh/sshd_config.d/01-disable-root-login.conf /etc/ssh/sshd_config.d/02-key-auth.conf /etc/ssh/sshd_config.d/03-custom-port.conf /etc/ssh/sshd_config.d/04-allow-users.conf

SSH on Fedora FAQ

Is openssh-server installed by default on Fedora Workstation?

Not reliably. Fedora Workstation usually already includes the client tools from openssh-clients, but you should still verify openssh-server and sshd.service on your own system. Custom images and previously configured machines may already have the server installed, while other Fedora installs need you to add and enable it yourself.

Which Fedora package installs the SSH client commands?

Fedora installs the client commands from openssh-clients. That package provides ssh, scp, sftp, and related client utilities. The inbound daemon belongs to openssh-server instead.

Why does systemctl status ssh fail on Fedora?

Fedora uses sshd.service as the OpenSSH unit name. The command systemctl status ssh fails because there is no ssh.service unit on Fedora. Use systemctl status sshd.service, systemctl enable --now sshd.service, and similar sshd-based commands instead.

Do I need to update both firewalld and SELinux when I change the SSH port?

Yes. Firewalld opens the network path to the new port, while SELinux decides whether sshd is allowed to bind that port. If you change only the firewall rule and skip semanage port -a -t ssh_port_t -p tcp PORT, SSH can still fail even though the port looks open from the network side.

Conclusion

SSH is now running on Fedora with the right sshd.service commands, firewalld access, and a clean path to key-only logins or custom ports. For the next security layer, install Fail2Ban with firewalld on Fedora, and keep the client side sharp with the SSH command guide for Linux.

Search LinuxCapable

Need another guide?

Search LinuxCapable for package installs, commands, troubleshooting, and follow-up guides related to what you just read.

Found this guide useful?

Support LinuxCapable to keep tutorials free and up to date.

Buy me a coffee Buy me a coffee

Before commenting, please review our Comments Policy.
Formatting tips for your comment

You can use basic HTML to format your comment. Useful tags currently allowed:

You type Result
<code>command</code> command
<strong>bold</strong> bold
<em>italic</em> italic
<blockquote>quote</blockquote> quote block

Leave a Comment

We read and reply to every comment - let us know how we can help or improve this guide.

Let us know you are human: