Remote administration over SSH gives an openSUSE or SLES machine an encrypted terminal login. Enabling SSH requires a running OpenSSH server and an allowed ssh service in the firewall zone handling the client connection.

The openssh package provides the server software, and sshd accepts incoming connections. A running daemon alone does not guarantee remote access because firewalld can assign the network interface to a different zone from the system default. SSH provides a remote shell; a graphical remote desktop needs a separate service.

An existing non-root account and console access with sudo privileges are enough to enable access after installation. Starting the server creates a network listener, and allowing ssh exposes TCP port 22 to clients accepted by that zone. Keep console access available until a login from another machine works, especially on a host reachable from untrusted networks.

Steps to enable SSH on openSUSE and SLES:

  1. Ensure the OpenSSH package is installed. 
    $ sudo zypper install openssh
##### snipped #####
'openssh' is already installed.
##### snipped #####
Nothing to do.

    The package may already be present even when remote SSH access is disabled.

  2. Enable sshd with immediate activation. 
    $ sudo systemctl enable --now sshd.service
Created symlink '/etc/systemd/system/multi-user.target.wants/sshd.service' → '/usr/lib/systemd/system/sshd.service'.

    The --now option starts the daemon immediately while also enabling it for future boots.

  3. Confirm that sshd is running. 
    $ sudo systemctl status sshd --no-pager
● sshd.service - OpenSSH Daemon
     Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; preset: disabled)
     Active: active (running) since Thu 2026-11-05 16:21:23 +08; 21ms ago
##### snipped #####

    Related: Manage the SSH server service
    Related: Manage services in openSUSE and SLES

  4. Identify the server interface used to reach the SSH client. 
    $ ip route get 192.0.2.10
192.0.2.10 dev enp0s5 src 192.0.2.25 uid 0
    cache

    Here 192.0.2.10 represents the other machine's IP address, enp0s5 is the server interface, and 192.0.2.25 is the server address used for the final login. Substitute your client's reachable address. On a system with asymmetric routing, the incoming interface may differ from the return route; the relevant interface is the one receiving the client's SSH connection.

  5. Check whether firewalld is running. 
    $ sudo firewall-cmd --state
running

    If the result is not running or firewall-cmd is not installed, skip the remaining firewalld steps and continue to the final login test. Do not install or start a firewall just to enable SSH. An existing alternative firewall or upstream network firewall still needs to permit TCP port 22. A failed firewalld startup needs investigation before its policy can be changed.

  6. Inspect the active firewall zones for a source binding matching the client. 
    $ sudo firewall-cmd --get-active-zones
docker
  interfaces: docker0
internal
  interfaces: enp0s5
public (default)

    A matching client address or subnet under sources can select a zone instead of the interface assignment. In that case, use that source zone for the SSH rules. This output has no source binding; enp0s5 belongs to internal even though the default is public.

  7. Query the zone assigned to the server's connection interface. 
    $ sudo firewall-cmd --get-zone-of-interface=enp0s5
internal

    If your interface has no explicit zone and no source binding matches the client, sudo firewall-cmd –get-default-zone reports the fallback zone. Substitute the selected zone for internal in the remaining firewall steps.

    Allowing ssh permits TCP port 22 for clients handled by that zone, including other interfaces or source ranges assigned to it. It does not restrict access to the single client used for testing.

  8. Allow the predefined ssh service in the selected runtime zone. 
    $ sudo firewall-cmd --zone=internal --add-service=ssh
success
  9. Save the same SSH allowance in the selected permanent zone. 
    $ sudo firewall-cmd --zone=internal --permanent --add-service=ssh
success

    The runtime rule takes effect immediately; the permanent rule survives a firewall restart or reboot. Applying both avoids a reload that could discard unrelated runtime-only changes.

  10. Verify the runtime SSH allowance in the selected zone. 
    $ sudo firewall-cmd --zone=internal --query-service=ssh
yes
  11. Verify the saved SSH allowance in the selected zone. 
    $ sudo firewall-cmd --zone=internal --permanent --query-service=ssh
yes
  12. Open an SSH session from another machine using the server's reachable address. 
    $ ssh user@192.0.2.25
##### snipped #####
user@server1:~>

    Substitute an existing non-root account for user. On a first connection, compare the displayed host-key fingerprint with the server's fingerprint obtained through its console or administrator before accepting it. Authentication may use your SSH key or prompt for the account's password. A remote shell prompt confirms login; Connection refused or a timeout means the listener, route, or firewall still needs attention, while Permission denied points to authentication policy.

  13. Confirm the account name inside the remote SSH session. 
    user@server1:~> whoami
user
Share this guide