Hi Laszlo. I use sshd under supervise/svscan, (from the qmail and
tcpserver guy,) and use:
#!/bin/sh
exec env - PATH="$PATH:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin" \
tcpserver -R -v -x /my_access_directory/tcp.ssh.cdb -u 0 -g 0 0 ssh sshd -i 2>&1
in the "run" file. Works fine. (The X11 path is needed for sshd's X
forwarding option authentication.)
Svscan/supervise will keep the process running, and restart it if it
dies. Svscan/supervise has its own logging mechanism that is much more
machine efficient and faster than syslog, so you can tell if script
kiddie was hitting on port 22.
John
BTW, I would recommend that you move ssh's ports to above the
privileged ports, 1024, as an option in ssh's config files, and
tcpserver comes highly recommended, (it is DoS attack resistant.)
Laszlo Vecsey writes:
> I've been wondering about the 'sshd1 -i' option for calling from
> inetd and specifically the man page reference to the lengthy key
> generation process:
>
> -i Specifies that sshd is being run from inetd. Sshd
> is normally not run from inetd because it needs to
> generate the server key before it can respond to
> the client, and this may take tens of seconds.
> Clients would have to wait too long if the key was
> regenerated every time. However, with small key
> sizes (e.g. 512) using sshd from inetd may be feas
> sible.
>
> A co-worker of mine tells me that he likes to run it from inetd because of
> the added security of having a key generated each time.
>
> Personally, I can't stand inetd and avoid it at all costs -- being a fan
> of qmail, if I really had to run sshd1 -i then I would wrap it under
> tcpserver and live with that. My hunch though is that generating the key
> too often is actually a bad thing when you consider that most computers
> don't have a good source of randomness. So generating keys too often will
> actually help the attacker. Is that correct?
>
> Comments appreciated. Are both issues (key generation and inetd/tcpserver)
> moot points / insignificant? And the ability for sshd as a daemon on its
> own to gracefully defer connections if there are too many, which I imagine
> it does, plus any other issues there may be. Thanks.
>
> Bottom of this page describes tcpserver vs inetd:
>
> http://cr.yp.to/ucspi-tcp.html
>
--
John Conover Tel. 408.370.2688 [EMAIL PROTECTED]
631 Lamont Ct. Cel. 408.772.7733
Campbell, CA 95008 Fax. 408.379.9602 http://www.johncon.com
