How to configure multiple instances of sshd in RHEL 5 or 6?

Solution Verified - Updated -


  • Red Hat Enterprise Linux (RHEL) 5
  • Red Hat Enterprise Linux 6
  • openssh-server


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


This resolution applies to Red Hat Enterprise Linux 5 or 6 only. If you want to run multiple instances of sshd on RHEL 7, please see another solution describing the same for RHEL 7.

Disclaimer: Writing init script for second instance is out of scope of work. Given below is just an example.

Running multiple instances of sshd on RHEL5/6 is supported. Follow the steps below to configure a second instance of the sshd daemon.

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

    # cp /etc/ssh/sshd_config /etc/ssh/sshd_config-second
  2. Edit the /etc/ssh/sshd_config-second file to assign a different port number and pid file. Make sure this port is not in use by any other service

    Port 5222
    PidFile /var/run/
  3. Make a symlink to the sshd binary (see RHBZ #826720) and make a copy of the sshd init script

    # ln -s /usr/sbin/sshd /usr/sbin/sshd-second
    # cp /etc/rc.d/init.d/sshd /etc/rc.d/init.d/sshd-second
  4. Find the lines below in the /etc/rc.d/init.d/sshd-second file and make the changes accordingly.

    # config: /etc/ssh/sshd_config-second
    # pidfile: /var/run/
    [ -f /etc/sysconfig/sshd-second ] && . /etc/sysconfig/sshd-second
    [ -f /etc/ssh/sshd_config-second ] || exit 6
  5. Create the /etc/sysconfig/sshd-second file with the following contents:

    OPTIONS="-f /etc/ssh/sshd_config-second"
  6. Create a separate PAM configuration file for the new sshd-second service.

    # cp /etc/pam.d/sshd /etc/pam.d/sshd-second
  7. If SELinux is enabled, on RHEL6 system, set the security context for the sshd-second service

    # semanage fcontext -a -e /etc/init.d/sshd /etc/init.d/sshd-second
    # semanage fcontext -a -e /usr/sbin/sshd /usr/sbin/sshd-second
    # semanage fcontext -a -e /etc/ssh/sshd_config /etc/ssh/sshd_config-second
    # restorecon -v /etc/init.d/sshd-second /usr/sbin/sshd-second /etc/ssh/sshd_config-second

8a. If SELinux is enabled, on RHEL5 system, instead of semanage use chcon command to change the context:

# chcon --reference=/etc/init.d/sshd /etc/init.d/sshd-second  
# chcon --reference=/usr/sbin/sshd /usr/sbin/sshd-second
# chcon --reference=/etc/ssh/sshd_config /etc/ssh/sshd_config-second 

8b. If you need to use semanage on a RHEL5 system you can use the following commands to set the context:

# semanage fcontext -a -t initrc_exec_t /etc/init.d/sshd-second  
# semanage fcontext -a -t sshd_exec_t /usr/sbin/sshd-second
# semanage fcontext -a -t etc_t /etc/ssh/sshd_config-second
# restorecon -v /etc/init.d/sshd-second /usr/sbin/sshd-second /etc/ssh/sshd_config-second 
  1. If the iptables firewall is enabled, insert a rule in the INPUT chain to open the port for the sshd-second service. In this example, the rule should be inserted at slot 9, before the reject-with icmp-host-prohibited line. (The system-config-firewall GUI tool can make this step easier on RHEL 6.)

    # iptables -L --line-numbers
    Chain INPUT (policy ACCEPT)
    num  target     prot opt source               destination
    8    ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ssh
    9    REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited
    # iptables -I INPUT 9 -m state --state NEW -m tcp -p tcp --dport 5222 -j ACCEPT
  2. Restart the sshd service and the newly created sshd-second service, and use chkconfig to start the sshd-second service on reboot.

    # service sshd restart
    # service sshd-second start
    # chkconfig --add sshd-second
  3. On the client, specify the port number with the -p option to connect to the sshd-second daemon

    # ssh user1@ipaddress -p 5222

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.


Small fix in /etc/init.d/sshd-second

# config: /etc/ssh/sshd_config-second
# pidfile: /var/run/
[ -f /etc/sysconfig/sshd-second ] && . /etc/sysconfig/sshd-second
[ -f /etc/ssh/sshd_config-second ] || exit 6

Additional Suggestion - chkconfig configuration
chkconfig --add sshd-second

An unfortunately naive solution but understandable since the original init script is of such poor quality. Move all hard-coded variables (eg. *_KEY, PID_FILE) into /etc/sysconfig/`basename $0` for starters. And then correctly apply parameters throughout. Then you can have as many instances of SSHd as you have sym- or hard links to the original.

what use cases this configuration is needed? is that for multihosting? are there any good justification to use two ssh daemons?

I would say user segregation as the main one. For example you have an sftp service running to the DMZ. For security reasons you wouldn't really want to use the same Ethernet card or share the userbase. It would be better to configure two ssh daemons, one to each card and use different PAM profiles .. Also custom services against different ports, or maybe just for auditing requirements. Not sure how you would do Multihosting as you would really be accessing the same server, unless one or both ssh daemons forced a changeroot environment.
The solution for the two daemons I went for was 'not' to symbolic link the sshd daemon, but to just create the second sshd-config file using a different port, pid file, lock file, and create a simple init file. to start/stop/etc sshd -f sshd_config-second. Wasn't really happy with the sshd init script Redhat 6 provided.

My two cents:

1) Ensure you have the two instances using different ports, I had the previous config with 22 and 1022, left it running, even with config update, the other instance couldn't start up.
2) Internal I have UsePAM yes , External I had to change to UseLogin yes
3) I had to comment out AuthorizedKeysCommand /usr/libexec/openssh/ssh-ldap-wrapper on the ext to decouple ldap.