I may be attacking this problem the wrong way, if so let me know.

I have a server which is available through SSH from both the public internet and the local LAN. I would like to have two very different security policies for each, by running two copies of sshd with two different sshd_config files each on a different port.

Some of the things I'd like to change is to allow password or public-key authentication on the LAN, but public-key only from the internet. All (real) users could login from the LAN side, but only certain authorized users would be individually whitelisted to login through the internet.

As far as I can tell this requires having two different SSH daemons running on different ports with different sshd_configs. I am fine with the different ports part, I can easily forward port 22 to any port I want through my firewall.

So my question is what is the best way to actually START the second sshd under Ubuntu 10.04 LTS. Is there a recommended way to do something like this? Surely I am not the first person with this sort of need.

I have a bit of experience with upstart, and I can manually hack the second sshd into /etc/init/ssh.conf I suppose but I'm not sure if that will get overwritten by the package. However I do it, It's important to ensure both sshd processes always get restarted after any automatic or manual upgrade of the openssh-server package.

Thanks in advance.

  • 1
    I'm not sure if that will get overwritten by the package. Packages that follow the Debian policy will not modify anything under /etc without prompting you to resolve the conflict. If you are aware of any package that doesn't follow this policy it has a bug, and should be reported. – Zoredache Mar 8 '11 at 18:45

Start your separate SSH daemons however your operating system traditionally starts SSH daemons:

If Ubuntu is using upstart to launch sshd these days, create new upstart job that looks like the standard one, only pointing the daemon at your custom config file.

If it's using init.d & rc#.d scripts copy them and modify them as needed.

This avoids any package updates stomping on your customizations, and gives you fine-grained control over starting/stopping/restarting the specific SSH daemon you want to target. It also means that an admin stepping in to your universe will be able to recognize what's going on and how to start/stop/restart these daemons because it's done in the operating system's usual way rather than by hackery.

  • I know this is from awhile ago, I just wanted to say that this was a beautiful solution (why didn't I think of that!) and I have been using it happily ever since. – cecilkorik Nov 1 '11 at 6:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.