topic Re: SSH under inetd in Operating System - HP-UX

SSH under inetd

John Payne_2 — Tue, 27 Nov 2001 20:54:03 GMT

I am about to start what will problibly a fight here over bringing ssh under inetd. We are currently running it by itself, with the sshd running all the time. We are restricting access with /etc/hosts.allow and /etc/hosts.deny (tcpwrappers.) I want to put ssh in inetd.conf and restrict via /var/adm/inetd.sec My argument is that inetd is almost ALWAYS available, and the service will be started as needed. Then we can trust ssh to be there like we have trusted telnet and ftp to be there. It also makes a single point of management with the inetd.sec file.

My question is this: Does anyone have a success story or a disaster story to share regarding this? Any reason not to do this? I really can't think of one myself.

Re: SSH under inetd

harry d brown jr — Tue, 27 Nov 2001 20:59:16 GMT

John,

That's a damn good place to put it, because if you needed to shut off network access, you could do it just by stopping inetd, instead of multiple services. Any other justification needed?

live free or die
harry

Re: SSH under inetd

Marco Paganini — Tue, 27 Nov 2001 21:00:28 GMT

Hello John,

To be honest, I never had my sshd crashing. Anyway, if you have a large number of SSH connections, you may be able to save some startups by leaving the daemon running. If you use SSH sparingly, you can just put it on inetd (however, as I've said, I see no advantage on doing that).

Regards,
Paga

Re: SSH under inetd

Craig Rants — Tue, 27 Nov 2001 21:05:48 GMT

John,
I've been running SSH for about 3 years and have never put it under inetd. Doesn't mean I have a good reason not to. I don't think I have ever had the daemon die, which does not mean it never does.

Also some versions of ssh allow you to control access with the AllowHosts option in the sshd_config file, it works much the same as inetd.conf.

I don't think it matters, do what you think is best for you guys.

Good Luck,
C

Re: SSH under inetd

G. Vrijhoeven — Tue, 27 Nov 2001 21:05:54 GMT

Hi,

I think you should go for your plan. It is save and does not run sshd if it is not needed.

Gideon

Re: SSH under inetd

Bernie Vande Griend — Tue, 27 Nov 2001 21:12:44 GMT

I think it makes sense to have it in inetd, so you can take advantage of inetd.sec and only have it running when needed.
The only reasons I can think of for not using inetd: SSH was probably not written with the intention of running in inetd in mind, so its possible that you could have some problems. (But I can't think of any at the moment.) Also, if you have a large number of SSH connections, then it is probably more efficient and quicker to just having the sshd running all the time. I don't know of too many situations where that would be the case.

I too have never had an issue with sshd failing. However if its in inetd then you don't have to monitor a separate daemon nor worry about if it does fail.

Re: SSH under inetd

Sridhar Bhaskarla — Tue, 27 Nov 2001 21:14:28 GMT

John,

One of the reasons why one wouldn't start sshd through inetd is because it needs to generate the server key everytime it starts through inetd. And this will take time. However it may be ok if smaller key sizes are fine with you.

You need to make sure you add -i option. It tells sshd that it is being invoked by inetd.

-Sri

Re: SSH under inetd

Sridhar Bhaskarla — Tue, 27 Nov 2001 21:17:53 GMT

I am damn sure my message was not even clear to me.

The reason why sshd is barred running from inetd is because everytime a client connects to it, it needs to generate a key unlike the standalone one that generates it only once and then every hour.

-Sri

Re: SSH under inetd

John Payne_2 — Tue, 27 Nov 2001 21:31:12 GMT

We are talking here about not very many users ever logging in, and never more than a couple at a time. These machines are A500's or better, I am not really worried about waiting for the key. (The wait is not really noticable). Being a University, people are kind of paranoid about security, and I am tired of having two places to manage....