[Bug 1674330] Re: Please consider dropping /etc/network/if-up.d/openssh-server
ChristianEhrhardt
1674330 at bugs.launchpad.net
Fri Sep 22 09:06:25 UTC 2017
Hi,
trying to get new life in bugs dormant for quite a while - in addition hte had not too much consensus before.
I'll just try to recreate the case in a virt env (as it is easy for
everyone to reproduce) in the way I understood the case - I beg your
pardon if that isn't the case you meant - please help if that is true.
# get a simple guest
$ uvt-kvm create --password=ubuntu artful-testnosshhook release=artful arch=amd64 label=daily
# gets it's IP
$ virsh domifaddr artful-testnosshhook
Name MAC address Protocol Address
-------------------------------------------------------------------------------
vnet1 52:54:00:38:7b:4e ipv4 192.168.122.236/24
# Login via SSH
$ ssh ubuntu at 192.168.122.236
# Login via Console in case network/ssh connection dies
$ virsh console artful-testnosshhook
# Initially both logins work and there is no ifupdown installed (so hooks won't be working)
ubuntu at artful-testnosshhook:~$ dpkg -S /sbin/ifup
dpkg-query: no path found matching pattern /sbin/ifup
ubuntu at artful-testnosshhook:~$ ll /sbin/ifup
ls: cannot access '/sbin/ifup': No such file or directory
# Before changing IPs we have the binds on 0.0.0.0 and :::, as well as my own active ssh connection
$ sudo netstat -apn | grep ssh
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 967/sshd
tcp 0 0 192.168.122.236:22 192.168.122.1:36062 ESTABLISHED 1043/sshd: ubuntu [
tcp6 0 0 :::22 :::* LISTEN 967/sshd
# Currently I have
$ ip addr show
2: ens3:
inet 192.168.122.236/24 brd 192.168.122.255 scope global dynamic ens3
#Thet next IP is free, so just bluntly change the IP (without up/down/dhcp this time)
$ ip addr add 192.168.122.237/24 broadcast 192.168.122.255 dev ens3
$ sudo ip addr del 192.168.122.236/24 dev ens3
Of course my ssh session is dead, ssh is still listening on all
interfaces but didn't pick up .237 as the ssh code just doesn't do so
(like IP_FREEBIND).
So let's be more fair and use dhcp to reassign (more realistic case).
# Edit the range so the current IP is no more in it and then restart (Host)
# I had a range like this <range start='192.168.122.2' end='192.168.122.200'/>
#And started with leases:
$ virsh net-dhcp-leases default
2017-09-22 10:39:55 52:54:00:38:7b:4e ipv4 192.168.122.30/24 artful-testnosshhook
# Now lets add a new range and remove the current one without brekaing the bridge (destroy/start would break it)
$ virsh net-update default add ip-dhcp-range "<range start='192.168.122.220' end='192.168.122.230'/>" --live --config
$ virsh net-update default delete ip-dhcp-range "<range start='192.168.122.2' end='192.168.122.200'/>" --live --config
# Then in the guest renew the lease and networking
# this will only ADD the new ip
$ sudo dhclient -r ens3; sudo dhclient -v ens3
# so instead do
$ sudo systemctl restart systemd-networkd
# After a few seconds we have a new IP and ssh is gone on "the old IP"
# but a login to the new one works.
# Now this might be due to restarting systemd-networkd
# It could be "too much" for the test still and its dependencies reload sshd?
# So instead wait on the renewal (feel free to reduce the expiration if you are impatient)
What I see after a while is:
1. the IP renewed
2. the connect on the old IP is dead (that is ok)
3. ssh accepts connections on the new IP (that is what we wanted with all of this right?)
I double checked that nothing restarted ssh in the background, but it is the one started an hour ago when I manually did so on the old IP.
$ ubuntu at artful-testnosshhook:~$ systemctl status sshd
● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enab
Active: active (running) since Fri 2017-09-22 07:54:25 UTC; 1h 0min ago
# New lease on new address
$ virsh net-dhcp-leases default
2017-09-22 10:49:29 52:54:00:38:7b:4e ipv4 192.168.122.223/24 artful-testnosshhook
While wanted to agree that [1] is the real way to solve this eventually it seems that the core of this feature already works withotu it. Without ifup hooks and anything else restarting ssh it accepts connections on the new IP.
This was done on Artful as there ifup is dropped.
I hope I added enough details, maybe one would co-test the same there to be sure.
[1]: https://bugzilla.mindrot.org/show_bug.cgi?id=2512
** Bug watch added: OpenSSH Portable Bugzilla #2512
https://bugzilla.mindrot.org/show_bug.cgi?id=2512
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1674330
Title:
Please consider dropping /etc/network/if-up.d/openssh-server
Status in openssh package in Ubuntu:
New
Bug description:
The /etc/network/if-up.d/openssh-server hack was introduced ten years ago [1] as a response to bug
103436. At least from today's perspective this isn't justified:
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.
The hack introduces a race: you run into connection errors after
bringing up a new interface as sshd stops listening briefly while
being reloaded. That's the reason why I looked at it, as this
regularly happens in upstream's cockpit integration tests.
Also, /etc/network/if-up.d/ isn't being run when using
networkd/netplan, i. e. in more recent Ubuntnu cloud instances. So far
this doesn't seem to have caused any issues.
I asked the original reporter of bug 103436 for some details, and to
check whether that hack is still necessary. There is actually a
proposed patch upstream [2] to use IP_FREEBIND, which is the modern
solution to listening to all "future" interfaces as well. But at least
for the majority of cases it seems to work fine without that even.
So I wonder if it's time to bury that hack?
[1] https://anonscm.debian.org/cgit/pkg-ssh/openssh.git/commit/?id=ba6b55ed6
[2] https://bugzilla.mindrot.org/show_bug.cgi?id=2512
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1674330/+subscriptions
More information about the foundations-bugs
mailing list