godot
01-04-2001, 04:08 PM
I use debian (woody) but instead of apt-getting ssh I compiled it. I had a heck of a time getting it to run on boot. Just today I noticed a folder /etc/rc.boot and I decided to try a symbolic link in that folder to the sshd binary. My bet payed off and it now works.
This may seem like a lame "How I Did It" story but hopefully it will help someone who has been working at this for months. Did I say months! I meant days.... hours...... a couple minutes. DOH!
Craig McPherson
01-12-2001, 12:31 AM
Alternate, more "standard" solutions:
If you want to run SSHD from your inetd server rather than as a standalone server (this is a good way to save memory if you'll be accepting SSH connections only occasionally -- the daemon is only started when a connection comes in, which makes the connection take a split second longer to establish, but saves memory when there's no active SSH connection), just add an entry for it to your inetd configuration file.
For the standard inetd, in your inetd.conf:
ssh stream tcp nowait root /usr/sbin/sshd
(Adjust path accordingly, make sure "ssh" is in your /etc/services)
For xinetd, which cool people use, in your xinetd.conf:
service ssh
{
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/sshd
}
Restart your inetd program after changing its configuration file.
The ssh program on my system claimed it needed to be passed the "-i" flag to be run from inetd, but that wasn't my experience. If it's required with your version of ssh, just add -i to the inetd.conf, or the line "server_args = -i" to your xinetd.conf.
If you want to run your sshd as a standalone daemon, you should make an init script for it in /etc/init.d. A very simple /etc/init.d/ssh could be just this:
#!/bin/sh
/usr/sbin/sshd&
Of course, if you were going to do something that simple, you might as well just call your init script "/etc/init.d/local", and add any other commands that you want run at bootup to it.
Then you just go to the init directory for the runlevel you boot into (check /etc/inittab for this), ie /etc/rc2.d for runlevel 2. Now create a symlink there pointing to your init script, and call it something like "S90local" or "S90ssh". It has to start with a capital S, and the number following that determines when during the boot process the script should be run.
A more complex init script would be something like this, from the Debian SSH package:
#! /bin/sh
# /etc/init.d/ssh: start and stop the OpenBSDh "secure shell(tm)" daemon
test -x /usr/sbin/sshd | | exit 0
( /usr/sbin/sshd -\? 2>&1 | grep -q OpenSSH ) 2>/dev/null | | exit 0
# forget it if we're trying to start, and /etc/ssh/NOSERVER exists
if expr "$1" : '.*start$' >/dev/null && [ -e /etc/ssh/NOSERVER ]; then
echo "Not starting OpenBSD Secure Shell server (/etc/ssh/NOSERVER)"
exit 0
fi
# Configurable options:
case "$1" in
start)
test -f /etc/ssh/sshd_not_to_be_run && exit 0
echo -n "Starting OpenBSD Secure Shell server: sshd"
start-stop-daemon --start --quiet --pidfile /var/run/sshd.pid --exec /usr/sbin/sshd
echo "."
;;
stop)
echo -n "Stopping OpenBSD Secure Shell server: sshd"
start-stop-daemon --stop --quiet --oknodo --pidfile /var/run/sshd.pid --exec /usr/sbin/sshd
echo "."
;;
reload|force-reload)
echo -n "Reloading OpenBSD Secure Shell server's configuration"
start-stop-daemon --stop --signal 1 --quiet --oknodo --pidfile /var/run/sshd.pid --exec /usr/sbin/sshd
echo "."
;;
restart)
echo -n "Restarting OpenBSD Secure Shell server: sshd"
start-stop-daemon --stop --quiet --oknodo --pidfile /var/run/sshd.pid --exec /usr/sbin/sshd
sleep 10
start-stop-daemon --start --quiet --pidfile /var/run/sshd.pid --exec /usr/sbin/sshd
echo "."
;;
*)
echo "Usage: /etc/init.d/ssh {start|stop|reload|force-reload|restart}"
exit 1
esac
exit 0
Then symlink it as before.
Anyway, what you did broke a number of Linux and Unix standards. The Linux Standards Base people aren't going to come to your door with a gun, but you might run into problems down the line.
1. Symlinks in the various rc boot directories (rc.boot, rcS.d, rc0-6.d) can't point directly to binaries. They have to point to scripts, which generally in turn start binaries. Of course, nothing will break if you do this but it violates the standards.
2. You shouldn't use rc.boot. I believe its use is deprecated and is only for backwards compatibility while programs finish switching over to the standards. rc.boot will probably be removed at some point. Use the normal runlevel rc directories (rc2.d through rc5.d) for normal stuff, rcS.d for stuff that will be started in EVERY runlevel, even single user mode (stuff like SSH should NOT start in single user mode), rc0.d and rc6.d should be used for stuff that needs to be run when shutting down or rebooting.
Clear enough?
------------------
http://users.ipa.net/~cmcpher/paminv.gif DEBIAN (http://www.debian.org/) http://users.ipa.net/~cmcpher/paminv.gif
It turns girls into statues!
[This message has been edited by Craig McPherson (edited 11 January 2001).]
Sterling
01-12-2001, 06:20 PM
I think that the -i option for sshd running from inetd is more of an information thing than anything else. It lets sshd optimize some things to work better with inetd, although the man page is quite unclear about this. I've got mine running from inetd just to be able to use the tcpd wrappers with it. (VERY handy for access control)
------------------
-Sterling
"There is no Linuxnewbie.org cabal..."
Craig McPherson
01-12-2001, 07:11 PM
Thanks for the info.
When I tried running ssh from inetd, it flat-out would not work when I passed it the -i flag.
This was with xinetd rather than the normal inetd, but from the point of view of the programs they call, they should be exactly the same.
TCP Wrappers... bah... I use my firewall for access control. http://www.linuxnewbie.org/ubb/smile.gif