[Bug 2020560] Re: ssh.service and ssh.socket both running.
Launchpad Bug Tracker
2020560 at bugs.launchpad.net
Wed Jul 12 20:04:14 UTC 2023
This bug was fixed in the package openssh - 1:9.3p1-1ubuntu1
---------------
openssh (1:9.3p1-1ubuntu1) mantic; urgency=medium
* Merge with Debian unstable (LP: #2025664). Remaining changes:
- debian/rules: modify dh_installsystemd invocations for
socket-activated sshd
- debian/openssh-server.postinst: handle migration of sshd_config options
to systemd socket options on upgrade.
- debian/README.Debian: document systemd socket activation.
- debian/patches/socket-activation-documentation.patch: Document in
sshd_config(5) that ListenAddress and Port no longer work.
- debian/openssh-server.templates: include debconf prompt explaining
when migration cannot happen due to multiple ListenAddress values
- debian/.gitignore: drop file
- debian/openssh-server.postrm: remove systemd drop-ins for
socket-activated sshd on purge
- debian/openssh-server.ucf-md5sum: update for Ubuntu delta
- debian/openssh-server.tmpfile,debian/systemd/ssh.service: Move
/run/sshd creation out of the systemd unit to a tmpfile config so
that sshd can be run manually if necessary without having to create
this directory by hand.
- debian/patches/systemd-socket-activation.patch: Fix sshd
re-execution behavior when socket activation is used
- debian/tests/systemd-socket-activation: Add autopkgtest for systemd socket
activation functionality.
- d/p/test-set-UsePAM-no-on-some-tests.patch: set UsePAM=no for some tests
- Ensure smooth upgrade path from versions affected by LP: #2020474:
+ debian/openssh-server.postint: do not try to restart systemd units,
and instead indicate that a reboot is required
+ debian/tests/systemd-socket-activation: Reboot the testbed before starting the test
+ debian/rules: Do not stop ssh.socket on upgrade
openssh (1:9.3p1-1) unstable; urgency=medium
* Debconf translations:
- Romanian (thanks, Remus-Gabriel Chelu; closes: #1033178).
* Properly fix date of 1:3.0.2p1-2 changelog entry (closes: #1034425).
* New upstream release (https://www.openssh.com/releasenotes.html#9.3p1):
- [CVE-2023-28531] ssh-add(1): when adding smartcard keys to
ssh-agent(1) with the per-hop destination constraints (ssh-add -h ...)
added in OpenSSH 8.9, a logic error prevented the constraints from
being communicated to the agent. This resulted in the keys being added
without constraints. The common cases of non-smartcard keys and keys
without destination constraints are unaffected. This problem was
reported by Luci Stanescu (closes: #1033166).
- [SECURITY] ssh(1): Portable OpenSSH provides an implementation of the
getrrsetbyname(3) function if the standard library does not provide
it, for use by the VerifyHostKeyDNS feature. A specifically crafted
DNS response could cause this function to perform an out-of-bounds
read of adjacent stack data, but this condition does not appear to be
exploitable beyond denial-of-service to the ssh(1) client.
- ssh-keygen(1), ssh-keyscan(1): accept -Ohashalg=sha1|sha256 when
outputting SSHFP fingerprints to allow algorithm selection.
- sshd(8): add a `sshd -G` option that parses and prints the effective
configuration without attempting to load private keys and perform
other checks. This allows usage of the option before keys have been
generated and for configuration evaluation and verification by
unprivileged users.
- scp(1), sftp(1): fix progressmeter corruption on wide displays.
- ssh-add(1), ssh-keygen(1): use RSA/SHA256 when testing usability of
private keys as some systems are starting to disable RSA/SHA1 in
libcrypto.
- sftp-server(8): fix a memory leak.
- ssh(1), sshd(8), ssh-keyscan(1): remove vestigial protocol
compatibility code and simplify what's left.
- Fix a number of low-impact Coverity static analysis findings.
- ssh_config(5), sshd_config(5): mention that some options are not
first-match-wins.
- Rework logging for the regression tests. Regression tests will now
capture separate logs for each ssh and sshd invocation in a test.
- ssh(1): make `ssh -Q CASignatureAlgorithms` work as the manpage says
it should.
- ssh(1): ensure that there is a terminating newline when adding a new
entry to known_hosts.
- sshd(8): harden Linux seccomp sandbox. Move to an allowlist of
mmap(2), madvise(2) and futex(2) flags, removing some concerning
kernel attack surface.
* debian/README.Debian: Clarify that you need to restart ssh.socket after
overriding its ListenStream= option (LP: #2020560).
* debian/openssh-server.postinst: Use "sshd -G" to parse the server
configuration file (closes: #959726).
* Fix incorrect RRSET_FORCE_EDNS0 flags validation in SSHFP DNSSEC patch
(thanks, Ben Hutchings; closes: #909022).
* Always use the internal mkdtemp implementation, since it substitutes
more randomness into the template string than glibc's version (closes:
#1001186).
-- Nick Rosbrook <nick.rosbrook at canonical.com> Mon, 03 Jul 2023
11:34:47 -0400
** Changed in: openssh (Ubuntu)
Status: Fix Committed => Fix Released
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2023-28531
--
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/2020560
Title:
ssh.service and ssh.socket both running.
Status in openssh package in Ubuntu:
Fix Released
Bug description:
I am running Ubuntu 23.04. The out-of-the-box configuration allows SSH
access on port 22. I wish to have ssh listen on both ports 22 and
7022. The ssh_config file contains a comment that Ubuntu now uses
socket activated connections and thus ignores the Port and
ListenAddress entries. I looked up the ssh socket activation and found
that I needed a /etc/systemd/system/ssh.socket.d directory that
contains a listen.conf file. I created the directory and the
listen.conf file that contains this.
[Socket]
# Uncomment the following line to turn of listening on port 22.
#ListenStream=
ListenStream=7022
I then ran these two commands:
sudo systemctl daemon-reload
sudo systemctl restart ssh
I then checked for port listeners:
root# lsof -i -P -n | grep LISTEN
systemd 1 root 454u IPv6 25979 0t0 TCP *:22 (LISTEN)
systemd-r 638 systemd-resolve 14u IPv4 35332 0t0 TCP 127.0.0.53:53 (LISTEN)
systemd-r 638 systemd-resolve 16u IPv4 35334 0t0 TCP 127.0.0.54:53 (LISTEN)
Xtigervnc 941 moose 9u IPv4 22485 0t0 TCP 127.0.0.1:5902 (LISTEN)
Xtigervnc 941 moose 10u IPv6 22486 0t0 TCP [::1]:5902 (LISTEN)
cupsd 2258639 root 6u IPv6 33526334 0t0 TCP [::1]:631 (LISTEN)
cupsd 2258639 root 7u IPv4 33526335 0t0 TCP 127.0.0.1:631 (LISTEN)
sshd 3698765 root 3u IPv6 25979 0t0 TCP *:22 (LISTEN)
I then discovered that both ssh.service and ssh.socket are running:
root@/etc/netplan# systemctl status ssh.service
? ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; disabled; preset: enabled)
Drop-In: /etc/systemd/system/ssh.service.d
??00-socket.conf
Active: active (running) since Tue 2023-05-23 11:17:29 EDT; 36min ago
TriggeredBy: ? ssh.socket
Docs: man:sshd(8)
man:sshd_config(5)
Process: 3698763 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
Main PID: 3698765 (sshd)
Tasks: 3 (limit: 38046)
Memory: 3.6M
CPU: 206ms
CGroup: /system.slice/ssh.service
??3698765 "sshd: /usr/sbin/sshd -D [listener] 1 of 10-100 startups"
??3777496 "sshd: root [priv]"
??3777497 "sshd: root [net]"
May 23 11:51:44 alces sshd[3771657]: ...
Hint: Some lines were ellipsized, use -l to show in full.
root@/etc/netplan# systemctl status ssh.socket
? ssh.socket - OpenBSD Secure Shell server socket
Loaded: loaded (/lib/systemd/system/ssh.socket; enabled; preset: enabled)
Drop-In: /etc/systemd/system/ssh.socket.d
??listen.conf
Active: active (running) since Mon 2023-05-15 09:23:44 EDT; 1 week 1 day ago
Until: Mon 2023-05-15 09:23:44 EDT; 1 week 1 day ago
Triggers: ? ssh.service
Listen: [::]:22 (Stream)
[::]:7022 (Stream)
Tasks: 0 (limit: 38046)
Memory: 8.0K
CPU: 569us
CGroup: /system.slice/ssh.socket
May 15 09:23:44 alces systemd[1]: ...
Hint: Some lines were ellipsized, use -l to show in full.
Finally, I found that /lib/systemd/system contains both ssh.service and ssh.socket configurations.
ssh.service:
[Unit]
Description=OpenBSD Secure Shell server
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run
[Service]
EnvironmentFile=-/etc/default/ssh
ExecStartPre=/usr/sbin/sshd -t
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/usr/sbin/sshd -t
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartPreventExitStatus=255
Type=notify
[Install]
WantedBy=multi-user.target
Alias=sshd.service
ssh.socket:
[Unit]
Description=OpenBSD Secure Shell server socket
Before=sockets.target
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run
[Socket]
ListenStream=22
Accept=no
[Install]
WantedBy=sockets.target
Finally, in /etc/systemd/system there is an ssh.service.d directory
that contains the 00-socket.conf file that contains:
[Unit]
After=ssh.socket
Requires=ssh.socket
This is very confusing. I could disable ssh.service, but I am concerned that if I do this I will lose ssh connectivity to my headless server. What is the way out of this morass? It would be VERY helpful if there was a comprehensive guide to the current ssh configuration that explains what services to run, how to configure those services, and where the configuration files should reside.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2020560/+subscriptions
More information about the foundations-bugs
mailing list