How to configure multiple instances of sshd in RHEL 7 or 8?

Solution Verified - Updated -


  • Red Hat Enterprise Linux 7
  • Red Hat Enterprise Linux 8
  • openssh-server


How to configure multiple instances of sshd in Red Hat Enterprise Linux 7 or 8? Is that supported?


This resolution applies to Red Hat Enterprise Linux 7 or 8. If you want to run multiple instances of sshd on RHEL 5 or RHEL 6, please see How to configure multiple instances of sshd in RHEL 5 or 6? describing the same for these RHEL versions.

Running multiple instances of sshd on RHEL7 or 8 is supported. Follow the steps below to configure a second instance of sshd:

  1. Make a copy of the sshd_config file (to be used by the second daemon).

    # cp /etc/ssh/sshd{,-second}_config
  2. Edit sshd-second_config to assign a different port number. Use Port keyword to achieve that. See sshd_config(5) for documentation on these keywords. Make sure this port is not in use by any other service.

    Port 22220
  3. Make a copy of the systemd unit file for the sshd service.

    # cp /usr/lib/systemd/system/sshd.service  /etc/systemd/system/sshd-second.service   
  4. Alter /etc/systemd/system/sshd-second.service in the following way:

    • Modify Description

      Description=OpenSSH server second instance daemon
    • Add the -f /etc/ssh/sshd-second_config option to sshd, so that the alternative configuration file is used

      ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS

      Note: The ExecStart line may differ, depending on the RHEL sub-release. Keep the rest of the line as is.

  5. If using SELinux, add the port for the second instance of sshd to SSH ports, otherwise the second instance of sshd will be rejected to bind to the port:

    # yum -y install policycoreutils-python
    # semanage port -a -t ssh_port_t -p tcp 22220
  6. Run a reload so that systemd can pick up the changes:

    # systemctl daemon-reload
  7. Start sshd-second.service and enable the service, so that it starts automatically upon boot:

    # systemctl enable sshd-second.service --now
    Created symlink from /etc/systemd/system/ to /etc/systemd/system/sshd-second.service.

Diagnostic Steps

Whether the second sshd instance is started, can be checked with systemctl:

# systemctl status sshd-second.service
sshd-second.service - OpenSSH server second instance daemon
   Loaded: loaded (/etc/systemd/system/sshd-second.service; enabled)
   Active: active (running) since Mon 2014-08-18 12:58:25 CEST; 1s ago
 Main PID: 4799 (sshd)
   CGroup: /system.slice/sshd-second.service
           `-4799 /usr/sbin/sshd -D -f /etc/ssh/sshd-second_config

Aug 18 12:58:25 server systemd[1]: Starting OpenSSH server second instance daemon...
Aug 18 12:58:25 server systemd[1]: Started OpenSSH server second instance daemon.
Aug 18 12:58:25 server sshd[4799]: Server listening on port 22220.
Aug 18 12:58:25 server sshd[4799]: Server listening on :: port 22220.

Users can login from a client using the -p option of ssh:

$ ssh -p 22220 user@server

If firewall is in use, please make sure that it is configured appropriately in order to allow connections to the second instance of sshd.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.


Hi, why do you suggest putting the new unit file in /usr/lib/systemd/system? I would have thought /etc/systemd/system or some other "obviously not from the OS" location would have been better. As suggested by

Hi, correct. We are about to rework this kbase. Also some other code snippets here like the example service file are no longer applicable to openssh as of rhel7.4.

Doesn't work. I am NOT running selinux but Red Hat Enterprise Linux Server release 7.4 (Maipo) so can't run semanage as described above.

-- Unit sshd-admin.service has begun starting up. sshd[18895]: error: Bind to port 22220 on failed: Permission denied. sshd[18895]: error: Bind to port 22220 on :: failed: Permission denied. sshd[18895]: fatal: Cannot bind any address.

We are about to modify some pieces of this kbase, but as I just verified on a fresh rhel7.4 with disabled selinux, the above instructions should work. In your case, executing "/usr/sbin/sshd -D -f /etc/ssh/sshd-admin_config -dd" as root might give further hints on the issue. To look at this with more details, please open a case and supply a sosreport.

I am having similar issues with the error as indicated above. Running with -dd does not indicate any reason for failure. Any tips to try to resolve?

I would run "ss -tulpen|grep <your-port" or "lsof -n" to find out if something is already listening, or wrap the "/usr/sbin/sshd[..]" in "strace -f -o /tmp/logg [sshd command]" to find out more.

Hi, there is a mistake to make the second sshd daemon keeping switch up and down. The error is in /etc/systemd/system/sshd-second.service. ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS <<< The -D option will make it does not become a daemon. The statement is in the man page of sshd -D When this option is specified, sshd will not detach and does not become a daemon. This allows easy monitoring of sshd.

Hello, Which RHEL7 subrelease are you trying to configure? With RHEL7.5 at least, the sshd.service unit is of type Notify hence sshd is not daemonized:

# cat /usr/lib/systemd/system/sshd.service
ExecStart=/usr/sbin/sshd -D $OPTIONS

Hi, My RHEL7 subrelease is 7.3. The content of /usr/lib/systemd/system/sshd.service is [Service] Type=forking PIDFile=/var/run/ Do you mean we need to remove the -D option if the OS version is before 7.5?

Yes. In fact, keep the actual line and just add -f /etc/ssh/sshd-second_config

I updated the solution accordingly (added a Note)

It would've been cooler if the sshd unit was as flexible as the openvpn unit. With the openvpn unit you can start multiple daemons by providing a config file with e.g. openvpn@home.udp and openvpn@home.tcp, which then starts openvpn with 2 different configs. Much more manageable than this solution described here. It of course requires changes to the sshd unit file to conform to this method. But that can be a distribution decision.

Hi, I have created 2nd sshd_1131.service which is communicating on 1131 port. I wanted to make it EAP authentication as per pam.d dir rules..can you please help me out.. (Note - EAP authentication should be on 1131 port not on 22).

Other solutions to this issue that can be found on the internet tell you to just put multiple "Port" lines in /etc/ssh/sshd_config and restart the service. Despite being more involved, I like the solution presented here better.

Any ideas about pros and cons of that solution vs the one described here ?

I needed to run an SFTP service from a less trusted network. I'd rather have a totally separate service (sshd instance) for that purpose than to share the same sshd instance used for administration of the system with it.

I believe this solution provides better segmentation, for security reasons, than having the built-in sshd listening on multiple ports.

This doesn't mention updating firewalld.

Can I suggest that something like the following is added?

To allow access to the second ssh service, ensure the firewall allows incoming connections. Note that this is only a basic allow-all rule and you may wish to use zones or rich rules for better control.

firewall-cmd --permanent --add-port=22220/tcp


firewall-cmd --reload


Wouldn't it be better to change steps #3 and #4 so that the systemd unit file is updated with sshd package updates? Otherwise you have a static copy forever.

I'd suggest something like:

  1. ln -s /usr/lib/systemd/system/sshd.service /usr/lib/systemd/system/sshd-second.service
  2. systemctl edit sshd-second.service In the editor add five lines (this example is from RHEL8 which has a $CRYPTO_OPTIONS argument not found in RHEL7)
Description=Second OpenSSH server daemon

ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS $CRYPTO_POLICY

PS: Never mind this sadly doesn't work!

systemd complains that 'sshd.service: Service has more than one ExecStart= setting, which is only allowed for Type=oneshot services. Refusing.' As soon as we make a full copy of the unit file we're maintaining our own copy again anyway, so the benefit of making a link is lost.

You have another issue here, when you create a symbolic link, you actually have the same configuration for both instances. When you change one configuration, you also change the other one.

Thanks for clarifying that.

I had hoped that I could get away with it by putting an override in for one copy, but it's not possible.