Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Security and Hardening Guide
  1. Preface
  2. 1 Security and confidentiality
  3. 2 Common Criteria
  4. I Authentication
    1. 3 Authentication with PAM
    2. 4 Using NIS
    3. 5 Setting up authentication clients using YaST
    4. 6 LDAP with 389 Directory Server
    5. 7 Network authentication with Kerberos
    6. 8 Active Directory support
    7. 9 Setting up a freeRADIUS server
  5. II Local security
    1. 10 Physical security
    2. 11 Software management
    3. 12 File management
    4. 13 Encrypting partitions and files
    5. 14 Storage encryption for hosted applications with cryptctl
    6. 15 User management
    7. 16 Restricting cron and at
    8. 17 Spectre/Meltdown checker
    9. 18 Configuring security settings with YaST
    10. 19 Authorization with PolKit
    11. 20 Access control lists in Linux
    12. 21 Intrusion detection with AIDE
  6. III Network security
    1. 22 X Window System and X authentication
    2. 23 Securing network operations with OpenSSH
    3. 24 Masquerading and firewalls
    4. 25 Configuring a VPN server
    5. 26 Managing a PKI with XCA, X certificate and key manager
    6. 27 Improving network security with sysctl variables
    7. 28 Enabling compliance with FIPS 140-2
  7. IV Confining privileges with AppArmor
    1. 29 Introducing AppArmor
    2. 30 Getting started
    3. 31 Immunizing programs
    4. 32 Profile components and syntax
    5. 33 AppArmor profile repositories
    6. 34 Building and managing profiles with YaST
    7. 35 Building profiles from the command line
    8. 36 Profiling your Web applications using ChangeHat
    9. 37 Confining users with pam_apparmor
    10. 38 Managing profiled applications
    11. 39 Support
    12. 40 AppArmor glossary
  8. V SELinux
    1. 41 Configuring SELinux
  9. VI The Linux Audit Framework
    1. 42 Understanding Linux audit
    2. 43 Setting up the Linux audit framework
    3. 44 Introducing an audit rule set
    4. 45 Useful resources
  10. A GNU licenses
Applies to openSUSE Leap 15.3

23 Securing network operations with OpenSSH Edit source


OpenSSH is the SSH (secure shell) implementation that ships with SUSE Linux Enterprise Server, for securing network operations such as remote administration, file transfers, and tunneling insecure protocols. SSH encrypts all traffic, including authentication, to protect against eavesdropping and connection hijacking. This chapter covers basic operations, plus host key rotation and certificate authentication, which are especially useful for managing larger SSH deployments.

23.1 OpenSSH overview Edit source

SSH is a protocol that provides end-to-end protection for communications between the computers on your network, or between computers on your network and systems outside your network. SSH is a client-server protocol. Any host running the sshd daemon can accept connections from any other host. Every host running sshd can have their own custom custom configurations, such as limiting who can have access, and which authentication protocols are allowed.

The openssh package installs the server, client, file transfer commands, and helper utilities.

OpenSSH supports several different types of authentication:

Password authentication

Uses your system login and password; you must have a user account on the machine you are connecting to. This is the simplest and most flexible authentication because you can open an SSH session from anywhere, on any machine. It is also the least secure, because it is vulnerable to password-cracking and keystroke logging.

Public key authentication

Authenticates with your personal SSH keys, rather than your system login. This is less flexible than password authentication, because you can open SSH sessions only from a machine that holds your private identity key. It is much stronger because it is not vulnerable to password cracking or keystroke logging; an attacker must possess your private key and know its passphrase.

Passphrase-less public key authentication

Public key authentication, paired with private identity keys that do not have passphrases. This is useful for automated services, like scripts and cron jobs. You must protect private keys, because anyone who gains access to them can easily masquerade as the key owner.

A useful alternative is to use ssh-agent and related utilities for managing passphrase-protected keys. These hold passphrases in memory, and apply them as needed.

Certificate authentication

OpenSSH supports certification authentication, for easier key management and large-scale SSH deployments.

openSUSE Leap installs the OpenSSH package by default, providing the following commands:


The client command for initiating an SSH connection to a remote host.


Secure file copy from or to a remote host.


Secure file transfer between a client and an SFTP server.


Add private key identities to the authentication agent, ssh-agent.


Manages a user's private identity keys and their passphrases, for public key authentication. ssh-agent holds the passphrases in memory and applies them as needed, so that users do not have to type their passphrases to authenticate.


Securely transfer a public key to a remote host, to set up public key authentication.


Collect the public SSH host keys of a number of hosts, for populating known_hosts files.

23.2 Server hardening Edit source

OpenSSH ships with a usable default server configuration, but there are additional steps you can take to secure your server.

The default server configuration file, /etc/ssh/sshd_config, contains the default configuration, and all the defaults are commented out. Override any default item by entering your own configuration item, uncommented, like the following example that sets a different listening port, and specifies the listening IPv4 address:

#Port 22
Port 2022


The following settings for /etc/ssh/sshd_config strengthen access controls:

# Check if the file modes and ownership of the user’s files and
# home directory are correct before allowing them to login
StrictModes yes

# If your machine has more than one IP address, define which address or
# addresses it listens on

# Allow only members of the listed groups to log in
AllowGroups ldapadmins backupadmins

# Or, deny certain groups. If you use both, DenyGroups is read first
DenyGroups users

# Allow or deny certain users. If you use both, DenyUsers is read first
AllowUsers user1 user2 user3
DenyUsers user4

# Allow root logins only with public key authentication
PermitRootLogin prohibit-password

# Disable password authentication and allow only public key authentication
# for all users
PasswordAuthentication no

After changing /etc/ssh/sshd_config, run the syntax checker:

> sudo sshd -t

The syntax checker only checks for correct syntax, and does not find configuration errors. When you are finished, reload the configuration:

> sudo systemctl reload sshd.server

Check the server's key directories for correct permissions.

/etc/ssh should be mode 0755/drwxr-xr-x, owned by root:root.

Private keys should be 0600/-rw-------, owned by root:root.

Private keys should be 0644/-rw-r--r--, owned by root:root.

23.3 Password authentication Edit source

With ssh you may log in to remote systems and work interactively. To log in to the host sun as user tux enter one of the following commands:

> ssh tux@sun
> ssh -l tux sun

Type exit and press Enter to close an SSH session.

If the user name is the same on both machines, you can omit it, and then using ssh sun is sufficient. The remote host prompts for the remote user's password. After a successful authentication, you can work on the remote command line or use interactive applications, such as YaST in text mode.

You may also run non-interactive commands on remote systems using ssh USER_NAME HOST COMMAND. COMMAND needs to be properly quoted. Multiple commands can be concatenated as on a local shell:

> ssh root@sun "dmesg -T | tail -n 25"
> ssh root@sun "cat /etc/os-release && uptime"

23.3.1 Starting X11 applications on a remote host Edit source

You can run graphical applications that are installed on a remote machine on your local computer. X11Forwarding Yes must be set in the /etc/ssh/sshd_config file on the remote machine. Then, when you run ssh with the -X option, the DISPLAY variable is automatically set on the remote machine, and all X output is exported to the local machine over the SSH connection. At the same time, X applications started remotely cannot be intercepted by unauthorized individuals.

A quick test is to run a simple game from the remote machine, such as GNOME Mines:

> ssh tux@sun
Last login: Tue May 10 11:29:06 2022 from
Have a lot of fun...

tux@sun gnome-mines

The remote application should appear on your local machine just as though it were installed locally. (Note that network lag may affect performance.) Close the remote application in the usual way, such as clicking the close button. This closes only the application, and your SSH session remains open.

Important: X11 forwarding does not work on Wayland

X11 forwarding requires the X Windows System, which is the default on SLE, and not the Wayland display server protocol. The X Windows System has built-in networking, while Wayland does not.

Use the following command to learn if your system runs X or Wayland:


If Wayland is in use, it looks like the following example:


23.3.2 Agent forwarding Edit source

By adding the -A option, the ssh-agent authentication mechanism is carried over to the next machine. This way, you can work from different machines without having to enter a password, but only if you have distributed your public key to the destination hosts and properly saved it there. (Refer to Section 23.7.2, “Copying an SSH key” to learn the safe way to copy your public keys to other hosts.)

23.4 scp—secure copy Edit source

scp copies files to or from a remote machine. If the user name on jupiter is different than the user name on sun, specify the latter using the USER_NAME@host format. If the file should be copied into a directory other than the remote user's home directory, specify it as sun:DIRECTORY. The following examples show how to copy a file from a local to a remote machine and vice versa.

> scp ~/MyLetter.tex tux@sun:/tmp 1
> scp tux@sun:/tmp/MyLetter.tex ~ 2


local to remote


remote to local

Tip: The -l option

With the ssh command, the option -l can be used to specify a remote user (as an alternative to the USER_NAME@host format). With scp the option -l is used to limit the bandwidth consumed by scp.

After the correct password is entered, scp starts the data transfer. It displays a progress bar and the time remaining for each file that is copied. Suppress all output with the -q option.

scp also provides a recursive copying feature for entire directories. The command

> scp -r src/ sun:backup/

copies the entire contents of the directory src including all subdirectories to the ~/backup directory on the host sun. If this subdirectory does not exist, it is created automatically.

The -p option tells scp to leave the time stamp of files unchanged. -C compresses the data transfer. This minimizes the data volume to transfer, but creates a heavier burden on the processors of both machines.

23.5 sftp—secure file transfer Edit source

23.5.1 Using sftp Edit source

If you want to copy several files from or to different locations, sftp is a convenient alternative to scp. It opens a shell with a set of commands similar to a regular FTP shell. Type help at the sftp-prompt to get a list of available commands. More details are available from the sftp man page.

> sftp sun
Enter passphrase for key '/home/tux/.ssh/id_rsa':
Connected to sun.
sftp> help
Available commands:
bye                                Quit sftp
cd path                            Change remote directory to 'path'

23.5.2 Setting permissions for file uploads Edit source

As with a regular FTP server, a user cannot only download, but also upload files to a remote machine running an SFTP server by using the put command. By default the files will be uploaded to the remote host with the same permissions as on the local host. There are two options to automatically alter these permissions:

Setting a umask

A umask works as a filter against the permissions of the original file on the local host. It can only withdraw permissions:

Table 23.1:

permissions original


permissions uploaded










To apply a umask on an SFTP server, edit the file /etc/ssh/sshd_configuration. Search for the line beginning with Subsystem sftp and add the -u parameter with the desired setting, for example:

Subsystem sftp /usr/lib/ssh/sftp-server -u 0002
Explicitly setting the permissions

Explicitly setting the permissions sets the same permissions for all files uploaded via SFTP. Specify a three-digit pattern such as 600, 644, or 755 with -u. When both -m and -u are specified, -u is ignored.

To apply explicit permissions for uploaded files on an SFTP server, edit the file /etc/ssh/sshd_configuration. Search for the line beginning with Subsystem sftp and add the -m parameter with the desired setting, for example:

Subsystem sftp /usr/lib/ssh/sftp-server -m 600

23.6 The SSH daemon (sshd) Edit source

To work with the SSH client programs ssh and scp, a server (the SSH daemon) must be running in the background, listening for connections on TCP/IP port 22. The daemon generates host key pairs when starting for the first time. Each key pair consists of a private and a public key. Therefore, this procedure is called public key-based. To guarantee the security of the communication via SSH, access to the private key files must be restricted to the system administrator. The file permissions are set accordingly by the default installation. The private keys are only required locally by the SSH daemon and must not be given to anyone else. The public key components (recognizable by the name extension .pub) are sent to the client requesting the connection. They are readable for all users.

A connection is initiated by the SSH client. The waiting SSH daemon and the requesting SSH client exchange identification data to compare the protocol and software versions, and to prevent connections through the wrong port. Because a child process of the original SSH daemon replies to the request, several SSH connections can be made simultaneously.

The private host and server keys are absolutely required to decrypt the session key and cannot be derived from the public parts. Only the contacted SSH daemon can decrypt the session key using its private keys. This initial connection phase can be watched closely by turning on verbose debugging using the -v option of the SSH client.

Tip: Viewing the SSH daemon log file

To watch the log entries from the sshd use the following command:

> sudo journalctl -u sshd

23.6.1 Maintaining SSH keys Edit source

It is recommended to back up the private and public keys stored in /etc/ssh/ in a secure, external location. In this way, key modifications can be detected or the old ones can be used again after having installed a new system.

Tip: Existing SSH host keys

If you install openSUSE Leap on a machine with existing Linux installations, the installation routine automatically imports the SSH host key with the most recent access time from an existing installation.

When establishing a secure connection with a remote host for the first time, the client stores all public host keys in ~/.ssh/known_hosts. This prevents any man-in-the-middle attacks—attempts by foreign SSH servers to use spoofed names and IP addresses. Such attacks are detected either by a host key that is not included in ~/.ssh/known_hosts, or by the server's inability to decrypt the session key in the absence of an appropriate private counterpart.

If the public keys of a host have changed (that needs to be verified before connecting to such a server), the offending keys can be removed with ssh-keygen -r HOSTNAME.

23.6.2 Rotating host keys Edit source

As of version 6.8, OpenSSH includes a protocol extension that supports host key rotation. Server admins must periodically retire old host keys and create new keys, for example if a key has been compromised, or it is time to upgrade to stronger keys. Before OpenSSH 6.8, if StrictHostKeyChecking was set to yes in ssh_config on client machines, clients would see a warning that the host key had changed, and were not allowed to connect. Then the users would have to manually delete the server's public key from their known_hosts file, reconnect, and manually accept the new key. Any automated SSH connections, such as scheduled backups, would fail.

The new host key rotation scheme provides a method to distribute new keys without service interruptions. When clients connect, the server sends them a list of new keys. Then the next time they log in they are asked if they wish to accept the changes. Give users a few days to connect and receive the new keys, and then remove the old keys. The known_hosts files on the clients are automatically updated, with new keys added and the old keys removed.

Setting up host key rotations requires creating new keys on the server, some changes to /etc/ssh/sshd_config on the server, and to /etc/ssh/ssh_config on the clients.

First create your new key or keys. The following example creates a new RSA key and a new Ed25519 key, with comments. The new keys must have unique names. A useful convention is to name them with the creation date. Remember, a host key must not have a passphrase:

# ssh-keygen -t rsa -f ssh_host_rsa_2022-01 -C "main server"
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in ssh_host_rsa_2022-01
Your public key has been saved in ssh_host_rsa_2022-01.pub
The key fingerprint is:
SHA256:F1FIF2aqOz7D3mGdsjzHpH/kjUWZehBN3uG7FM4taAQ main server
The key's randomart image is:
+---[RSA 3072]----+
|         .Eo*.oo |
|          .B .o.o|
|          o . .++|
|         . o ooo=|
|        S . o +*.|
|         o o.oooo|
|       .o ++oo.= |
|       .+=o+o + .|
|       .oo++..   |

# ssh-keygen -t ed25519 -f ssh_host_ed25519_2022-01 -C "main server"
Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in ssh_host_ed25519_2022-01
Your public key has been saved in ssh_host_ed25519_2022-01.pub
The key fingerprint is:
SHA256:2p9K0giXv7WsRnLjwjs4hJ8EFcoX1FWR4nQz6fxnjxg root@server2
The key's randomart image is:
+--[ED25519 256]--+
|   .+o ...o+     |
| . .... o *      |
|  o..  o = o     |
|  ..   .. o      |
|   o. o S  .     |
|  . oo.*+   E o  |
|   + ++==..  = o |
|    = +oo= o. . .|
|     ..=+o=      |

Record the fingerprints, for users to verify the new keys.

Add the new key names to /etc/ssh/sshd_config, and uncomment any existing keys that are in use:

## Old keys
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_ecdsa_key

## New replacement keys
HostKey /etc/ssh/ssh_host_rsa_2022-01
HostKey /etc/ssh/ssh_host_ed25519_2022-01

Save your changes, then restart sshd:

# systemctl restart sshd.service

The /etc/ssh/ssh_config file on the clients must include the following settings:

UpdateHostKeys ask
StrictHostKeyChecking yes

Test connecting from a client by opening an SSH session to the server to receive the new keys list. Log out, then log back in. When you log back in you should see something like the following message:

The server has updated its host keys.
These changes were verified by the server's existing trusted key.
Deprecating obsolete hostkey: ED25519
Deprecating obsolete hostkey:
RSA SHA256:+NR4DVdbsUNsqJPIhISzx+eqD4x/awCCwijZ4a9eP8I
Accept updated hostkeys? (yes/no):

You may set UpdateHostKeys ask to UpdateHostKeys yes to apply the changes automatically, and avoid asking the user to approve the changes, though asking them to review the changes and compare fingerprints is safer.

For more information:

23.7 SSH authentication mechanisms Edit source

In its simplest form, authentication is done by entering the user's password just as if logging in locally. However, having to memorize passwords of several users on remote machines is inefficient. What is more, these passwords may change. On the other hand—when granting root access—an administrator needs to be able to quickly revoke such a permission without having to change the root password.

To accomplish a login that does not require to enter the remote user's password, SSH uses another key pair, which needs to be generated by the user. It consists of a public (id_rsa.pub or id_dsa.pub) and a private key (id_rsa or id_dsa).

To be able to log in without having to specify the remote user's password, the public key of the SSH user must be in ~/.ssh/authorized_keys. This approach also ensures that the remote user has got full control: adding the key requires the remote user's password and removing the key revokes the permission to log in from remote.

For maximum security such a key should be protected by a passphrase which needs to be entered every time you use ssh, scp, or sftp. Contrary to the simple authentication, this passphrase is independent from the remote user and therefore always the same.

An alternative to the key-based authentication described above, SSH also offers a host-based authentication. With host-based authentication, users on a trusted host can log in to another host on which this feature is enabled using the same user name. openSUSE Leap is set up for using key-based authentication, covering setting up host-based authentication on openSUSE Leap is beyond the scope of this manual.

Note: File permissions for host-based authentication

If the host-based authentication is to be used, the file /usr/lib/ssh/ssh-keysign should have the setuid bit set, which is not the default setting in openSUSE Leap. In such case, set the file permissions manually. You should use /etc/permissions.local for this purpose, to make sure that the setuid bit is preserved after security updates of openssh.

23.7.1 Generating Client and Host SSH keys Edit source

There are several key types to choose from: DSA, RSA, ECDSA, ECDSA-SK, Ed25519, and Ed25519-SK. DSA was deprecated several years, and disabled in OpenSSH 7.0 and should not be used. RSA is the most universal as it is older, and more widely used.

Ed25519 and ECDSA are stronger and faster. Ed25519 is considered to be the strongest. If you must support older clients that do not support Ed25519, create both Ed25519 and RSA host keys.

Note: Older clients may be unsafe

Some older SSH clients do not support ECDSA and ED25519. ECDSA and ED25519 were released with OpenSSH 6.5 in 2014. It is important to keep security services updated, and, if possible, to not allow unsafe old clients.

SSH keys serve two purposes: authenticating servers with host keys, and authenticating clients. Host keys are stored in /etc/ssh. Client keys are specific to users, and are stored in /home/user/.ssh.

Host keys must not have passphrases.

In most cases, private client keys should have strong passwords.

The following procedure shows how to create client keys.

Procedure 23.1: Creating client SSH key pairs
  1. To generate a client key pair with the default parameters (RSA, 3072 bits), use the ssh-keygen command with no options. Protect your private key with a strong passphrase:

    > ssh-keygen
    Generating public/private rsa key pair.
    Enter file in which to save the key (/home/user/.ssh/id_rsa):
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in /home/user/.ssh/id_rsa
    Your public key has been saved in /home/user/.ssh/id_rsa.pub
    The key fingerprint is:
    SHA256:z0uJIuc7Doy07bFTe1ppZHLVrkD/bWWlBAF/PcHjblU user@server2
    The key's randomart image is:
    +---[RSA 3072]----+
    |          ..o... |
    |           o . +E|
    |        . . o +.=|
    |       . o . o o+|
    |  .   . S . . o +|
    | . =  .= * + . = |
    |  o *.o.= * . +  |
    |   ..Bo+.. . .   |
    |    oo==  .      |
  2. Create an RSA key pair with a longer bit length:

    > ssh-keygen -b 4096

    OpenSSH RSA keys can be a maximum of 16,384 bits. However, longer bit lengths are not necessarily more desirable. See the GnuPG FAQ for more information, https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096.

  3. Create an RSA key pair with a custom name and a comment:

    > ssh-keygen -f backup-server-key -C "infrastructure backup server"
  4. Create an Ed25519 key pair with a comment:

    > ssh-keygen -t ed25519 -f ldap-server-key -C "Internal HTTP server"

    Ed25519 keys are fixed at 256 bits, which is equivalent in cryptographic strength to RSA 4096.

Host keys are managed a little differently. A host key must not have a passphrase, and the key pairs are stored in /etc/ssh. OpenSSH automatically generates a set of host keys when it is installed, like the following example:

> ls -l /etc/ssh
total 608
-rw------- 1 root root 577834 2021-05-06 04:48 moduli
-rw-r--r-- 1 root root   2403 2021-05-06 04:48 ssh_config
-rw-r----- 1 root root   3420 2021-05-06 04:48 sshd_config
-rw------- 1 root root   1381 2022-02-10 06:55 ssh_host_dsa_key
-rw-r--r-- 1 root root    604 2022-02-10 06:55 ssh_host_dsa_key.pub
-rw------- 1 root root    505 2022-02-10 06:55 ssh_host_ecdsa_key
-rw-r--r-- 1 root root    176 2022-02-10 06:55 ssh_host_ecdsa_key.pub
-rw------- 1 root root    411 2022-02-10 06:55 ssh_host_ed25519_key
-rw-r--r-- 1 root root     96 2022-02-10 06:55 ssh_host_ed25519_key.pub
-rw------- 1 root root   2602 2022-02-10 06:55 ssh_host_rsa_key
-rw-r--r-- 1 root root    568 2022-02-10 06:55 ssh_host_rsa_key.pub

ssh-keygen has a special option, -A, for creating new host keys. This creates new keys for each of the key types for which host keys do not exist, with the default key file path, an empty passphrase, default bit size for the key type, and an empty comment. The following example creates a complete new set of keys by first deleting the existing keys, then creating a new set:

> sudo rm /etc/ssh/ssh_host*
> sudo ssh-keygen -A

You can replace selected key pairs by first deleting only the keys you want to replace, because ssh-keygen -A does not replace existing keys.


ssh-keygen -A still creates DSA keys, even though they have been deprecated as unsafe for several years. In OpenSSH 7.0 they are still created, but disabled by not being listed in sshd_config. You may safely delete DSA keys.

When you want to rotate host keys, you must create the new keys individually, because they must exist at the same time as your old host keys. Your clients will authenticate with the old keys, and then receive the list of new keys. They need unique names, to not conflict with the old keys. The following example creates new RSA and Ed25519 host keys, labeled with the year and month they were created. Remember, the new host ukeys must not have passphrases:

> cd /etc/ssh
> sudo ssh-keygen -b 4096 -f "ssh_host_rsa_2022_02"
> sudo ssh-keygen -t ed25519 -f "ssh_host_ed25519_2022_02"

You may name your new keys whatever you want.

23.7.2 Copying an SSH key Edit source

To copy a public SSH key to ~/.ssh/authorized_keys of a user on a remote machine, use the command ssh-copy-id. To copy your personal key stored under ~/.ssh/id_rsa.pub you may use the short form. To copy DSA keys or keys of other users, you need to specify the path:

> ~/.ssh/id_rsa.pub
ssh-copy-id -i tux@sun

> ~/.ssh/id_dsa.pub
ssh-copy-id -i ~/.ssh/id_dsa.pub  tux@sun

> ~notme/.ssh/id_rsa.pub
ssh-copy-id -i ~notme/.ssh/id_rsa.pub  tux@sun

To successfully copy the key, you need to enter the remote user's password. To remove an existing key, manually edit ~/.ssh/authorized_keys.

23.7.3 Using the ssh-agent Edit source

When doing lots of secure shell operations it is cumbersome to type the SSH passphrase for each such operation. Therefore, the SSH package provides another tool, ssh-agent, which retains the private keys for the duration of an X or terminal session. All other windows or programs are started as clients to the ssh-agent. By starting the agent, a set of environment variables is set, which will be used by ssh, scp, or sftp to locate the agent for automatic login. See the ssh-agent man page for details.

After the ssh-agent is started, you need to add your keys by using ssh-add. It will prompt for the passphrase. After the password has been provided once, you can use the secure shell commands within the running session without having to authenticate again. Using ssh-agent in an X session Edit source

On openSUSE Leap, the ssh-agent is automatically started by the GNOME display manager. To also invoke ssh-add to add your keys to the agent at the beginning of an X session, do the following:

  1. Log in as the desired user and check whether the file ~/.xinitrc exists.

  2. If it does not exist, use an existing template or copy it from /etc/skel:

    if [ -f ~/.xinitrc.template ]; then mv ~/.xinitrc.template ~/.xinitrc; \
    else cp /etc/skel/.xinitrc.template ~/.xinitrc; fi
  3. If you have copied the template, search for the following lines and uncomment them. If ~/.xinitrc already existed, add the following lines (without comment signs).

    # if test -S "$SSH_AUTH_SOCK" -a -x "$SSH_ASKPASS"; then
    #       ssh-add < /dev/null
    # fi
  4. When starting a new X session, you will be prompted for your SSH passphrase. Using ssh-agent in a terminal session Edit source

In a terminal session you need to manually start the ssh-agent and then call ssh-add afterward. There are two ways to start the agent. The first example given below starts a new Bash shell on top of your existing shell. The second example starts the agent in the existing shell and modifies the environment as needed.

> ssh-agent -s /bin/bash
eval $(ssh-agent)

After the agent has been started, run ssh-add to provide the agent with your keys.

23.8 Restricting SSH logins Edit source

The SSH service on a machine can be restricted to allow logins only from a certain IP subnet for a given account. Perform the following steps to configure user remote login restrictions for ssh (Section 23.3, “Password authentication”), scp (Section 23.4, “scp—secure copy”), and sftp (Section 23.5, “sftp—secure file transfer”.

  1. Edit the file /etc/pam.d/sshd and append the following at the end of the auth block:

    auth required pam_access.so
  2. Edit the file /etc/security/access.conf to configure individual restrictions. In this example the users root and tux are restricted to the network, while the wilber user can only login from within the network:

    + : root :
    + : tux :
    + : wilber :
    - : ALL : ALL

    Do not forget the last line which denies access for all other users from all sources, but be careful not to lock yourself out of the system.

    For more configuration options, refer to the examples in the file and to man access.conf.

Warning: Do not use pam-config

Do not use the pam-config utility here. It only supports pam_access as a global module. The configuration above is not suitable to be used globally for all services and can completely deny access to the system.

23.9 Port forwarding Edit source

ssh can also be used to redirect TCP/IP connections. This feature, also called SSH tunneling, redirects TCP connections to a certain port to another machine via an encrypted channel.

With the following command, any connection directed to jupiter port 25 (SMTP) is redirected to the SMTP port on sun. This is especially useful for those using SMTP servers without SMTP-AUTH or POP-before-SMTP features. From any arbitrary location connected to a network, e-mail can be transferred to the home mail server for delivery.

# ssh -L 25:sun:25 jupiter

Similarly, all POP3 requests (port 110) on jupiter can be forwarded to the POP3 port of sun with this command:

# ssh -L 110:sun:110 jupiter

Both commands must be executed as root, because the connection is made to privileged local ports. E-mail is sent and retrieved by normal users in an existing SSH connection. The SMTP and POP3 host must be set to localhost for this to work. Additional information can be found in the manual pages for each of the programs described above and in the OpenSSH package documentation under /usr/share/doc/packages/openssh.

23.10 Adding and removing public keys on an installed system Edit source

In some environments, it is convenient or necessary to log in over SSH. As such, the user needs to provide a public SSH key. To add or remove an SSH key, proceed as follows:

  1. Open YaST.

  2. Under Security and Users, open the User and Group Management module.

  3. Select the user you want to change and press Edit.

  4. Switch to the SSH Public Key tab.

  5. Add or remove your public key(s). If you add a public SSH key, look for the file extension .pub.

  6. Confirm with Ok.

Your public SSH key is saved in ~/.ssh/authorized_keys.

23.11 More information Edit source


The home page of OpenSSH


The OpenSSH Wikibook

man sshd

The man page of the OpenSSH daemon

man ssh_config

The man page of the OpenSSH SSH client configuration files

man scp , man sftp , man slogin , man ssh , man ssh-add , man ssh-agent , man ssh-copy-id , man ssh-keyconvert , man ssh-keygen , man ssh-keyscan

Man pages of several binary files to securely copy files (scp, sftp), to log in (slogin, ssh), and to manage keys.

/usr/share/doc/packages/openssh-common/README.SUSE , /usr/share/doc/packages/openssh-common/README.FIPS

SUSE package specific documentation; changes in defaults with respect to upstream, notes on FIPS mode etc.

Print this page