ssh init script doesn't use the /etc/default/ssh file

apport information

In the /etc/init/ssh.conf:

# if you used to set SSHD_OPTS in /etc/default/ssh, you can change the
# 'exec' line here instead

Wishlist!!? This a bug!!

Why the openssh-server package installs the /etc/default/ssh file then?
Moreover, in the /etc/default/ssh file doesn't explain nothing about this.
I was used to modify the /etc/default/ssh file not the /etc/init/ssh.conf
I lost many hours trying to start my ssh server in IPv4 mode because you have changed the default behavior!! :-(

/etc/default/ssh (and, for that matter, /etc/init.d/ssh) is at this
point only provided because Upstart can't yet manage jobs in chroots.
When it can, I expect that these will be removed.

This is not just a wishlist. The package as it is now breaks expected behaviour
(the one you get after 15 years of using /etc/init.d style startup scripts)
and is not properly documented in the obvious places (README.Debian, for example), with only a mention of
this new behaviour buried in changelog.Debian.gz.

Furthermore, and most importantly, the daemon behaves differently if you
start it with old style init scripts, or with new style upstart commands:

# cat /etc/default/ssh | grep -v '#'
SSHD_OPTS='-p 11210'
SSHD_OOM_ADJUST=-17
# service ssh start
ssh start/running, process 23950
# lsof -n | grep LISTEN | grep ssh
sshd 23950 root 3u IPv4 24579273 0t0 TCP *:ssh (LISTEN)
sshd 23950 root 4u IPv6 24579275 0t0 TCP *:ssh (LISTEN)
# service ssh stop
ssh stop/waiting
# /etc/init.d/ssh start
 * Starting OpenBSD Secure Shell server sshd [ OK ]
# lsof -n | grep LISTEN | grep ssh
sshd 23983 root 3u IPv4 24589208 0t0 TCP *:11210 (LISTEN)
sshd 23983 root 4u IPv6 24589210 0t0 TCP *:11210 (LISTEN)

This means that someone changing the configuration and restarting the daemon "the old way" will not find the daemon listening
on the inteded port after a reboot.

The old style startup script should be modified to output a message
urging the user to change his habit to upstart commands.

The /etc/default/ssh file should be modified to include a prominent warning
that the file itself is deprecated and not used by upstart anymore.

The package as it is now may cause a machine to become unreachable if an
external firewall is configured to allow a certain non-standard port, while
the daemon starts listening on 22 because /etc/default/ssh is not used anymore.

Pf

Pierfrancesco Caci, I'm agree with you but if the other services in Ubuntu still using the "old style" init scripts, why only ssh has changed to new style? and, more important, why it conserves the old init script?

Colin Watson, if Upstart can't yet manage jobs in chroots, why you has changed the behaviour now? Why don't to wait to Upstart is complete?

Colin, I did more tests and here's another issue:

sshd is stopped, and the 2 config files have these contents:

# grep -v '#' /etc/default/ssh
SSHD_OPTS='-p 12345'
SSHD_OOM_ADJUST=-17

 # tail -1 /etc/init/ssh.conf
exec /usr/sbin/sshd -p 11210

# service ssh start
ssh start/running, process 30569

# ps ax | grep sshd
30569 ? Ss 0:00 /usr/sbin/sshd -p 11210

# /etc/init.d/ssh start
 * Starting OpenBSD Secure Shell server sshd [ OK ]

# ps ax | grep sshd
30569 ? Ss 0:00 /usr/sbin/sshd -p 11210

so far, this is the expected behaviour. Now I stop again the daemon, and start it again, but this time with the old style init script first

# /etc/init.d/ssh start
 * Starting OpenBSD Secure Shell server sshd [ OK ]

# ps ax | grep sshd
31604 ? Ss 0:00 /usr/sbin/sshd -p 12345

# service ssh start
ssh start/running, process 31614

# ps ax | grep sshd
31604 ? Ss 0:00 /usr/sbin/sshd -p 12345
31614 ? Ss 0:00 /usr/sbin/sshd -p 11210

Result: 2 daemons running, on different ports.

Also, the init script is no longer able to stop the daemon it started:

# service ssh stop
ssh stop/waiting

# ps ax | grep sshd
31604 ? Ss 0:00 /usr/sbin/sshd -p 12345

# /etc/init.d/ssh stop
 * Stopping OpenBSD Secure Shell server sshd [ OK ]

# ps ax | grep sshd
31604 ? Ss 0:00 /usr/sbin/sshd -p 12345

Pf

On Sat, Jul 17, 2010 at 12:22:34PM -0000, Simon wrote:
> Colin Watson, if Upstart can't yet manage jobs in chroots, why you has
> changed the behaviour now? Why don't to wait to Upstart is complete?

Because other functionality written as Upstart jobs depends on ssh.