Running multiple sshd instances on one server - SSH

I am running a system that has a NAT firewall on it with two IP
addresses, one on the outside
internet, and one on an internal network. This is a debian stable
system.

I want to have different login criteria for the internal network
(passwords allowed) and the
external network (key based only) and different allowd user lists for
each. I conjecture that the
only way to do this is to run two instances of sshd with different
config files. Is there anything
in ssh that would prevent me from doing this? Has anyone tried this
and have any pointers
or gotcha's to look out for.

Thanks,
Stuart

On Wed, 19 Mar 2008 06:01:14 -0700 (PDT), ss11223@gmail.com wrote:
> I am running a system that has a NAT firewall on it with two IP
> addresses, one on the outside
> internet, and one on an internal network. This is a debian stable
> system.

> I want to have different login criteria for the internal network
> (passwords allowed) and the
> external network (key based only) and different allowd user lists for
> each. I conjecture that the
> only way to do this is to run two instances of sshd with different
> config files. Is there anything
> in ssh that would prevent me from doing this? Has anyone tried this
> and have any pointers
> or gotcha's to look out for.

I've run two separate sshd daemons. The instructions below,
which I've posted a few times before, pertain to RedHat-style
systems (RHEL, Fedora, CentOS, and so on). You'll have to
translate them for your debian system.

=====
I suggest the following procedure, which will give you two distinct
ssh daemons, each with its own policies. These instructions pertain
to Redhat-style systems, your file paths might vary.

Let's assume you already have ssh set up to listen on one NIC
with the policies you want. Then, without too much detail:

1. cp -p /etc/ssh/ssh_config /etc/ssh/otherssh_config
Modify the new file as necessary for the policy you want.

2. cp -p /etc/ssh/sshd_config /etc/ssh/othersshd_config
Modify the new file as necessary. Most importantly, look
at ListenAddress and Port.

3. cp -p /etc/rc.d/init.d/sshd /etc/rc.d/init.d/othersshd
Modify the new file to point to otherssh wherever
the old file pointed to ssh. This includes
executables, config files, pid files and key files, for
example.

4. cd /usr/sbin/
ln -s sshd othersshd
No changes to the executable

5. cd /etc/pam.d/
ln -s sshd othersshd
No changes to the PAM module, usually

Then when all the changes are done:
6. chkconfig --add othersshd
chkconfig --list | grep othersshd
Should be on in levels 2345
service othersshd start
This should create a new set of keys.

One drawback to this scheme: if you ever update ssh, it might change
the config files or sshd init file, but it won't touch the
otherssh files.
=====

--
Dale Dellutri (lose the Q's)

>
> I've run two separate sshd daemons. The instructions below,
> which I've posted a few times before, pertain to RedHat-style
> systems (RHEL, Fedora, CentOS, and so on). You'll have to
> translate them for your debian system.
>
> =====
> I suggest the following procedure, which will give you two distinct
> ssh daemons, each with its own policies. These instructions pertain
> to Redhat-style systems, your file paths might vary.
>
> Let's assume you already have ssh set up to listen on one NIC
> with the policies you want. Then, without too much detail:
>
> 1. cp -p /etc/ssh/ssh_config /etc/ssh/otherssh_config
> Modify the new file as necessary for the policy you want.
>
> 2. cp -p /etc/ssh/sshd_config /etc/ssh/othersshd_config
> Modify the new file as necessary. Most importantly, look
> at ListenAddress and Port.
>
> 3. cp -p /etc/rc.d/init.d/sshd /etc/rc.d/init.d/othersshd
> Modify the new file to point to otherssh wherever
> the old file pointed to ssh. This includes
> executables, config files, pid files and key files, for
> example.
>
> 4. cd /usr/sbin/
> ln -s sshd othersshd
> No changes to the executable
>
> 5. cd /etc/pam.d/
> ln -s sshd othersshd
> No changes to the PAM module, usually
>
> Then when all the changes are done:
> 6. chkconfig --add othersshd
> chkconfig --list | grep othersshd
> Should be on in levels 2345
> service othersshd start
> This should create a new set of keys.
>
> One drawback to this scheme: if you ever update ssh, it might change
> the config files or sshd init file, but it won't touch the
> otherssh files.
> =====
>
> --
> Dale Dellutri (lose the Q's)

Thanks. The procedure you gave is about what I thought to do except
I didn't think that is was necessary to copy the executable to another
name first.

Stuart

On Thu, 20 Mar 2008 07:49:53 -0700 (PDT), ss11223 wrote:
> >
> > I've run two separate sshd daemons. The instructions below,
> > which I've posted a few times before, pertain to RedHat-style
> > systems (RHEL, Fedora, CentOS, and so on). You'll have to
> > translate them for your debian system.
> >...[snipped]...

> Thanks. The procedure you gave is about what I thought to do except
> I didn't think that is was necessary to copy the executable to another
> name first.

First, some of the subroutines in the startup script depend on the
executable name being the same as the service name. Second, if you
do a "ps" or something else that shows statistics by process, it will
be possible to know which ssh daemon is which. Third, having a new
name gives a consistent naming scheme to all components of the new
(RedHat-style) service.

Of course, Debian may have different requirements.

--
Dale Dellutri (lose the Q's)

On Thu, 20 Mar 2008 07:49:53 -0700 (PDT) ss11223 wrote:

| Thanks. The procedure you gave is about what I thought to do except
| I didn't think that is was necessary to copy the executable to another
| name first.

It's not exactly required, but it is a good idea. It keeps processes well
identified, for example. In many cases, the distinction is by inode, so
making a hardlink is not as good as a full copy.

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2008-03-28-1408@ipal.net |
|------------------------------------/-------------------------------------|

On 2008-03-19, ss11223@gmail.com wrote:
> I am running a system that has a NAT firewall on it with two IP
> addresses, one on the outside
> internet, and one on an internal network. This is a debian stable
> system.
>
> I want to have different login criteria for the internal network
> (passwords allowed) and the
> external network (key based only) and different allowd user lists for
> each. I conjecture that the
> only way to do this is to run two instances of sshd with different
> config files.

Depending on how modern the OpenSSH version is, you can use the Match
directive to do that in a single instance.

PasswordAuthentication no
# plus all other auth types such as ChallengeResponse and
# KbdInteractive...
Match Address 192.168.0.*
PasswordAuthentication yes


> Is there anything in ssh that would prevent me from doing this?

No.

> Has anyone tried this
> and have any pointers or gotcha's to look out for.

Make them use different config files, and make sure you set PidFile
to point to some place different. Use BindAddress to have them listen
on different interfaces, or run one on a different port and NAT
external traffic to that port.

--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.