How to Install SSH on Fedora 44

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. A package named ssh resolves to the client tools on Fedora, so use openssh-server when the goal is accepting incoming SSH logins.

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. Do not use sudo dnf install ssh for the server daemon; DNF resolves that name to the client package on Fedora.

rpm -q openssh-clients openssh-server

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

openssh-clients-10.2p1-10.fc44.x86_64
openssh-server-10.2p1-10.fc44.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 and is enabled for the next boot.

systemctl is-active sshd.service
systemctl is-enabled sshd.service

A healthy service returns:

active
enabled

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.2p1, OpenSSL 3.5.5 27 Jan 2026

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 -tln | grep ':22'

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:*
LISTEN 0      128             [::]:22           [::]:*

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 default-zone rule before adding another one.

Check the Default Zone and SSH Rule

Start by asking firewalld which zone is the default and whether that zone already allows the built-in ssh service. If your network interface is assigned to a different active zone, repeat the service query with that zone name.

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

A Fedora Workstation system that already allows SSH returns:

FedoraWorkstation
yes

A yes result means firewalld already allows SSH in the default zone. If firewall-cmd is missing on your system, install it with the guide to install firewalld on Fedora, then rerun the zone and service checks.

Allow the SSH Service When the Rule Is Missing

If the query returned no, add the service permanently and reload firewalld.

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

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

sudo firewall-cmd --list-services

A Workstation zone with SSH enabled includes the service 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

A Fedora Workstation system with one active wired interface can look like this:

lo               UNKNOWN        127.0.0.1/8 ::1/128
ens160           UP             192.168.50.233/24 fdde:514e:2780:cbca:7d60:6b73:774:d4a8/64 fe80::783a:cbb6:dc7:27c5/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. Compare that fingerprint with the server’s real host key when you manage both ends of the connection.

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

For a successful key login, look for stable markers such as Accepted publickey and pam_unix(sshd:session): session opened. Authentication failures commonly include Failed password, Invalid user, or disconnect messages from the client address.

Harden SSH on Fedora

Fedora 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' 'KbdInteractiveAuthentication 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 add a non-default SSH port, 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 22' '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

The semanage command comes from policycoreutils-python-utils. Install that package first if the command is missing on a minimal Fedora system.

sudo dnf install policycoreutils-python-utils

The add command is correct when port 2222 is not already assigned in SELinux policy. If semanage reports that the port is already defined, inspect the current label before changing it, then choose a different port or modify the label only when you know the existing service does not need it.

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, SELinux should show both the default and custom port:

ssh_port_t                     tcp      2222, 22

Test the daemon configuration, restart sshd, and confirm the effective port list. Keeping both Port 22 and Port 2222 in the drop-in preserves the existing SSH path while you test the new one from a second terminal.

sudo sshd -t
sudo systemctl restart sshd.service
sudo sshd -T | grep '^port '

The effective configuration should list both ports during the transition:

port 22
port 2222

Test ssh -p 2222 username@server-ip before you remove port 22 from the drop-in or firewall. Keep a working local console or existing SSH session open until a fresh login succeeds on the new port.

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.

Update OpenSSH Server on Fedora

Fedora updates openssh-server and openssh-clients through DNF like the rest of the system packages. Use a targeted upgrade when you only want to refresh the SSH package pair.

sudo dnf upgrade --refresh openssh-server openssh-clients

If DNF reports Nothing to do., the installed OpenSSH packages already match the enabled Fedora repositories. When a package update is installed, keep the current session open and test a fresh SSH login after restarting the daemon.

sudo systemctl restart sshd.service
systemctl is-active sshd.service

The service should return active after the restart. Existing SSH sessions usually remain open, but the separate test login proves new connections still work before you close your current terminal.

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.

sudo chown -R "$USER":"$(id -gn)" ~/.ssh
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:

/home/user/sshd-bad-test.conf: line 134: Bad configuration option: BadDirective
/home/user/sshd-bad-test.conf: 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.

For more ways to filter diagnostic output, 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 Custom Firewall and SELinux Port Rules

If you added a custom SSH port for this setup, remove the matching firewalld and SELinux entries when that port is no longer needed. Skip these commands if another service or policy still depends on the same port.

sudo firewall-cmd --permanent --remove-port=2222/tcp
sudo firewall-cmd --reload
sudo semanage port -d -t ssh_port_t -p tcp 2222

If you added the built-in ssh firewalld service only for this setup and no SSH listener should remain reachable on port 22, remove that rule separately. Skip this cleanup when the rule already existed before the SSH server was installed.

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

Remove Any Custom SSH Drop-In Files You Added

This cleanup only removes the custom hardening files created earlier. 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

Conclusion

SSH is running on Fedora with the correct sshd.service commands, firewalld access, and a safer path to key-only logins or custom ports. Keep a second access path open while changing authentication or port settings, then add log-based protection such as Fail2Ban if the host is exposed to untrusted networks.