sshd not reconfigured by /etc/network

Colin Watson <email address hidden> writes:
> ** Changed in: openssh (Ubuntu)
> Importance: Undecided => Wishlist
> Status: Unconfirmed => Confirmed

FYI, this need not stay "wishlist" for long -- it will take
less than five minutes to actually add ssh.

Just to make it clear:

in /etc/network/if-up.d, place a file named "ssh" saying this or a
slight variant:

----------------------------------------------------------------------
#!/bin/sh

case $ADDRFAM in
        inet*)
                if [ -x "/etc/init.d/ssh" ]; then
                        /etc/init.d/ssh restart || exit $?
                fi
                ;;
esac
----------------------------------------------------------------------

This really will take no time. Please fix it -- it will make the world
a better place and close an open bug.

Perry

Well, I can tell for a start that the above isn't right because what if
sshd isn't running? That's why I didn't just fix it on the spot, because
it isn't entirely trivial and I wanted to think about it a bit.

Colin Watson <email address hidden> writes:
> Well, I can tell for a start that the above isn't right because what if
> sshd isn't running?

Then no real harm is caused -- but several of the other scripts in
network happily test for this sort of thing already.

Here is how to do it. The test you are looking for is to check if
/var/run/sshd.pid is there, and if so, if the running process is in
fact sshd, which is done by checking /proc/pid/exe.

if [ -f /var/run/sshd.pid ]
then
    if [ -h /proc/$(cat /var/run/sshd.pid)/exe ]
    then
        NAME=$(ls -l /proc/$(cat /var/run/sshd.pid)/exe | sed 's/^.*\///' )
        if [ $NAME = "sshd" ]
        then
            /etc/init.d/sshd restart
        fi
    fi
fi

This is straightforward. (You should of course test the code.)

> That's why I didn't just fix it on the spot, because it isn't
> entirely trivial and I wanted to think about it a bit.

Well, the code to do what you want is above.

See also bug #120199 if you fix the above one.

Feel free to bother me if you need any more shell magic like the stuff
above written.

Perry

I did it differently in the end (you can make better use of the init script than that; reload does the job with less messing around), but thanks for the help anyway.

openssh (1:4.6p1-2) unstable; urgency=low

  * Fix ordering of SYSLOG_LEVEL_QUIET and SYSLOG_LEVEL_FATAL.
  * Clarify that 'ssh -q -q' still prints errors caused by bad arguments
    (i.e. before the logging system is initialised).
  * Suppress "Connection to <host> closed" and "Connection to master closed"
    messages at loglevel SILENT (thanks, Jaap Eldering; closes: #409788).
  * Suppress "Pseudo-terminal will not be allocated because stdin is not a
    terminal" message at loglevels QUIET and SILENT (closes: #366814).
  * Document the SILENT loglevel in sftp-server(8), ssh_config(5), and
    sshd_config(5).
  * Add try-restart action to init script.
  * Add /etc/network/if-up.d/openssh-server to restart sshd when new
    interfaces appear (LP: #103436).
  * Backport from upstream:
    - Move C/R -> kbdint special case to after the defaults have been
      loaded, which makes ChallengeResponse default to yes again. This was
      broken by the Match changes and not fixed properly subsequently
      (closes: #428968).
    - Silence spurious error messages from hang-on-exit fix
      (http://bugzilla.mindrot.org/show_bug.cgi?id=1306, closes: #429531).

 -- Colin Watson <email address hidden> Wed, 20 Jun 2007 11:52:44 +0100

Perry, I just revisited this:

 - /etc/network/if-up.d/openssh-server hack introduces a race (you run into connection errors after bringing up a new interface as sshd stops listening briefly while being reloaded).

 - I can't seem to be able to actually reproduce that issue: I can start a VM with no network interfaces, remove the above hack, then start sshd, then bring up an ethernet interface, and I can connect to ssh via ethernet just fine. Also, e. g. Fedora has no counterpart of this hack, and these days a lot of people would complain if that would cause problems, as hotpluggable/roaming network devices are everywhere.

 - /etc/network/if-up.d/ isn't being run when using networkd/netplan, thus in our cloud instances. So far this doesn't seem to have caused any issues.

So my questions:

  (1) Can you please describe more precisely what exactly you did back then? Do you have a nonstandard SSH configuration with some ListenAddresses/AddressFamily restrictions or similar?

  (2) Can you please disable the hack (sudo chmod 0 /etc/network/if-up.d/openssh-server) and check if your use case works without it?

Thanks!

I filed bug 1674330 about dropping the hack.

On Mon, 20 Mar 2017 13:18:54 -0000 Martin Pitt
<email address hidden> wrote:
> Perry, I just revisited this:

That bug report was a decade ago.

So far as I know, this is still an issue for your users, because sshd
does not, on its own, change its network address when one changes
networks. I would not remove this because if you remove it you're
going to harm anyone who changes addresses frequently.

However, I have not used Ubuntu in many years (this is 2017, the bug
report was 2007) and I am no longer in a position to help you.

Perry
--
Perry E. Metzger <email address hidden>

Hey Perry,

Perry E. Metzger [2017-03-20 13:11 -0400]:
> That bug report was a decade ago.

Yeah, I know :-)

> So far as I know, this is still an issue for your users, because sshd
> does not, on its own, change its network address when one changes
> networks. I would not remove this because if you remove it you're
> going to harm anyone who changes addresses frequently.

That's what I've thought, but it am puzzled that I cannot actually produce this
situation (when removing the script). That, and the fact that Fedora or SUSE
don't have this indicate that this was dealt with by something else in the
meantime.

> However, I have not used Ubuntu in many years (this is 2017, the bug
> report was 2007) and I am no longer in a position to help you.

No worries, it was a long shot anyway. Thanks for your fast response!

Martin