Running Two SSH Daemons (SysV Init)

These are the instructions for running two SSH daemons in a SysV Init server distro, Redhat-style (RHEL, CentOS, and Scientific Linux). Click here if you need the instructions for a Systemd distro.

THE FOLLOWING IS OFFERED WITHOUT WARRANTY OF ANY KIND. THIS IS WHAT I DID, BUT YOU MAY NEED TO DO SOMETHING DIFFERENT. YOU ARE RESPONSIBLE FOR ALL CHANGES TO YOUR SYSTEM. IF IT BREAKS, YOU GET TO FIX IT.

You may need to horizontally scroll the code boxes shown below.

I started with a single SSH daemon set up to listen only on the lan NIC. Then:

I copied the sshd_config file, and modified the new file as necessary for the policy I wanted. Wherever the old file mentioned ssh<whatever>, I changed it to otherssh<whatever>. I also changed Port, ListenAddress, and other variables. I made sure that the original file only listened on the lan NIC.
```
# cd /etc/ssh
# cp -p sshd_config othersshd_config
```
I copied the init script, and modified the new file to point to otherssh<whatever> wherever the old file pointed to ssh<whatever>.
```
# cd /etc/rc.d/init.d
# cp -p sshd othersshd
```
I created a soft link to the executable SSH daemon.
```
# cd /usr/sbin/
# ln -s sshd othersshd
```
I created a soft link to the PAM module. I didn't need to make any changes to this file. If you need to change the PAM module you should copy it instead, then modify the new file.
```
# cd /etc/pam.d/
# ln -s sshd othersshd
```
When the changes were done, I added the new SSH daemon to the service list and started it. The grep below showed that the service was on in runlevels 2345. Starting the service created a new set of keys as defined in the HostKey lines in othersshd_config.
```
# chkconfig --add othersshd
# chkconfig --list | grep othersshd
# service othersshd start
```

There is a drawback to this scheme: if a system software update changes any of the ssh config or init files, I have to manually make similar changes to the files I've copied and modified.

I've been asked why I needed to make a new init file and a new soft link to the executable. There are three reasons. First, some of the subroutines in the init script depend on the executable name being the same as the service name. Second, when I do a "ps" or something else that shows statistics by process, I'd be able to tell which ssh daemon is which. Third, having a new name gives a consistent naming scheme to all components of the new (RedHat-style) service.

Web site comments, criticisms and complaints: E-mail: Dale Dellutri .
Copyright 2020 Dale A. Dellutri
Last modified: Saturday, 09-May-2020 16:16:34 EDT