Bug#1073065: ssh_config manpage disagrees with ssh -Q kex on KexAlgorithms
On Wed, Jun 12, 2024 at 12:45:49PM -0400, Antoine Beaupre wrote: > In Debian stable, the manual page says: > > KexAlgorithms > Specifies the available KEX (Key Exchange) algorithms. > Multiple algorithms must be comma-separated. If the spec‐ > ified list begins with a ‘+’ character, then the specified > algorithms will be appended to the default set instead of > replacing them. If the specified list begins with a ‘-’ > character, then the specified algorithms (including wild‐ > cards) will be removed from the default set instead of re‐ > placing them. If the specified list begins with a ‘^’ > character, then the specified algorithms will be placed at > the head of the default set. The default is: > >sntrup761x25519-sha...@openssh.com, >curve25519-sha256,curve25519-sha...@libssh.org, >ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521, >diffie-hellman-group-exchange-sha256, >diffie-hellman-group16-sha512, >diffie-hellman-group18-sha512, >diffie-hellman-group14-sha256 > > The list of available key exchange algorithms may also be > obtained using "ssh -Q kex". > > Yet that command, `ssh -Q kex`, has a *different* list: I think this is mainly an error of emphasis. The list that's explicitly spelled out in the manual page is the list of algorithms used by *default*, but the list shown by "ssh -Q kex" is the list that's *available*. Some old algorithms are still implemented for legacy compatibility reasons but aren't sent to servers by default. It would probably be less confusing if the word "also" were removed from the last sentence, but also "available" is used in two slightly different senses in this documentation, which doesn't help. While the similar passage in sshd_config(5) still isn't ideal, it has a slightly clearer distinction between "supported" and "default" which is an improvement. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1072221: secure_permission from user-group-modes.patch does not account for symlinks installed by systemd
On Thu, May 30, 2024 at 12:04:02PM -0400, Ryan Kavanagh wrote: > systemd services that use ssh (e.g., backup services launched by a > systemd timer) abort with: > > Bad owner or permissions on > /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf > > After quickly tracing through the sources, I suspect that this is due to > Debian's user-group-modes.patch. It introduces a function > secure_permission and patches read_config_file_depth in readconf.c to > use secure_permission to check that a configuration file is not world > writeable. Unfortunately, the check > > if ((st->st_mode & 002) != 0) > > in secure_permission does not account for symlinks. I'm not sure that can be it, because as far as I can tell this is only ever called on a stat buffer resulting from stat() or equivalent, not lstat(). It shouldn't see the permissions on the symbolic link itself. Are you in a position to trace any further? A copy of one of the relevant systemd units might be helpful information. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1071292: openssh-server: sshd fails to restart at package upgrade, future logins to server impossible
On Fri, May 17, 2024 at 09:42:05PM +0200, Sven-Haegar Koch wrote: > I just upgraded openssh as part of my normal "apt dist-upgrade" every > few days, from 1:9.7p1-4 to 1:9.7p1-5. > > The whole apt went through without any errors - but afterwards sshd > was no longer running / listening on its network ports. Hm, I haven't seen this elsewhere either in my own upgrades or from anyone else, and as you say the ssh.service logs don't give much to go on. Is there anything informative in /var/log/auth.log, perhaps? -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1070098: openssh-sftp-server: False dependency on openssh-client
On Mon, Apr 29, 2024 at 10:19:14PM -0500, Wolf wrote: > Only the openssh-sftp-server package to be installed, as it has no ties to the > openssh-client files and is in fact only used by the server side components. It's not precisely a false dependency: $ ls -l /usr/share/doc/openssh-sftp-server lrwxrwxrwx 1 root root 14 Feb 26 12:26 /usr/share/doc/openssh-sftp-server -> openssh-client This saves a bit of space if all the packages are installed together, which is the common case. However, it's true that it's not very much space (200K or so), so maybe it's not worth the resulting confusion ... > Related but dropbear-bin also has a suggestion to install openssh-client, > however dropbear-bin includes all relevant key-generation tools natively, > so perhaps this 'Suggestion' should point to openssh-sftp-server instead? You'll have to report that as a separate bug - I don't maintain the dropbear packages. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1069706: systemd unit files lack ordering wrt nss-user-lookup.target
On Tue, Apr 23, 2024 at 09:32:00AM +0200, Rasmus Villemoes wrote: > According to systemd.special(7) > > nss-user-lookup.target > > A target that should be used as synchronization point for all > regular UNIX user/group name service lookups. [...] All > services for which the availability of the full user/group > database is essential should be ordered after this target, but > not pull it in. All services which provide parts of the > user/group database should be ordered before this target, and > pull it in. > > I have a custom .service that does exactly as described in the second > part, i.e. provides part of the user/group database and says > Before=nss-user-lookup.target, Wants=nss-user-lookup.target > (concretely, it modifies /etc/shadow to update a default password, but > that's not really important). I believe sshd definitely belongs in the > former category, i.e. sshd should not be started until any such > service that updates the user/group database, such as updating > /etc/shadow, have run. > > Hence the ssh.service and ssh.socket files should add > > After=nss-user-lookup.target > > in their [Unit] sections. This is a no-op on systems that do not have > any service pulling in that target, but required for correctness on > systems that do. > > Of course, I could, and currently do, handle this via a drop-in config > fragment in some ssh.service.d/ directory. But this, and other similar > synchronization targets, exist so that one does not necessarily need > to know about every other service running on the system. This sounds like a reasonable proposal to me. I'm just CCing Debian's systemd maintainers for a quick review to make sure I'm not missing anything subtle. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: [Pkg-shadow-devel] Bug#1068017: util-linux: please ship liblastlog2 packages
On Mon, Apr 08, 2024 at 09:19:09AM +0200, Iker Pedrosa wrote: > On Sat, Apr 6, 2024 at 11:48 PM Chris Hofstaedtler wrote: > > util-linux upstream provides three binary objects to be built: > > - liblastlog2.so > > - pam_lastlog2.so > > - lastlog2 (program) > > > > Debian's PAM policy says to put PAM modules into their own package, > > thus libpam-lastlog2. liblastlog2.so would go into the > > > liblastlog2(-0) package. The lastlog2 program either into its own > > lastlog2 package, or elsewhere. > > > > Please, let's call this pam_lastlog2 and not libpam-lastlog2. AFAIK, all > pam modules start with the prefix pam_*. The file names do, but the package names almost always start with "libpam-". (Also, Debian package names may not contain "_".) $ apt-file search security/pam_ | grep -v libpam-modules | grep --count ^libpam- 68 $ apt-file search security/pam_ | grep -v libpam-modules | grep --count ^pam- 1 And the Debian PAM mini-policy says: 1) Packages should use the naming scheme of `libpam-' (eg. libpam-ldap). -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Debian openssh option review: considering splitting out GSS-API key exchange
On Thu, Apr 04, 2024 at 06:42:08PM -0300, Henrique de Moraes Holschuh wrote: > If libwrap is bringing in complex libs, maybe we could reduce the > attack surface on libwrap itself? It would be nice to have a variant > that only links to the libc and that's it... Yeah, that's https://bugs.debian.org/1068311 which I linked to elsewhere in this thread. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Debian openssh option review: considering splitting out GSS-API key exchange
On Wed, Apr 03, 2024 at 04:01:34PM -0400, Michael Stone wrote: > To speed things up for those who really want it, perhaps make > openssh-client/server dependency-only packages on > openssh-client/server-nogss? People can choose the less-compatible version > for this release if they want to, and the default can change next release. > Pushing back the ability to install the unpatched version for a few more > years seems suboptimal. I worry about churn, and about inviting more bugs to do with moving an awkward combination of conffiles and non-conffile configuration files between packages. But maybe. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Debian openssh option review: considering splitting out GSS-API key exchange
On Wed, Apr 03, 2024 at 04:38:19PM +0200, Marc Haber wrote: > On Wed, 03 Apr 2024 14:10:37 +0100, "Jonathan Dowland" > wrote: > >For you and fellow greybeards, perhaps: I'd be surprised if many people > >younger than us have even heard of tcp wrappers. I don't think the > >muscle memory of a diminishing set of users is a strong argument, > >especially given it's a preference rather than a requirement, and > >alternatives do exist. > > It is possible to have that alternative not present without being > noticed (for example, a firewall build script failing, but sshd start > nof failing), whilea security measure built into the very daemon is > way harder to be accidentally disabled while keeping the daemon > running. While I'm still not totally convinced, one possible alternative here is https://bugs.debian.org/1068311. That would still mean one more library than strictly needed (once the GSS-API stuff is split out), but at least it would be one small library rather than a big linkage chain over 30 times the size. I could probably justify keeping it in that case. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Debian openssh option review: considering splitting out GSS-API key exchange
On Tue, Apr 02, 2024 at 12:04:26PM +0200, Marco d'Itri wrote: > Yes, people. I object to removing TCP wrappers support since the patch > is tiny and it supports use cases like DNS-based ACLs which cannot be > supported by L3 firewalls. I suspect OpenSSH upstream would also want me to point out that DNS-based ACLs are supported by Match blocks without needing a separate library. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Debian openssh option review: considering splitting out GSS-API key exchange
On Tue, Apr 02, 2024 at 12:04:26PM +0200, Marco d'Itri wrote: > On Apr 02, Colin Watson wrote: > > At the time, denyhosts was popular, but it was removed from Debian > > several years ago. I remember that, when I dealt with that on my own > > systems, fail2ban seemed like the obvious replacement, and my impression > > is that it's pretty widely used nowadays; it's very pluggable but it > > normally works by adding firewall rules. Are there any similar popular > > systems left that rely on editing /etc/hosts.deny? > > Yes, people. I object to removing TCP wrappers support since the patch > is tiny and it supports use cases like DNS-based ACLs which cannot be > supported by L3 firewalls. It's not about the size of the patch. You could use a drop-in unit to wrap sshd in tcpd, as suggested by the Fedora wiki page? This would avoid exposing sshd's process space to libwrap and all the stuff it links to by default. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Bug#1068017: util-linux: please ship liblastlog2 packages
On Sat, Mar 30, 2024 at 01:41:40AM +0100, Chris Hofstaedtler wrote: > On Sat, Mar 30, 2024 at 01:32:08AM +0100, Chris Hofstaedtler wrote: > > On Fri, Mar 29, 2024 at 06:02:39PM +0100, Sven Joachim wrote: > > > It seems desirable to ship liblastlog2 in trixie, considering that the > > > /var/log/lastlog file is not Y2038-safe and pam in unstable has already > > > dropped pam_lastlog.so, meaning that non-ssh logins are no longer > > > recorded in /var/log/lastlog. > > > [..] > > At the same time, all traditional writing to /var/log/lastlog should > > stop. > > > > So, after some of the current fog clears, src:util-linux could > > introduce new binary packages (at least libpam-lastlog2), but > > src:pam would need to add it to the common-* config files. > > > > Does this seem right? > > Answering my own question, not quite. > > Apparently, traditionally we have: > > * sshd writes to /var/log/lastlog by itself. > * login has pam_lastlog.so in its PAM snippet. > > Both of these would need to be replaced by pam_lastlog2.so. I don't > really know what the other distros are doing right now, and/or if > we should align on this. > > So we could either put pam_lastlog2.so into a common-* file from > src:pam, or openssh and shadow should switch their setup. I think I'm OK with configuring openssh with --disable-lastlog, although I haven't tested it. I think we should at least roughly coordinate this so that there isn't a long period when testing users have no last login information at all, though, so let me know when you'd like me to do that. It might be a good idea to wait until the main bulk of the 64-bit time_t transition is over so that we have a little more reasonable expectation of changes migrating to testing somewhat promptly. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Debian openssh option review: considering splitting out GSS-API key exchange
On Tue, Apr 02, 2024 at 03:27:30AM +0200, Christoph Anton Mitterer wrote: > Do you think it will be possible to have still only one `ssh`, `scp`, > etc. command and that will just use extra GSSAPI stuff if installed and > needed by a certain connection? It would be technically possible to retain the client parts of the GSS-API key exchange patch in the default variant. It would require the build to be separated into multiple passes, since that patch touches a number of files shared by the client and the server. Rather than trying to construct this, though, it would be much simpler and I think safer to just have a separate openssh-client-gsskeyex package. Like today's openssh-client, it would be usable both with and without GSS-API key exchange. -- Colin Watson (he/him) [cjwat...@debian.org]
Debian openssh option review: considering splitting out GSS-API key exchange
==
We carry a patch to restore support for TCP wrappers, which was dropped
in OpenSSH 6.7 (October 2014); see
https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-April/032497.html
and thread. That wasn't long before the Debian 8 (jessie) freeze, and
so I patched it back in "temporarily", but then I dropped the ball on
organizing a proper transition. libwrap links to libgssapi_krb5 (via
libnsl and libtirpc), so if we want to do a proper job of removing that
linkage then we'll have to finish this transition too. This probably
means a similar timeline, with the addition that people will have to
make sure that they aren't relying on /etc/hosts.deny being effective
for sshd.
At the time, denyhosts was popular, but it was removed from Debian
several years ago. I remember that, when I dealt with that on my own
systems, fail2ban seemed like the obvious replacement, and my impression
is that it's pretty widely used nowadays; it's very pluggable but it
normally works by adding firewall rules. Are there any similar popular
systems left that rely on editing /etc/hosts.deny?
Fedora dropped libwrap from sshd in 2018
(https://bugzilla.redhat.com/show_bug.cgi?id=1530163), and
https://fedoraproject.org/wiki/Changes/Deprecate_TCP_wrappers has some
other options here (which would need to be adapted for Debian, but
broadly similar approaches would work).
SELinux
===
The fact that we build using --with-selinux has come up
(https://cybervillains.com/@djm/112192735215160932). I haven't formed a
complete opinion on this, but I'm less worried about this linkage than
about GSS-API: it doesn't need much in the way of complex OpenSSH
patches, and the idea that it links indirectly to liblzma seems to have
been a mistaken one that turned up early in the discussions around the
xz-utils backdoor.
My feeling on this is that it's probably of about as much concern as
PAM, which we're definitely stuck with enabling, and I'm not
enthusiastic about adding a matrix of variant packages. We could go for
something like openssh-{client,server}-full, but I'm not clear that
there's much in the way of correlation between people who need GSS-API
key exchange and people who need SELinux support, and I don't want to
force more people than necessary onto the variant that includes an extra
4000-odd-line patch.
For the time being my inclination is to leave this be, but I've seen the
suggestion that pam_selinux is basically all you need
(https://infosec.exchange/@alwayscurious/112192949171400643), so maybe
it would be an option to drop --with-selinux in favour of that? I've
never used SELinux, so I'd need an expert to weigh on here.
Comments welcome,
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#1068162: Please consider adding MP-TCP support
Control: tags -1 wontfix On Mon, Apr 01, 2024 at 01:21:27AM +0200, Juliusz Chroboczek wrote: > Please consider applying the following patch: > > https://github.com/openssh/openssh-portable/pull/335 > > MP-TCP support allows moving from one IP address to another without > breaking connections, and does so in a way that remains compatible with > existing clients and servers. It solves the main issue that causes people > to prefer mosh to ssh. While I realize that this doesn't introduce a new external dependency, I have to say that this is not the week to be asking for a new distro patch to OpenSSH! I'd be happy to include this if upstream does, but I don't think I'm likely to apply this in advance of upstream. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: sshd dependancy to systemd and attack surface
On Sat, Mar 30, 2024 at 12:46:51PM +0100, Marc SCHAEFER wrote: > sshd has a dependancy to systemd, and thus includes a lot of libraries, > which augments its attack surface. libsystemd, not systemd. > The recent xz-utils issue [1] has lead to this post by someone suggesting > (with a patch, apparently) to confine the sshd -> systemd dependancy > in a subprocess [2]. > > Maybe you want to look into it? We could do something like that, but I'd prefer to go with the patch upstream is working on in https://bugzilla.mindrot.org/show_bug.cgi?id=2641. I'm going to be doing some testing of that soon. There's also work on the libsystemd side to load decompression libraries only when actually needed, which they wouldn't be in this case. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1067243: openssh: please build without -fzero-call-used-regs=used on m68k
On Sat, Mar 23, 2024 at 01:49:19AM +, Thorsten Glaser wrote: > Colin Watson dixit: > >Could you try the somewhat further reduced patch in > > The package made from that branch built fine in my cowbuilder, > and I have all reason to assume it’ll do so in sbuild/buildd. Thanks for the testing! -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1067243: openssh: please build without -fzero-call-used-regs=used on m68k
On Thu, Mar 21, 2024 at 10:35:17PM +, Thorsten Glaser wrote: > Colin Watson dixit: > >Could you try the somewhat further reduced patch in > > I’ve started a build and will let you know probably when I get > back late tomorrow. Thanks! No rush - I won't be at a proper computer until Sunday or so anyway. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1067243: openssh: please build without -fzero-call-used-regs=used on m68k
On Wed, Mar 20, 2024 at 07:14:42PM +, Thorsten Glaser wrote:
> I can confirm that appending…
>
> int snprintf_eta;
> double snprintf_time_per_line;
> int snprintf(char *str, size_t size, const char *format, ...) {
> snprintf_eta = snprintf_time_per_line;
> }
>
> … (lightly changed from the above) to the program from
> m4/openssh.m4 OSSH_COMPILER_FLAG_TEST_PROGRAM fails with:
>
> (pbuild-15711)root@ara2:/tmp# gcc -O2 -fPIE -fno-strict-aliasing
> -fzero-call-used-regs=used t.c
> during RTL pass: zero_call_used_regs
> t.c: In function 'snprintf':
> t.c:51:1: internal compiler error: in change_address_1, at emit-rtl.cc:2287
>51 | }
> | ^
> […]
I don't love overriding snprintf here, since it seems possible that that
could disturb the check on other architectures. Could you try the
somewhat further reduced patch in
https://salsa.debian.org/ssh-team/openssh/-/tree/zero-call-used-regs-m68k,
please? I wanted to use the mitchy.debian.net porterbox but I got
ECONNREFUSED.
> Alternatively, just hardcode disabling this flag on m68k for now,
> which we’ll eventually have to revert once GCC is on a fixed release
> (14 probably).
This configure check doesn't use the usual autoconf result caching
arrangements, which makes it a bit more awkward to override from
debian/rules. There are options, but an extended configure check that I
could send upstream would probably be best.
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#1061516: Please add a sshd@.service template for socket activation
On Wed, Feb 28, 2024 at 01:17:32AM +0100, Marco d'Itri wrote: > On Jan 25, Marco d'Itri wrote: > > systemd currently expects the template to be named sshd@.service > > (because that is what Fedora uses), but if you prefer to keep the > > ssh@.service name then I suppose that we could patch systemd as well. > > Is there any way I can help with this? > The major issue is deciding how you want the template to be called. Does this patch look workable? It mostly just resurrects the template unit we used to ship, under a different name. diff --git a/debian/changelog b/debian/changelog index 873dddcfa..78863e039 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,14 @@ +openssh (1:9.6p1-5) UNRELEASED; urgency=medium + + * Restore systemd template unit for per-connection sshd instances, +although without any corresponding .socket unit for now; this is mainly +for use with the forthcoming systemd-ssh-generator (closes: #1061516). +It's now called sshd@.service, since unlike the main service there's no +need to be concerned about compatibility with the slightly confusing +"ssh" service name that Debian has traditionally used. + + -- Colin Watson Sun, 03 Mar 2024 19:49:58 + + openssh (1:9.6p1-4) unstable; urgency=medium * Add sshd_config checksums for 1:9.2p1-1 to ucf reference file, and add a diff --git a/debian/openssh-server.install b/debian/openssh-server.install index cf86dce41..5bf99be16 100755 --- a/debian/openssh-server.install +++ b/debian/openssh-server.install @@ -14,6 +14,7 @@ debian/openssh-server.ufw.profile => etc/ufw/applications.d/openssh-server debian/systemd/ssh.service lib/systemd/system debian/systemd/ssh.socket lib/systemd/system debian/systemd/rescue-ssh.target lib/systemd/system +debian/systemd/sshd@.service lib/systemd/system debian/systemd/ssh-session-cleanup usr/lib/openssh # dh_apport would be neater, but at the time of writing it isn't in unstable diff --git a/debian/systemd/sshd@.service b/debian/systemd/sshd@.service new file mode 100644 index 0..29864a800 --- /dev/null +++ b/debian/systemd/sshd@.service @@ -0,0 +1,12 @@ +[Unit] +Description=OpenBSD Secure Shell server per-connection daemon +Documentation=man:sshd(8) man:sshd_config(5) +After=auditd.service + +[Service] +EnvironmentFile=-/etc/default/ssh +ExecStart=-/usr/sbin/sshd -i $SSHD_OPTS +StandardInput=socket +RuntimeDirectory=sshd +RuntimeDirectoryPreserve=yes +RuntimeDirectoryMode=0755 Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1064898: /usr/bin/sshd: mktemp - literal X-s in /tmp directory names
On Tue, Feb 27, 2024 at 12:56:47PM +0100, Csillag Tamas wrote: >* What led up to the situation? > After upgrading to debian 12 I am seeing directories in /tmp like: > ssh-XXnOKqkt, ssh-XXtGmfLV >* What was the outcome of this action? >* What outcome did you expect instead? > These directories are created by sshd. > In oldstable and OpenBSD the directories are as expected: > ssh-LwxtSMoGSV, ssh-JPcQMaBN6s > > The regression might be only in openssh-portable? > > As there are still 6 variable characters this might not be easily exploitable > security-wise and it used to be 10 just as in OpenBSD current. This is the same as https://bugs.debian.org/1001186; it's fixed for the next development release, but not yet for bookworm. Since this doesn't appear to be immediately serious, my inclination is to queue this up to fix along with the next bookworm openssh security update (whenever that might be), but not to trouble the security team with it right away. Does that sound reasonable? Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1059393: openssh: CVE-2023-51767
On Fri, Feb 23, 2024 at 12:40:41PM +, P Tamil Selvam wrote: > Pls. let us know the ETA by when openssh issue will be fixed in bookworm > release ? No fix exists anywhere to my knowledge, so there is currently no ETA. The right place to ask about a fix would be upstream. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1063842: openssh-server: Binding to a static IPv6 address causes sshd to fail at bootup
On Tue, Feb 13, 2024 at 01:13:17PM +, Bert wrote: > I configured SSH with a static IPv6 ListenAddress. > During bootup, SSH tries to start before the IPv6 address has been fully > bound to the host (ie during duplicate address detection) > This results in SSH failing to start with "Cannot bind any address" and a > return code of 255. > The systemd unit file for ssh contains "RestartPreventExitStatus=255" which > causes it to give up when it encounters this error. > In a cloud environment this is a critical failure as it renders the host > inaccessible. > The same thing occurs if the static IPv6 address is assigned a different way > (eg via SLAAC or DHCPv6) > If you remove this line, systemd tries again and succeeds once the address > has been bound to the host. I generally also add "StartSec=15s" to prevent it > trying too frequently. > This manual change is not persistent, as it gets overwritten next time you > update the package. I suggest that in such unusual configurations you should use the After= directive in the [Unit] section to ensure that ssh.service doesn't start until the relevant other systemd unit has been started. You can do this in a way that persists across upgrades using a drop-in unit; see "man systemd.unit" or use "systemctl edit ssh.service". However, a simpler solution might well be to remove ListenAddress and instead use firewall rules to restrict incoming SSH connections to only the desired address(es), as is recommended in README.Debian. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: openssh-server for stable has CVE vulnerability
On Wed, Jan 31, 2024 at 08:19:41AM +, schw...@riseup.net wrote: > I'm a longterm debian user but seeing latest security fix is not > delivered - Should I start using `sid` for everything now?? https://security-tracker.debian.org/tracker/source-package/openssh shows only one open CVE of any importance, for which no fix exists anywhere to my knowledge (it's mainly a hardware issue, so OpenSSH can't really fix it although it's possible that some form of mitigation might be developed; but in any case that would have to be done upstream first). The rest are all either fixed in stable or unimportant for one reason or another, which you can usually find if you click through to the CVE ID in question. There are no differences in CVE coverage right now between stable and unstable as far as I know. Is there a particular CVE that you're concerned about? Note that third-party scanners often report false positives because they work purely in terms of upstream versions and don't understand that distributions often backport fixes. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1059393: ABACuS arXiv.2310.09977
On Tue, Dec 26, 2023 at 12:03:36PM +0100, Boud Roukema wrote: > There's a proposed mitigation for CVE-2023-51767 with ABACuS: > > https://arxiv.org/abs/2310.09977 > > https://github.com/CMU-SAFARI/ABACuS This is a proposal for redesigned memory controllers. It isn't an actionable mitigation at the level of OpenSSH. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1059639: please give possibility for custom ssh-agent parameters
On Fri, Dec 29, 2023 at 07:38:40PM +0100, Marc Haber wrote: > /usr/lib/openssh/agent-launch starts ssh-agent with a standard set of > parameters. I'd like to have -t 1200 added to that. > > Please consider adding a possibility to control the parameters that the > ssh agent is being invoked, for example by having an override unit, or > having /usr/lib/openssh/agent-launch read a user-specific configuration > file. My main concern is getting quoting right: ssh-agent does take some options were quoting can be relevant, especially -P. IMO that rules out approaches such as environment variables (well, it's not impossible, but it'd be a likely source of bugs). I think the simplest approach would be to allow invoking something like "/usr/lib/openssh/agent-launch start -- -t 1200", and pass the extra arguments on to ssh-agent. You could then write a drop-in unit like this: [Service] ExecStart= ExecStart=/usr/lib/openssh/agent-launch start -- -t 1200 Would that be acceptable? -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1049995: openssh: catalan translation [INTL:ca]
On Fri, Aug 18, 2023 at 04:37:50AM +0200, Pablo Huguet wrote: > I did the catalan translation of it, and I will add the translation is > included > thanks for reading! Hi, Thanks for the translation! However, it contains syntax errors: $ msgmerge -U debian/po/ca.po debian/po/templates.pot debian/po/ca.po:41:59: syntax error debian/po/ca.po:57:27: syntax error msgmerge: found 2 fatal errors Could you please fix these? -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1052150: bullseye-pu: package openssh/1:8.4p1-5+deb11u2
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: open...@packages.debian.org
Control: affects -1 + src:openssh
[ Reason ]
https://bugs.debian.org/1042460 is a security issue affecting bullseye.
The security team doesn't think it warrants a DSA, but thinks it's worth
fixing in a point release. I agree.
[ Impact ]
Forwarding an SSH agent to a remote system may be exploitable by
administrators of that remote system in complicated conditions. See
https://www.qualys.com/2023/07/19/cve-2023-38408/rce-openssh-forwarded-ssh-agent.txt.
[ Tests ]
I have tested this manually as far as I'm able to do so. Essentially,
this shuts down the exploit at the first hurdle by refusing to load
objects that don't appear to be valid FIDO/PKCS#11 modules intended for
use by ssh-agent.
[ Risks ]
The code isn't quite trivial, but it's fairly straightforward once you
understand what it's doing.
The second upstream patch in the series wasn't in OpenSSH 9.3p2 (the
initial upstream release addressing this vulnerability), but I think
it's worth taking anyway because it shuts down a range of clever attacks
along these same lines without introducing an unreasonable amount of
extra complexity. Ubuntu did the same thing in their security updates
for this.
I wasn't able to backport the other part of upstream's fix for this
(disallowing remote addition of FIDO/PKCS#11 keys by default), because
that relies on the mechanism in
https://www.openssh.com/agent-restrict.html and bullseye doesn't have
that.
[ Checklist ]
[X] *all* changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in (old)stable
[X] the issue is verified as fixed in unstable
[ Changes ]
See attached debdiff.
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
diff -Nru openssh-8.4p1/debian/.git-dpm openssh-8.4p1/debian/.git-dpm
--- openssh-8.4p1/debian/.git-dpm 2022-07-01 23:37:41.0 +0100
+++ openssh-8.4p1/debian/.git-dpm 2023-09-17 23:46:46.0 +0100
@@ -1,6 +1,6 @@
# see git-dpm(1) from git-dpm package
-ed99ef256258d8556dbe39d976c2528ede050f14
-ed99ef256258d8556dbe39d976c2528ede050f14
+fb685ebb9f8391ab2836715c9c347ee50a0c9f48
+fb685ebb9f8391ab2836715c9c347ee50a0c9f48
2b2c99658e3e8ed452e28f88f9cdbcdfb2a461cb
2b2c99658e3e8ed452e28f88f9cdbcdfb2a461cb
openssh_8.4p1.orig.tar.gz
diff -Nru openssh-8.4p1/debian/changelog openssh-8.4p1/debian/changelog
--- openssh-8.4p1/debian/changelog 2022-07-01 23:37:41.0 +0100
+++ openssh-8.4p1/debian/changelog 2023-09-17 23:46:46.0 +0100
@@ -1,3 +1,12 @@
+openssh (1:8.4p1-5+deb11u2) bullseye; urgency=medium
+
+ * Cherry-pick from OpenSSH 9.3p2:
+- [CVE-2023-38408] Fix a condition where specific libraries loaded via
+ ssh-agent(1)'s PKCS#11 support could be abused to achieve remote code
+ execution via a forwarded agent socket (closes: #1042460).
+
+ -- Colin Watson Sun, 17 Sep 2023 23:46:46 +0100
+
openssh (1:8.4p1-5+deb11u1) bullseye; urgency=medium
* Backport from upstream:
diff -Nru openssh-8.4p1/debian/patches/CVE-2023-38408-1.patch
openssh-8.4p1/debian/patches/CVE-2023-38408-1.patch
--- openssh-8.4p1/debian/patches/CVE-2023-38408-1.patch 1970-01-01
01:00:00.0 +0100
+++ openssh-8.4p1/debian/patches/CVE-2023-38408-1.patch 2023-09-17
23:46:46.0 +0100
@@ -0,0 +1,30 @@
+From 8175e38eaf5636f45c3f27f4eadee1d583b70d35 Mon Sep 17 00:00:00 2001
+From: Damien Miller
+Date: Thu, 13 Jul 2023 12:09:34 +1000
+Subject: terminate pkcs11 process for bad libraries
+
+Origin: upstream,
https://anongit.mindrot.org/openssh.git/commit/?id=b23fe83f06ee7e721033769cfa03ae840476d280
+Last-Update: 2023-09-17
+
+Patch-Name: CVE-2023-38408-1.patch
+---
+ ssh-pkcs11.c | 6 ++
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+diff --git a/ssh-pkcs11.c b/ssh-pkcs11.c
+index f495883d1..d864051c4 100644
+--- a/ssh-pkcs11.c
b/ssh-pkcs11.c
+@@ -1519,10 +1519,8 @@ pkcs11_register_provider(char *provider_id, char *pin,
+ error("dlopen %s failed: %s", provider_id, dlerror());
+ goto fail;
+ }
+- if ((getfunctionlist = dlsym(handle, "C_GetFunctionList")) == NULL) {
+- error("dlsym(C_GetFunctionList) failed: %s", dlerror());
+- goto fail;
+- }
++ if ((getfunctionlist = dlsym(handle, "C_GetFunctionList")) == NULL)
++ fatal("dlsym(C_GetFunctionList) failed: %s", dlerror());
+ p = xcalloc(1, sizeof(*p));
+ p->name = xstrdup(provider_id);
+ p->handle = handle;
diff -Nru openssh-8.4p1/debian/patches/CVE-2023-38408-2.patch
openssh-8.4p1/debian/patches/CVE-2023-38408-2.patch
--- openssh-8.4p1/debian/patches/CVE-2023-38408-2.patch 1970-01-01
01:00:00.0 +0100
+++ openssh-8.4p1/debian/patches/CVE-2023-38408-2.p
Bug#1052149: bookworm-pu: package openssh/1:9.2p1-2+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: open...@packages.debian.org
Control: affects -1 + src:openssh
[ Reason ]
https://bugs.debian.org/1042460 is a security issue affecting bookworm.
The security team doesn't think it warrants a DSA, but thinks it's worth
fixing in a point release. I agree.
[ Impact ]
Forwarding an SSH agent to a remote system may be exploitable by
administrators of that remote system in complicated conditions. See
https://www.qualys.com/2023/07/19/cve-2023-38408/rce-openssh-forwarded-ssh-agent.txt.
[ Tests ]
I have tested this manually as far as I'm able to do so. Essentially,
this shuts down the exploit at the first hurdle by refusing to load
objects that don't appear to be valid FIDO/PKCS#11 modules intended for
use by ssh-agent, and by disallowing remote addition of FIDO/PKCS#11
keys by default.
[ Risks ]
The code isn't quite trivial, but it's fairly straightforward once you
understand what it's doing.
The third upstream patch in the series wasn't in OpenSSH 9.3p2 (the
initial upstream release addressing this vulnerability), but I think
it's worth taking anyway because it shuts down a range of clever attacks
along these same lines without introducing an unreasonable amount of
extra complexity. Ubuntu did the same thing in their security updates
for this.
[ Checklist ]
[X] *all* changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in (old)stable
[X] the issue is verified as fixed in unstable
[ Changes ]
See attached debdiff.
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
diff -Nru openssh-9.2p1/debian/.git-dpm openssh-9.2p1/debian/.git-dpm
--- openssh-9.2p1/debian/.git-dpm 2023-02-08 10:43:07.0 +
+++ openssh-9.2p1/debian/.git-dpm 2023-09-17 21:23:50.0 +0100
@@ -1,6 +1,6 @@
# see git-dpm(1) from git-dpm package
-74edce484429249265baaee1e8a5d1785ee7afa7
-74edce484429249265baaee1e8a5d1785ee7afa7
+29c7785a3673101b3af8f6f712795fa128e52ddd
+29c7785a3673101b3af8f6f712795fa128e52ddd
cf3c3acb2b8f74eeca7fcee269b1d33ac83f1188
cf3c3acb2b8f74eeca7fcee269b1d33ac83f1188
openssh_9.2p1.orig.tar.gz
diff -Nru openssh-9.2p1/debian/changelog openssh-9.2p1/debian/changelog
--- openssh-9.2p1/debian/changelog 2023-02-08 10:43:07.0 +
+++ openssh-9.2p1/debian/changelog 2023-09-17 21:23:50.0 +0100
@@ -1,3 +1,12 @@
+openssh (1:9.2p1-2+deb12u1) UNRELEASED; urgency=medium
+
+ * Cherry-pick from OpenSSH 9.3p2:
+- [CVE-2023-38408] Fix a condition where specific libraries loaded via
+ ssh-agent(1)'s PKCS#11 support could be abused to achieve remote code
+ execution via a forwarded agent socket (closes: #1042460).
+
+ -- Colin Watson Sun, 17 Sep 2023 21:23:50 +0100
+
openssh (1:9.2p1-2) unstable; urgency=medium
* Fix mistakenly-unreleased entry for 1:9.2p1-1 in debian/NEWS.
diff -Nru openssh-9.2p1/debian/patches/CVE-2023-38408-1.patch
openssh-9.2p1/debian/patches/CVE-2023-38408-1.patch
--- openssh-9.2p1/debian/patches/CVE-2023-38408-1.patch 1970-01-01
01:00:00.0 +0100
+++ openssh-9.2p1/debian/patches/CVE-2023-38408-1.patch 2023-09-17
21:23:50.0 +0100
@@ -0,0 +1,30 @@
+From dee3878689aef5365955442869be02d420b65ea6 Mon Sep 17 00:00:00 2001
+From: Damien Miller
+Date: Thu, 13 Jul 2023 12:09:34 +1000
+Subject: terminate pkcs11 process for bad libraries
+
+Origin: upstream,
https://anongit.mindrot.org/openssh.git/commit/?id=b23fe83f06ee7e721033769cfa03ae840476d280
+Last-Update: 2023-09-17
+
+Patch-Name: CVE-2023-38408-1.patch
+---
+ ssh-pkcs11.c | 6 ++
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+diff --git a/ssh-pkcs11.c b/ssh-pkcs11.c
+index b2e2b32a5..9e48c134e 100644
+--- a/ssh-pkcs11.c
b/ssh-pkcs11.c
+@@ -1537,10 +1537,8 @@ pkcs11_register_provider(char *provider_id, char *pin,
+ error("dlopen %s failed: %s", provider_id, dlerror());
+ goto fail;
+ }
+- if ((getfunctionlist = dlsym(handle, "C_GetFunctionList")) == NULL) {
+- error("dlsym(C_GetFunctionList) failed: %s", dlerror());
+- goto fail;
+- }
++ if ((getfunctionlist = dlsym(handle, "C_GetFunctionList")) == NULL)
++ fatal("dlsym(C_GetFunctionList) failed: %s", dlerror());
+ p = xcalloc(1, sizeof(*p));
+ p->name = xstrdup(provider_id);
+ p->handle = handle;
diff -Nru openssh-9.2p1/debian/patches/CVE-2023-38408-2.patch
openssh-9.2p1/debian/patches/CVE-2023-38408-2.patch
--- openssh-9.2p1/debian/patches/CVE-2023-38408-2.patch 1970-01-01
01:00:00.0 +0100
+++ openssh-9.2p1/debian/patches/CVE-2023-38408-2.patch 2023-09-17
21:23:50.0 +0100
@@ -0,0 +1,104 @@
+From 5c06b89189eb27f692b900526d60bf744918511e Mon Sep 17 00:00:00 2001
+From: Damie
Bug#972609: /lib/runit-helper/runit-helper: 74: sv: not found
Control: reassign -1 runit-helper Control: close -1 dh-runit/2.10.0 On Wed, Oct 21, 2020 at 08:59:31AM +0200, Marc Haber wrote: > reconfiguring openssh-server gives the following output: > > [5/5060]mh@fan:~ $ sudo dpkg-reconfigure -plow openssh-server > rescue-ssh.target is a disabled or a static unit, not starting it. > /lib/runit-helper/runit-helper: 74: sv: not found > [6/5061]mh@fan:~ $ > > I am not sure wheter this is an issue in runit, or in openssh. A message > like this is one that a trained administrator's eye will immediately > lock on to, so it should not be there. Sorry for missing this at the time. This was a dh-runit issue, and was fixed there: dh-runit (2.10.0) experimental; urgency=medium * Add invoke-rc.d actions support into dh-runit (Closes: #969511) * Deprecate the noreplace option, coupled with onupgrade=nostop * Add onupgrade=reload * Bump our version to 2.10.0 * Don't call sv if is runit is not installed (Closes: #968114) -- Lorenzo Puliti Sun, 06 Sep 2020 00:58:07 +0200 -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1034425: openssh: incorrection in changelog date
On Fri, Apr 14, 2023 at 07:04:46PM -0500, Peter Samuelson wrote: > I have no idea what possessed you to fix the dates on those > 20-year-old changelog entries, but since you care ... 1:3.0.2p1-2 is > still wrong. > > The correct fix was not s/Sat/Sun/ but s/2003/2002/. It was automatically generated by lintian-brush. I generally approve of having automatic tools fix menial packaging issues like this for me, even if they make the occasional mistake (I did review it, but I missed the error in this case). Thanks for spotting this; fixed. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1018260: openssh-server: fills the log with "deprecated reading of user environment enabled"
Control: clone -1
Control: reassign -2 release-notes
Control: retitle -2 release-notes: document deprecation of .pam_environment
On Sun, Jan 15, 2023 at 04:55:10PM +0300, Michael Tokarev wrote:
> On Sun, 28 Aug 2022 07:58:19 +0200 Francesco Potortì
> wrote:
> > My log is full of these:
> > sshd[4180530]: pam_env(sshd:session): deprecated reading of user
> > environment enabled
>
> This comes from /etc/pam.d/sshd:
> sessionrequired pam_env.so user_readenv=1 envfile=/etc/default/locale
>
> I'm not sure this is sshd issue or pam issue really: if it is deprecated
> in pam_env, sshd should not be using it, or it should not be deprecated.
>
> Removing user_readenv=1 fixes this.
There's now
https://salsa.debian.org/ssh-team/openssh/-/merge_requests/21 for this,
but as noted there I have documentation concerns about simply removing
this. Copying my comments from there:
This is going to have extensive fallout, the exact nature of which is
hard to predict. So far this deprecation has been the equivalent of
posting a notice in the bottom of a locked filing cabinet stuck in a
disused lavatory with a sign on the door saying "Beware of the
Leopard". The Debian PAM packages don't ship the upstream NEWS file,
and even if they did, the notice there is extremely brief. You can
see a deprecation warning if you read /var/log/auth.log, but who has
time for that unless something is going wrong? Besides, the people who
are most affected will be users who have .pam_environment files in
their home directories, and as far as I can tell nobody has gone to
any particular effort to notify them.
At a bare minimum, this needs an entry in debian/NEWS. But I'd go
further: I think this should be documented in Debian's release notes
(repository at https://salsa.debian.org/ddp-team/release-notes) for a
release before we make this change. That won't inform everyone, but
it should reduce the number of people caught unawares by this. Any
other practical ideas for informing affected users would be welcome.
Also, we need to track down an actual reason for this change.
"Security concerns" is not verbose enough to be convincing on its own.
I found
https://github.com/linux-pam/linux-pam/commit/ecd526743a27157c5210b0ce9867c43a2fa27784,
which is not much better ("Due to problematic security ..."). My best
guess is that upstream got fed up after dealing with things like
https://github.com/linux-pam/linux-pam/issues/263, but I'm really just
guessing, and proper documentation would actually explain this sort of
thing rather than just waving a security flag.
I'm cloning this bug for the release notes, and CCing the PAM maintainer
for comments.
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#1025533: New systemd socket activation breaks existing setups
On Tue, Dec 06, 2022 at 11:51:08AM +0100, martin f krafft wrote: > Package: openssh-server > Version: 1:9.1p1-1 > Severity: important > > Compared to Debian's 1:9.0p1-1, this version provides a `ssh.socket` > file that has `Accept=no`, and consequently, the package no longer > provides `ssh@.service`. This is most likely related to [Steve's > work](https://salsa.debian.org/ssh-team/openssh/-/commit/bfb10550c1e8c69757aff2860f60b78253fb9851) > > titled "Support systemd socket activation", despite socket > activation working out of the box previously. > > The new approach breaks existing setups that relied on systemd > handling the `accept()` call. At the very least, a `NEWS.Debian` > entry would be in order. > > Better yet would be a Debconf question to see what the user > wants/needs, defaulting to the status quo, rather than changing it. Steve, can I pass this bug over to you to address? Thanks, -- Colin Watson (he/him) [cjwat...@ubuntu.com]
Bug#1024568: openssh-client: ignores $HOME environment variable
Control: forwarded -1 https://bugzilla.mindrot.org/show_bug.cgi?id=3048 On Mon, Nov 21, 2022 at 02:54:13PM +0100, Gabor Kiss wrote: > I tried to run ssh client in a test environment with files (known_hosts, > config etc.) > from other than my usual /home/kissg/.ssh/ directory. > So after reading the docs I just modified the HOME environment variable to > /tmp/kissg. > However the program henceforward used the original /home/kissg/.ssh/. > > Checking the source I found that - in contrast to the man page - ssh client > does not care > with $HOME(*) but always uses home dir retrieved from passwd file. > (So I have to give every file in the command line one by one.) > > *: More precisely strace shows that ssh tried to open > "/tmp/kissg/.ssh/config_autotest" once: > newfstatat(AT_FDCWD, "/tmp/kissg/.ssh/config_autotest", 0x7ffda93d3cf0, > AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory) > That is quite funny because this file name does not occur in the source. The most current upstream bug for this is probably either https://bugzilla.mindrot.org/show_bug.cgi?id=3048 or https://bugzilla.mindrot.org/show_bug.cgi?id=3470, and those explain the historical reasons why the design is the way it is. I don't think there's anything we can sensibly do in Debian about this, so I'll just mark this as forwarded upstream. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#991936: openssh-server: seccomp filter defaults to SIGSYS, could break any libc or kernel upgrade
Control: severity -1 important Control: tag -1 upstream Control: forwarded -1 https://bugzilla.mindrot.org/show_bug.cgi?id=3478 On Fri, Aug 06, 2021 at 11:29:15AM +0200, Julian Andres Klode wrote: > seccomp filters are currently setup to kill the process > > #define SECCOMP_FILTER_FAIL SECCOMP_RET_KILL > > /* Default deny */ > BPF_STMT(BPF_RET+BPF_K, SECCOMP_FILTER_FAIL), > > this means every new libc or kernel release can cause openssh > to break, requiring breaks from them on openssh, which does not > scale, and is currently breaking SSH during upgrades. > > This also means openssh might fail to work inside containers > because the host kernel is newer. > > The default policy needs to be changed to return ENOSYS instead, > such that libc can fallback to other syscalls for its wrappers. > With the caveat that umask is a bit broken, if you don't want to > allow it, block it explicitly with RET_KILL: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1724098 > > This should be fixed for bullseye+1, and fixed in a point release > IMO, it might be a tad too late right now for the release itself. I agree this is at least a problem waiting to happen and a noticeable inconvenience for stable release maintenance, so I've (belatedly) forwarded it upstream with a suggested patch. The sandbox is security-critical enough that I don't want to patch fundamental things about its behaviour without upstream's consent, so we'll see what they make of my suggestion. I don't think this needs to be release-critical. It's a significant problem and I'd definitely like it to be fixed, but mostly this change would protect us against specific manifestations of syscall filtering problems that would be grave bugs, rather than being intrinsically RC. As such I'm downgrading it a step for now. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1016340: openssh: FTBFS: Failed to copy 'etc/ssh/sshd_config': No such file or directory at /usr/share/dh-exec/dh-exec-install-rename line 68, <> line 7.
dh-exec._KAY3sIj/usr/share/openssh/sshd_config") dh_missing: error: missing files, aborting While detecting missing files, dh_missing noted some files with a similar name to those that were missing. This error /might/ be resolved by replacing references to the missing files with the similarly named ones that dh_missing found - assuming the content is identical. As an example, you might want to replace: * debian/tmp/dh-exec._KAY3sIj/etc/ufw/applications.d/openssh-server with: * dh-exec.aqR1q_B1/etc/ufw/applications.d/openssh-server in a file in debian/ or as argument to one of the dh_* tools called from debian/rules. (Note it is possible the paths are not used verbatim but instead directories containing or globs matching them are used instead) Alternatively, add the missing file to debian/not-installed if it cannot and should not be used. The following debhelper tools have reported what they installed (with files per package) * dh_install: openssh-client (27), openssh-client-udeb (3), openssh-server (14), openssh-server-udeb (2), openssh-sftp-server (2), openssh-tests (10), ssh (0), ssh-askpass-gnome (2) * dh_installdocs: openssh-client (4), openssh-server (0), openssh-sftp-server (0), openssh-tests (0), ssh (0), ssh-askpass-gnome (0) * dh_installexamples: openssh-client (0), openssh-server (1), openssh-sftp-server (0), openssh-tests (0), ssh (0), ssh-askpass-gnome (1) * dh_installman: openssh-client (2), openssh-server (0), openssh-sftp-server (0), openssh-tests (0), ssh (0), ssh-askpass-gnome (1) If the missing files are installed by another tool, please file a bug against it. When filing the report, if the tool is not part of debhelper itself, please reference the "Logging helpers and dh_missing" section from the "PROGRAMMING" guide for debhelper (10.6.3+). (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz) Be sure to test with dpkg-buildpackage -A/-B as the results may vary when only a subset is built If the omission is intentional or no other helper can take care of this consider adding the paths to debian/not-installed. All those debian/tmp/dh-exec.* temporary directories are confusing dh_missing, it seems. I'm not quite sure what's going on here since this used to work. What's the intended design for these temporary directories? Presumably they can't be cleaned up by dh-exec-install-rename itself because the files still need to be processed by dh_install proper. That leaves the dh_missing warning for etc/ssh/sshd_config. That is in fact installed - it's just that debian/.debhelper/generated/openssh-server/installed-by-dh_install lists it as ./debian/tmp/dh-exec._KAY3sIj/usr/share/openssh/sshd_config rather than as the original file name. What are we supposed to do here? This seems like it must be a bug somewhere between debhelper and dh-exec, but I'm not sure exactly where. For now I'm going to work around this in openssh as follows: diff --git a/debian/openssh-server.install b/debian/openssh-server.install index 99cfb8d6b..cf86dce41 100755 --- a/debian/openssh-server.install +++ b/debian/openssh-server.install @@ -7,7 +7,7 @@ usr/share/man/man5/moduli.5 usr/share/man/man5/sshd_config.5 usr/share/man/man8/sshd.8 -etc/ssh/sshd_config => usr/share/openssh/sshd_config +debian/tmp/etc/ssh/sshd_config => usr/share/openssh/sshd_config debian/openssh-server.ucf-md5sum => usr/share/openssh/sshd_config.md5sum debian/openssh-server.ufw.profile => etc/ufw/applications.d/openssh-server diff --git a/debian/rules b/debian/rules index d5a9ee23d..5a8795478 100755 --- a/debian/rules +++ b/debian/rules @@ -203,6 +203,10 @@ override_dh_runit: execute_after_dh_fixperms-arch: chmod u+s debian/openssh-client/usr/lib/openssh/ssh-keysign +# Work around debhelper/dh-exec bug #XXX. +override_dh_missing: + dh_missing --list-missing + # Tighten libssl dependencies to match the check in entropy.c. execute_after_dh_shlibdeps: debian/adjust-openssl-dependencies But this all seems quite weird. Do you have any clues as to any of this? Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1011292: openssh-client: scp -O should be doable with a configuration file entry (in ~/.ssh/config)
On Thu, May 19, 2022 at 07:28:38PM +0200, Raphaël Hertzog wrote: > dput and dput-ng are using "scp" and don't offer any simple way to > configure command line parameters and the switch to "sftp-behind-the-back" > broke dput for me with some targets (cf #1011063). > > I would have liked to be able to add something like this in ~/.ssh/config: > > Host deb.freexian.com > UseLegacyScp true > > And be done with it. But there's no such option. It would be nice if > upstream could implement this. It would be best if you could forward this upstream yourself (https://bugzilla.mindrot.org/), since that way you can advocate for it directly. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1006445: openssh-server: Killed by seccomp after accepting connection (i386)
Control: forwarded -1 https://bugzilla.mindrot.org/show_bug.cgi?id=3396 On Fri, Feb 25, 2022 at 03:50:05PM +, Colin Watson wrote: > On Fri, Feb 25, 2022 at 02:14:58PM +, Paul Brook wrote: > > The attached patch fixes this by adding ppoll_time64 the seccomp sanbox > > filters, > > which seems reasonable as ppoll is already allowed. > > Yeah, this looks reasonable to me too, though for tidiness I'd suggest > moving __NR_ppoll_time64 below __NR_ppoll to match the ordering of > __NR_pselect6 and __NR_pselect6_time64. > > Would you mind sending this upstream to https://bugzilla.mindrot.org/ ? > I can do it for you if you can't, but it's usually best to have fewer > people in the middle of the discussion. Looks like somebody else already filed this at https://bugzilla.mindrot.org/show_bug.cgi?id=3396 with a very similar patch, so no need to send it again. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1006463: openssh-client: Can't login on two i386 boxes anymore since the server-side has been upgraded to 8.9p1: "debug1: expecting SSH2_MSG_KEX_ECDH_REPLY"
Control: forcemerge -1 1006445 On Fri, Feb 25, 2022 at 09:38:31PM +0100, Axel Beckert wrote: > TL;DR: OpenSSH clients (at least 8.8 and 8.9) can't talk with OpenSSH > 8.9 servers in some cases (common property so far: if and only if it's > i386 on the server-side), but 8.9 clients can talk with 8.8 servers in > the same cases (i.e. i386 on the server-side) after downgrading the > server-side. i386 OpenSSH clients can't talk to i386 8.9 servers either. See #1006445. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1004427: openssh-server: Connection reset when trying to establish a connection on armhf
Source: openssh Source-Version: 1:8.7p1-1 On Thu, Jan 27, 2022 at 02:52:31PM +0100, Benedikt Wildenhain wrote: > audit(1643291311.540:31): auid=4294967295 uid=105 gid=65534 ses=4294967295 > subj==unconfined pid=3813 comm="sshd" exe="/usr/sbin/sshd" sig=31 > arch=4028 syscall=413 compat=0 ip=0xb6a8e3c6 > This was fixed in OpenSSH 8.5p1: https://github.com/openssh/openssh-portable/commit/0f90440ca7 However, I think it would make sense to cherry-pick this patch to bullseye. I'll queue that up. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1004427: openssh-server: Connection reset when trying to establish a connection on armhf
On Fri, Feb 25, 2022 at 11:37:47AM +0100, Lionel Debroux wrote: > After upgrading packages on a Debian sid i386 computer today, which > contained a switch to OpenSSH_8.9p1 Debian-2 among other upgrades, I'm > now experiencing the same symptoms: > * [...] > debug1: Killing privsep child > debug1: audit_event: unhandled event 12 > appears in the auth log; > * an audit trace containing sig=31 syscall=414 appears in the kernel log. This is probably https://bugs.debian.org/1006445, which is a separate issue (the symptoms are different though superficially similar - the syscall is different). -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1006445: openssh-server: Killed by seccomp after accepting connection (i386)
On Fri, Feb 25, 2022 at 02:14:58PM +, Paul Brook wrote: > After accepting an ssh connection, the sshd process is killed and I see > the following in dmesg: > > audit: type=1326 audit(1645794361.669:40): auid=0 uid=100 gid=65534 ses=1 > subj==unconfined pid=8338 comm="sshd" exe="/usr/sbin/sshd" sig=31 > arch=4003 syscall=414 compat=0 ip=0xb7ee3559 code=0x0 > > Sysycall 414 is ppoll_time64, so I'm guessing this is fallout from > ongoing 2038 fixes. More likely fallout from the move from select()/pselect() to poll()/ppoll() in 8.9. I suspect this affects most 32-bit Linux architectures. > The attached patch fixes this by adding ppoll_time64 the seccomp sanbox > filters, > which seems reasonable as ppoll is already allowed. Yeah, this looks reasonable to me too, though for tidiness I'd suggest moving __NR_ppoll_time64 below __NR_ppoll to match the ordering of __NR_pselect6 and __NR_pselect6_time64. Would you mind sending this upstream to https://bugzilla.mindrot.org/ ? I can do it for you if you can't, but it's usually best to have fewer people in the middle of the discussion. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1006171: Make internal-sftp the default
On Sun, Feb 20, 2022 at 02:46:50PM +0100, MichaIng wrote: > Currently the standalone OpenSSH sftp-server is used as default SFTP > subsystem, set via /etc/ssh/sshd_config. This implies a dependency on the > openssh-sftp-server package and means that every SFTP connection spawns a > new external process, while sshd ships with the internal-sftp in-process > SFTP server, which perform better when dealing with many short duration > connections and simplifies the ChrootDirectory usage to not require any > manual /dev node setup. > > Legacy SSH1 clients pass an exact SFTP command, hence will still depend on > openssh-sftp-server or any alternative standalone SFTP server, also > internal-sftp means that the login shell is skipped in the first place. But > the need for both are edge cases, the use of SSH1 IMO worth to be actively > discouraged, and the vast majority of OpenSSH SFTP server admins will > benefit from this change, at least to not require a config change that is > part of very most SFTP guides around the internet, reasonably. I haven't done this mainly because if the default is to be changed it should be changed upstream; they're better placed to be aware of corner cases that might cause regressions if changing the default. I'd encourage you to file this on https://bugzilla.mindrot.org/ instead. (SSH 1 is not an issue, since the code to support it has been removed from the server anyway, so you should probably omit that part from your upstream report.) -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1001320: needrestart misdetects socket activated ssh and restarts service instead of socket
On Wed, Dec 29, 2021 at 07:45:11AM +0100, Marc Haber wrote: > On Tue, Dec 28, 2021 at 10:47:54PM +0000, Colin Watson wrote: > > On Sat, Dec 25, 2021 at 08:18:11AM +0100, Marc Haber wrote: > > > I would also mention that there might be cases of logins no longer > > > possible regarding library updates and needrestart. This is a serious > > > situation. > > > > Thanks, I've tweaked the parenthesis a bit more with that in mind. > > Technically, with socket activation, there is no "running sshd" while > nobody is logged in, but I still can log in. The issue is that if this > issue appears I can no longer log in because nothing, not even systemd, > is listening on Port 22. Fair enough - I've adjusted the documentation a bit further to make that clear. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1001320: needrestart misdetects socket activated ssh and restarts service instead of socket
On Sat, Dec 25, 2021 at 08:18:11AM +0100, Marc Haber wrote: > On Fri, Dec 24, 2021 at 11:04:20PM +0000, Colin Watson wrote: > > diff --git a/debian/README.Debian b/debian/README.Debian > > index dbe6c2958..0851e38e3 100644 > > --- a/debian/README.Debian > > +++ b/debian/README.Debian > > @@ -193,9 +193,12 @@ you can run: > > > > To make this permanent: > > > > - systemctl disable ssh.service > > + systemctl mask ssh.service > >systemctl enable ssh.socket > > I think the service needs to be stopped (and disable?) before masking > it. Stopping is already in the previous paragraph just outside the context of the patch I posted, but I've adjusted the linking sentence to make it clearer that you need to do both. > I would also mention that there might be cases of logins no longer > possible regarding library updates and needrestart. This is a serious > situation. Thanks, I've tweaked the parenthesis a bit more with that in mind. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1000495: openssh: drop the advertisement clause in BSD license
On Wed, Nov 24, 2021 at 01:50:01PM +0530, Ritesh Raj Sarraf wrote: > Niels gave his explicit permission to drop clause 3, the "advertising" > clause, from his code. > This restores the GPL compatibility. > > Request if the same can be updated in this package. > > References: > * https://github.com/pyca/bcrypt/pull/170 > * > https://github.com/pyca/bcrypt/files/3081054/Blowfish-cypher-license-change.pdf Regardless of what permission Niels has given, I can't unilaterally change it in Debian's OpenSSH packaging; it needs to be updated upstream first. Please file a bug at bugzilla.mindrot.org about this and mark this bug as forwarded (I don't think it makes sense for me to be in the middle here). -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#998619: openssh-server: server-sig-algs
On Thu, Nov 04, 2021 at 11:27:15PM -0300, Rafael Giangiulio wrote:
>* What led up to the situation?
>
> after changing all keys and keyex on sshd_config values so that sshd
> uses only "curve25519" algs, running "sshd -T" show everything allright but
> when connecting i get:
> debug1: kex_input_ext_info:
> server-sig-algs=
There's already a comment in the upstream source code about this:
static int
kex_send_ext_info(struct ssh *ssh)
{
int r;
char *algs;
debug("Sending SSH2_MSG_EXT_INFO");
if ((algs = sshkey_alg_list(0, 1, 1, ',')) == NULL)
return SSH_ERR_ALLOC_FAIL;
/* XXX filter algs list by allowed pubkey/hostbased types */
if ((r = sshpkt_start(ssh, SSH2_MSG_EXT_INFO)) != 0 ||
(r = sshpkt_put_u32(ssh, 1)) != 0 ||
(r = sshpkt_put_cstring(ssh, "server-sig-algs")) != 0 ||
(r = sshpkt_put_cstring(ssh, algs)) != 0 ||
(r = sshpkt_send(ssh)) != 0) {
error_fr(r, "compose");
goto out;
}
/* success */
r = 0;
out:
free(algs);
return r;
}
Does it cause a practical problem of any kind? ssh-ed25519 is still
first in the server-sig-algs list so any client that supports both
ssh-ed25519 and the server-sig-algs extension mechanism will select it,
and attempts to send public key material signed using a different
algorithm will be rejected later anyway due to PubkeyAcceptedKeyTypes
(renamed to PubkeyAcceptedAlgorithms in OpenSSH 8.5). So as far as I
can see this is essentially cosmetic.
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#997030: openssh: FTBFS on hurd-i386
On Fri, Oct 22, 2021 at 06:55:17PM +0200, Svante Signell wrote: > Currently openssh FTBFS on GNU/Hurd due to a missing definition of > MAXHOSTNAMELEN. The attached patches, defines.h.diff and gss- > serv.c.diff fixes these problems. The second patch isn't necessary; gss-serv.c already unconditionally includes includes.h, which in turn unconditionally includes defines.h. defines.h appears to conventionally not be included by individual .c files in OpenSSH. I've applied the first of these two patches for my next upload; thanks. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#996391: openssh: New upstream version available
For now I'm going to go ahead with packaging 8.7p1 (cherry-picking the security fix from 8.8p1) to at least catch us up a bit, and I'll leave this bug open. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#996391: openssh: New upstream version available
On Wed, Oct 13, 2021 at 05:38:56PM +0200, Michael Prokop wrote: > the current upstream version is 8.8p1 (see [1]), I'm sure that > the package maintainers are aware of this, but I couldn't find any > tracking bug report about this, so reporting it here. :) > > Given that there are plenty of new features, but also the (upcoming) > deprecation of scp(1), the disabled RSA signatures using the SHA-1 > hash algorithm,... it would be nice to get a more current OpenSSH > version in Debian. I'm indeed aware of this; but this is a good opportunity to explain the status, so thanks. The first issue was in sorting out an updated version of the GSS-API key exchange patch, which these days we maintain in conjunction with Fedora, but I wanted to sort out a new branch maintenance strategy. The current version of this is https://github.com/openssh-gsskex/openssh-gsskex/pull/23. (I don't think it's necessary to wait for review here; I've pulled that PR into my packaging in progress.) The second issue was that when I put together updated packaging and started my usual testing, I discovered that the SSH implementation in Twisted Conch doesn't support rsa-sha2-* signatures (https://twistedmatrix.com/trac/ticket/9765). I've actually known about this for a while but it had unfortunately slipped my mind. Fixing this requires first implementing RFC 8308 extension negotiation, which is currently pending review as https://github.com/twisted/twisted/pull/1666. The reason I care about this, beyond general interoperability, is that in my day job my team maintains some SSH endpoints which use Twisted Conch, and it would be personally very inconvenient if we had to suddenly start fielding lots of support requests due to the default OpenSSH configuration in Debian refusing to talk to them; so I realize that isn't necessarily compelling for everyone, but I'd rather hold off until I get this sorted out. (I might stick 8.8p1 packages in experimental before then, though.) I'll keep pushing on the Twisted issues, and hopefully we can get this sorted out soon. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#594175: openssh-server: support generation of ssh host keys in init script
On Tue, Oct 05, 2021 at 09:21:33PM +1100, Trent W. Buck wrote: > Michael Prokop wrote: > > Nowadays™ with systemd we use our own ssh.service, which looks like that: > > > > > > https://github.com/grml/grml-live/blob/8078724d5fa78f0b8fe0471b94368c58f204ee11/etc/grml/fai/config/files/etc/systemd/system/ssh.service/GRMLBASE > > Can we (Debian, not GRML) please just add > ExecStartPre=ssh-keygen -A > to Debian's default ssh.service? > Is there any DOWNSIDE to doing that? > It appears to be fully idempotent. I have always been extremely reluctant to do this because of the possible downsides explained in https://factorable.net/weakkeys12.extended.pdf. At the very least it requires lots of care to ensure that sufficient entropy is available; this can't be brushed off as something that we might be able to take care of later. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: OpenSSH 8.8 in Debian
On Mon, Sep 27, 2021 at 06:27:34PM +0200, Fabio Pedretti wrote: > OpenSSH 8.8 was recently released, with new features and fixes. > Notably, since 8.7, there is scp support using the SFTP protocol, > which will become the default in a "near-future release", and would be > nice to have some time to test it in Debian. > > Debian testing still has 8.4, can you please consider upgrading to 8.8? It's already on my list. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#994001: openssh-server: Almost locked out due #990456
On Thu, Sep 09, 2021 at 11:08:05AM -0400, Aristeu Rozanski wrote: > Jokes aside, I had 'ssh' group defined for a good while as to be used as > group of people allowed to ssh in the machine (AllowGroup, root login is > disabled) and a recent upgrade, probably due #990456, that group got renamed > as '_ssh' and I wasn't able to login anymore. Thankfully I had a session open > since before the change and was able to figure out what was going on. > > Please change the upgrade script to check if the group ssh already contains > users before doing the change. We can add some kind of check that would fail the installation in this situation, but please migrate to using some other site-specific group for this ASAP. The ssh/_ssh group is an internal implementation detail used only to ensure that private key material cannot be extracted from running ssh-agent processes using ptrace(2); it's not intended to have users added to it. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#992134: openssh FTBFS with glibc >= 2.34
On Thu, Aug 12, 2021 at 04:09:15PM -0500, William 'jawn-smith' Wilson wrote: > Due to an incompatible function prototype in the openbsd-compat tests, > this package FTBFS with glibc >= 2.34. There is already an upstream > commit to fix it, so I have pulled that in to this version of the > package. Thanks, I'll cherry-pick this too then. -- Colin Watson (he/him) [cjwat...@canonical.com]
Re: Processed: Bug#990456 marked as pending in openssh
On Sun, Jul 04, 2021 at 08:17:59AM +, Martin wrote: > Thanks for solving this so quickly, Colin! > > But doesn't need the `addgroup --system --quiet` also `--force-badname`, > if the group name starts with an underscore? Yes, a CI job pointed that out as well - fixed. > No harm done by `update_ssh_group_name()`, but maybe I would use > `if ! getent group _ssh >/dev/null; then` instead of > `if getent group ssh >/dev/null; then` just for the aesthetics (and to > prevent postinst failure, in case both `ssh` and `_ssh` already exist). The version check should deal with most of this in practice, but I've added a check for _ssh in addition (rather than "instead"). Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade
Control: reassign -1 libc6 2.31-12 Control: affects -1 openssh-server On Sat, Jul 03, 2021 at 11:36:49AM +0200, Olaf van der Spek wrote: > Op zo 20 jun. 2021 om 10:38 schreef Olaf van der Spek : > > So I think it's not accepting new connections from the start of the > > upgrade run until the end: > > Setting up openssh-sftp-server (1:8.4p1-5) ... > > Setting up console-setup (1.203) ... > > Setting up mime-support (3.66) ... > > Setting up openssh-server (1:8.4p1-5) ... > > Installing new version of config file /etc/init.d/ssh ... > > Installing new version of config file /etc/ssh/moduli ... > > Replacing config file /etc/ssh/sshd_config with new version > > rescue-ssh.target is a disabled or a static unit, not starting it. > > Hi Colin, > > Any thoughts on this? Sorry for my delay - it took me a while to spot the problem. libc6's postinst does arrange to restart services where needed, but in this case it doesn't realize that you have the ssh service installed because you only have the openssh-server package installed, not the ssh metapackage (i.e. the package with the same name as the service). I've proposed https://salsa.debian.org/glibc-team/glibc/-/merge_requests/3 to fix this. glibc maintainers, if there's any way to get this into bullseye, I'm sure it would help avoid some people upgrading remote systems ending up being unable to fix them if something goes wrong between configuring libc6 and configuring openssh-server. Also CCing debian-release for their information, as I know it's pretty late for glibc changes. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade
On Sat, Jun 19, 2021 at 12:53:48PM +0200, Olaf van der Spek wrote: > During a Debian 10 -> 11 upgrade, the SSH server doesn't appear to be > accepting new connections. IMO this is less than optimal, and not sure if > this was always the case. > Would it be possible to keep accepting connections, or at least to make the > time window in which SSH is down as short as possible? That's odd, because we already take care to do that. Any chance of some logs? I think the most useful things would be /var/log/dpkg.log, /var/log/apt/term.log, and the bits of "journalctl -b -u ssh.service" that show when sshd stopped and started. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#984940: CVE-2021-28041
On Sat, Mar 13, 2021 at 02:55:48PM +1100, Darren Tucker wrote: > On Sat, 13 Mar 2021 at 10:01, Colin Watson wrote: > > This patch unfortunately doesn't apply terribly cleanly to OpenSSH > > 8.4p1, [...] > > If I understand the vulnerability correctly, then it seems to me that > > the following shorter patch would fix it, and would run less risk of me > > fouling something else up by backporting the refactoring wrongly: > > There's a patch against 8.4 here: > https://ftp.openbsd.org/pub/OpenBSD/patches/6.8/common/015_sshagent.patch.sig > > It has the first of the two changes in your diff. The second is > harmless but unnecessary as it's on the exit path from the function > and there can't be a following call to free. Ah yes, indeed. I'll use that patch then. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#984940: CVE-2021-28041
On Wed, Mar 10, 2021 at 05:57:52PM +0100, Moritz Muehlenhoff wrote:
> The following vulnerability was published for openssh.
>
> CVE-2021-28041[0]:
> | ssh-agent in OpenSSH before 8.5 has a double free that may be relevant
> | in a few less-common scenarios, such as unconstrained agent-socket
> | access on a legacy operating system, or the forwarding of an agent to
> | an attacker-controlled host.
>
> Buster is not affected. Isolated patch at:
> https://github.com/openssh/openssh-portable/commit/e04fd6dde16de1cdc5a4d9946397ff60d96568db
This patch unfortunately doesn't apply terribly cleanly to OpenSSH
8.4p1, because it depends on some earlier refactoring, e.g.
37c70ea8d4f3664a88141bcdf0bf7a16bd5fd1ac.
If I understand the vulnerability correctly, then it seems to me that
the following shorter patch would fix it, and would run less risk of me
fouling something else up by backporting the refactoring wrongly:
diff --git a/ssh-agent.c b/ssh-agent.c
index e1fd1f3f6..b6ccbfb49 100644
--- a/ssh-agent.c
+++ b/ssh-agent.c
@@ -581,12 +581,14 @@ process_add_identity(SocketEntry *e)
goto err;
}
free(ext_name);
+ ext_name = NULL;
break;
default:
error("%s: Unknown constraint %d", __func__, ctype);
err:
free(sk_provider);
free(ext_name);
+ ext_name = NULL;
sshbuf_reset(e->request);
free(comment);
sshkey_free(k);
But I think I should probably check this with upstream before applying
it, so CCing openssh-unix-dev for review.
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#982950: ssh.service starts sshd before network is online: please switch to After=network-online.target instead of just After=network.target
On Wed, Feb 17, 2021 at 11:46:57AM +0100, Thomas Goirand wrote: > On 2/17/21 10:14 AM, Colin Watson wrote: > > On Wed, Feb 17, 2021 at 09:36:15AM +0100, Thomas Goirand wrote: > >> This means that, until FRR is fully up and running, with the BGP session > >> established, the server IP (10.x.x.x/32 bound to the loopback interface) > >> isn't > >> set yet on the server, and the ssh daemon cannot bind on the IP (as it's > >> not > >> there yet). > > > > Are you using ListenAddress in sshd_config? > > Yes, with the same IP as above, in order to make sure ssh isn't > listening on a public IP (which would be a security concern for us). Oh, that's vital information for this bug - using ListenAddress changes the constraints on sshd startup, somewhat as described in README.Debian. In that case I think this is at least arguably a case of needing to keep your configuration in sync, isn't it? You've made a change to sshd_config, so you need to change other parts of the system to support that change. I'd be happy to try to clarify documentation once we work out what works. > > See also > > https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/, which > > among other things (in general the tone of that page is that a > > well-written service should not use After=network-online.target) says: > > > > "If you write a server: listen on [::], [::1], 0.0.0.0 and 127.0.0.1 > > only. These pseudo-addresses are unconditionally available." > > > > That's what sshd does in its default configuration. If it doesn't work, > > the systemd documentation suggests that something else is not fulfilling > > its end of a contract somewhere. > > Maybe setting-up net.ipv4.ip_nonlocal_bind=1 (in sysctl.conf) would fix > my issue, no? That's the system-wide version of IP_FREEBIND. OpenSSH upstream seems to have decided not to support IP_FREEBIND (https://bugzilla.mindrot.org/show_bug.cgi?id=2512), but the sysctl should work if you're OK with it being system-wide. I'd also recommend at least considering other approaches to implementing your security policy that avoid the ordering complexities of ListenAddress, since there are other ways to prevent incoming connections on public IP addresses. Approaches I can think of include: * Reject connections to port 22 at the firewall level (perhaps a firewall on the local host). * It might be worth experimenting with Match LocalAddress in sshd_config. I haven't played with that much myself, and it's poorly-documented, but I *think* that might allow you to reject any connections that aren't directed to appropriate addresses. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#982950: ssh.service starts sshd before network is online: please switch to After=network-online.target instead of just After=network.target
Control: severity -1 important On Wed, Feb 17, 2021 at 09:36:15AM +0100, Thomas Goirand wrote: > Package: openssh-server > Version: 1:8.4p1-4 > Severity: grave No. It may yet need to be sorted out before release, but this is a rare situation and I'm not having it being release-critical right now, especially because it's not clear that it's openssh-server's problem. > On a Sid/Testing system, currently we have in /lib/systemd/system/ssh.service: > > After=network.target auditd.service > > While this isn't a problem in most installation, it didn't work under our > setup, > because we use "bgp-to-the-host" networking. In this setup, we need FRR (the > BGP routing daemon which is a fork of Quagga, if you didn't know) to provide > network connectivity to the server. Our configuration is something like this: > > # cat /etc/frr/frr.conf > [...] > ! > int lo > ip address 10.56.17.7/32 > ! > [...] > > This means that, until FRR is fully up and running, with the BGP session > established, the server IP (10.x.x.x/32 bound to the loopback interface) isn't > set yet on the server, and the ssh daemon cannot bind on the IP (as it's not > there yet). Are you using ListenAddress in sshd_config? Normally sshd doesn't require network interfaces to be online - it just binds to 0.0.0.0 or [::] and that's enough for it to be bound to interfaces as they come up. If lo has to be up for this to work (which is surprising to me, but maybe), then I think there's a decent argument for frr to be part of network.target on such systems. > Our fix was pretty simple: > > # cat /etc/systemd/system/ssh.service.d/override.conf > [Unit] > After=network-online.target auditd.service > > But IMO, this is very wrong to mandate doing this, and not having ssh > connectivity after a reboot, is kind of a grave problem. > > So, could you hard-wire this in the openssh-server package directly, so Debian > users can avoid such an override? Indeed After=network.target doesn't tell you > that network is ready. After=network-online.target does, and that's IMO what > the ssh daemon should be using. I don't agree that network-online.target is appropriate in general, from its documentation: network-online.target Units that strictly require a configured network connection should pull in network-online.target (via a Wants= type dependency) and order themselves after it. This target unit is intended to pull in a service that delays further execution until the network is sufficiently set up. What precisely this requires is left to the implementation of the network managing service. Note the distinction between this unit and network.target. This unit is an active unit (i.e. pulled in by the consumer rather than the provider of this functionality) and pulls in a service which possibly adds substantial delays to further execution. In contrast, network.target is a passive unit (i.e. pulled in by the provider of the functionality, rather than the consumer) that usually does not delay execution much. Usually, network.target is part of the boot of most systems, while network-online.target is not, except when at least one unit requires it. Also see Running Services After the Network is up[1] for more information. sshd does not in general require a configured network connection just to start up, and making it do so would be a pretty significant change to the unit dependency graph on most systems; it would make "is not [part of the boot process]" above typically untrue, for one thing. See also https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/, which among other things (in general the tone of that page is that a well-written service should not use After=network-online.target) says: "If you write a server: listen on [::], [::1], 0.0.0.0 and 127.0.0.1 only. These pseudo-addresses are unconditionally available." That's what sshd does in its default configuration. If it doesn't work, the systemd documentation suggests that something else is not fulfilling its end of a contract somewhere. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#982705: openssh: FTBFS: sha2.h:57:16: error: redefinition of ‘struct _SHA2_CTX’
On Mon, Feb 15, 2021 at 11:31:45AM +0100, Andreas Henriksson wrote: > On Mon, Feb 15, 2021 at 09:41:30AM +0000, Colin Watson wrote: > > FWIW, I think your patch in > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982705#25 is correct > > (even if I prefer to take a different approach as a workaround for the > > packaging) and could be forwarded upstream. Would you mind doing that? > > I normally prefer people to forward their own patches where possible so > > that there's no doubt about copyright/licensing intent or whatever. > > Agreed. The patch is fixing stuff in the non-portable version though > and I couldn't figure out how to contribute to that. The only > contribution info I could find lead to donating money to openbsd. IME: just send it as a bug on bugzilla.mindrot.org and they sort out which branch to apply it to. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#982705: openssh: FTBFS: sha2.h:57:16: error: redefinition of ‘struct _SHA2_CTX’
On Sun, Feb 14, 2021 at 12:49:29PM +0100, Andreas Henriksson wrote: > Attached is a possibly upstreamable patch that solves our problem > (but the base problem still exists in the code for anyone wishing to > build with openssl disabled). Thanks for digging into this. How about this approach instead? Given the choice between a packaging-only change and one that requires another patch against upstream, I have a slight preference for the packaging-only change as long as it's basically reasonable, which I think this is. It just overrides configure's automatic detection and tells it that sha2.h isn't available. Builds cleanly and doesn't seem to incur any new direct dependencies. diff --git a/debian/rules b/debian/rules index 73a53c309..44bac00f1 100755 --- a/debian/rules +++ b/debian/rules @@ -65,6 +65,10 @@ ifeq ($(DEB_HOST_ARCH_OS),hurd) confflags += --with-libs=-lcrypt endif +# Avoid using libmd even if it's installed; see +# https://bugs.debian.org/982705. +confflags += ac_cv_header_sha2_h=false + # Everything above here is common to the deb and udeb builds. confflags_udeb := $(confflags) Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#982392: ssh-copy-id: create ~/.ssh with default SELinux context
On Tue, Feb 09, 2021 at 05:55:00PM +0100, Christian Göttsche wrote: > ssh-copy-id(1) does create the directory ~/.ssh if it not already > exists. It also runs later, if available, restorecon(8) on the > directory, to correct the SELinux context of it. > It would however be idiomatic to create the directory already with the > default SELinux context, to prepare for restorecon failures and avoid > potential races. This code is run on the remote system. Therefore, won't this break ssh-copy-id against remote systems that lack mkdir -Z, such as systems with coreutils < 8.22 (released towards the end of 2013, which is certainly a while ago now but there are still systems in extended support that lack it, such as Ubuntu 14.04), or indeed systems with non-GNU versions of mkdir? I think it has to be done this way for portability, even if it's less idiomatic on systems with modern GNU coreutils. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#979970: libselinux1: dependency to newer libc6 ignored by/missing for aptitude
On Tue, Jan 26, 2021 at 01:44:47PM +0100, Julian Andres Klode wrote: > On Tue, Jan 26, 2021 at 12:52:52PM +0100, Aurelien Jarno wrote: > > The break hasn't been added randomly, but in response to upstream > > release notes and bug #965932. In short the openssh seccomp filters in > > buster are too narrow, and do not allow the new 64-bit syscalls needed > > for 64-bit time_t compatibility to be used. Would it help to get those seccomp filter fixes into buster, and then we could tell people that they have to upgrade to the latest point release first? Awkward but not unprecedented I think. > An alternative solution, for openssh-server would be to avoid using the > new syscalls for 64-bit time_t compatibility I assume (forcing it to > link with older symbol versions?), Changing openssh-server in bullseye can't possibly help here, because if you've upgraded openssh-server then that will include the updated seccomp filters anyway. Changing openssh-server in buster might help, but if so it would be much simpler to take the approach above (backporting the seccomp filter fixes) rather than doing symbol versioning hacks. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#978955: last update disables socket activation
Control: reassign -1 systemd On Sun, Jan 03, 2021 at 10:29:27AM +0100, Marc Haber wrote: > On Fri, Jan 01, 2021 at 11:21:31AM +0000, Colin Watson wrote: > > On Fri, Jan 01, 2021 at 06:59:42AM +0100, Marc Haber wrote: > > > with this last update of the Debian package, > > > unstable systems that are using socket activated > > > ssh lose ssh access (connection refused). > > > > > > It ie nscessary to do systemctl stop ssh.service, > > > systemctl start ssh.socket to be able to log in again. > > > > What exactly was the previous version that worked? 1:8.4p1-3 didn't go > > anywhere near any of the machinery for socket activation (it only > > involved a small fix to the ssh-copy-id shell script), so it's hard to > > see what could possibly have gone wrong there. > > > > Is it possible you upgraded some other piece of systemd-related > > machinery at around the same time? > > ok, this is interesting. While this has rendered _all_ my unstable > installations inaccessible via ssh, I have taken a closer look on the > most simple machine, and have found out openssh didn't get upgraded > during the apt session in question. Last ssh upgrade was on December 05 > when 1:8.4p1-3 replaced 1:8.4p1-2. > > However there was a systemd upgrade from 247.2-2 to 247.2-3. > > I have saved the dpkg log in question. If there is anything more I can > do to help, please let me know. I'll reassign this to systemd and see if they can work it out. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#978955: last update disables socket activation
On Fri, Jan 01, 2021 at 06:59:42AM +0100, Marc Haber wrote: > with this last update of the Debian package, > unstable systems that are using socket activated > ssh lose ssh access (connection refused). > > It ie nscessary to do systemctl stop ssh.service, > systemctl start ssh.socket to be able to log in again. What exactly was the previous version that worked? 1:8.4p1-3 didn't go anywhere near any of the machinery for socket activation (it only involved a small fix to the ssh-copy-id shell script), so it's hard to see what could possibly have gone wrong there. Is it possible you upgraded some other piece of systemd-related machinery at around the same time? -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#977245: openssh-server: Kernel error after big rsync or scp
Control: reassign -1 linux On Sat, Dec 12, 2020 at 09:53:23PM -0500, Gabe wrote: > After attempting to scp or rsync a directory with many large-ish files > (20-600M) to a remote host, the remote machine will crash. This hasn't > happened > with smaller file transfers; only when the directory contains gigabytes of > data, after about 3GB have been copied. I tried once to scp a similar ammount > of data from a different client to the same machine, with the same result. The > commands used were: > > scp -r ./localdirectory jgmanilla@remotehost:~/ > rsync -avP ./localdirectory jgmanilla@remotehost:~/ > > If you happened to be logged into an ssh session, you may get the following > message before the system goes down: > > Message from syslogd@localhost at Dec 12 16:22:24 ... >kernel:[ 406.101940] Internal error: Oops: 9604 [#1] SMP > > Message from syslogd@localhost at Dec 12 16:22:24 ... >kernel:[ 406.130105] Code: b9402a62 f9405e63 8b020014 dac00e81 > (f8626814) > > Expected outcome was for scp and rsync to complete their file transfers > with no errors. > > The hardware of the remote machine was a RockPro64. > The client operating systems tested were Gentoo and Arch linux. In general kernel oopses are kernel bugs, not userspace bugs, so reassigning to linux. I expect that the full contents of the oops message from syslog would be helpful to the kernel maintainers. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: OpenSSH buster-backport with libfido2 support
On Mon, Oct 19, 2020 at 07:15:17AM +, Mike Gabriel wrote: > a customer of mine is interested in a Debian backport of OpenSSH and > libfido2 from bullseye to Debian buster(-backports). The customer is ready > to cover the costs for bpo-maintenance over the full buster-backports > release cycle period, and thus, the required package updates in buster-bpo > on the way. > > I'd like to follow the Debian development flow of the openssh and libfido2 > packages when doing this (i.e. maintaining the uploaded bpo packages on a > Git branch), if ok on your side. I might need Git repo access for both > projects for easily doing this. > > @Colin: as the main uploader of openssh et al. in Debian. Would you be ok > with this? As per IRC discussion, I've granted you access to both repositories. Go ahead. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#950473: Please stop using deprecated and headers
On Sun, May 31, 2020 at 05:30:30PM +0200, Laurent Bigonville wrote: > libselinux 3.1 rc1 has been uploaded in experimental and I'm planning to > upload the final version in unstable as soon as it's released in the > upcoming days/weeks. > > Could you please make sure that your package is ready? This will make your > package FTBFS as the and > headers will be gone. Ugh, sorry for the inconvenience - I'd neglected to subscribe to openssh-ssh1 bugs and so didn't notice this report. Fixing now. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#965180: openssh-server: Incompatible with libc6=2.31-1, doesn't allow to login!
On Fri, Jul 17, 2020 at 10:29:18AM +0200, Philipp Marek wrote: > Package: openssh-server > Version: 1:7.9p1-10+deb10u2 > Severity: critical > Justification: breaks the whole system > > > Updating libc on stable breaks sshd; it dies with a SIGSYS on > clock_nanosleep. I agree it might be worth backporting this fix, but why would you be updating libc on stable? (The only reason I can think of would be partial upgrades to bullseye, which is hardly Severity: critical yet.) -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#965086: ssh: setgroups: Bad address [preauth]
On Wed, Jul 15, 2020 at 10:41:11PM +0200, Thorsten Glaser wrote:
> Package: openssh-server
> Version: 1:8.3p1-1
> Severity: grave
> Justification: renders package unusable
>
> After an upgrade of libc6 today, I can no longer log into my
> system using ssh:
Would it perhaps make sense to reassign this to libc6 first, unless and
until it seems to be a definite bug in OpenSSH? I'd have thought that
this sort of compatibility break would be a glibc bug in any event (if
nothing else it'd need a Breaks even if the fix is in OpenSSH), perhaps
unless OpenSSH is doing something clearly undefined.
Looking at your -ddd output, the failure must be within
sshd.c:privsep_preauth_child. But its setgroups() call seems
straightforward, and I don't see how it could produce EFAULT:
gid_t gidset[1];
[...]
gidset[0] = privsep_pw->pw_gid;
if (setgroups(1, gidset) == -1)
fatal("setgroups: %.100s", strerror(errno));
Is it possible that this is x32-specific in some way? I haven't been
able to reproduce it on amd64 so far. The implementation of setgroups()
also doesn't seem to have changed between the glibc-2.30 and glibc-2.31
tags upstream, though I haven't looked at the Debian patches.
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#961311: ssh-agent.service: cannot work without x11-common installed
On Sat, May 23, 2020 at 08:18:55PM +0800, Paul Wise wrote: > On Sat, 2020-05-23 at 13:07 +0100, Colin Watson wrote: > > What do you think? > > I don't think that will work because neither of the DISPLAY nor > WAYLAND_DISPLAY environment variables are set for user services since > they are user services *not* session services and systemd does not > support session services. OK, fair point. > You could of course check the session type, but I'm not sure what sets > that environment variable and if it is present for all Wayland > compositors. It is also a per-session variable rather than per-user > variable. So I think my idea of checking if Xsession.options exists is > best after all. My concern about that is that it's about what's installed, not what's active/running for that particular user. It may not matter in your case but I'm sure cutting that corner is going to be wrong for somebody. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#961311: ssh-agent.service: cannot work without x11-common installed
On Sat, May 23, 2020 at 09:45:55AM +0800, Paul Wise wrote:
> On pure-Wayland systems, the ssh-agent.service is not going to be able
> to start because x11-common won't nessecarily be installed. I think
> either the ConditionPathExists should get dropped and the script should
> check if the Xsession.options file exists before using it, when it
> doesn't exist people using Wayland without x11-common installed can just use
> `systemctl --user mask/enable/disable` to manage the service.
Hm. I'm somewhat inclined to do something like this. What do you
think?
(I'm aware using loginctl to figure out the session type might be more
technically correct. On the other hand, I seem to be suffering from
something similar to
https://askubuntu.com/questions/1238984/ubuntu-20-04-xdg-seat-xdg-vtnr-xdg-session-id-env-variables-are-not-set
here, so can't easily test it. Besides, checking the environment
variables is likely faster, so as long as it isn't hopelessly wrong ...)
diff --git a/debian/agent-launch b/debian/agent-launch
index 3b2abdbf7..75f185b72 100755
--- a/debian/agent-launch
+++ b/debian/agent-launch
@@ -8,8 +8,23 @@ if [ ! -d "$XDG_RUNTIME_DIR" ]; then
exit 1
fi
+session_is_x11 () {
+[ "$DISPLAY" ] && [ -z "$WAYLAND_DISPLAY" ]
+}
+
+session_uses_ssh_agent () {
+if session_is_x11; then
+grep -s -q '^use-ssh-agent$' /etc/X11/Xsession.options
+else
+# Users of non-X11 sessions can use "systemctl --user mask
+# ssh-agent.service" or similar to control whether this service
+# should run.
+return 0
+fi
+}
+
if [ "$1" = start ]; then
-if [ -z "$SSH_AUTH_SOCK" ] && grep -s -q '^use-ssh-agent$'
/etc/X11/Xsession.options; then
+if [ -z "$SSH_AUTH_SOCK" ] && session_uses_ssh_agent; then
S="$XDG_RUNTIME_DIR/openssh_agent"
dbus-update-activation-environment --verbose --systemd
SSH_AUTH_SOCK="$S" SSH_AGENT_LAUNCHER=openssh
exec ssh-agent -D -a "$S"
diff --git a/debian/systemd/ssh-agent.service b/debian/systemd/ssh-agent.service
index cdc10bb47..4d5d3faf8 100644
--- a/debian/systemd/ssh-agent.service
+++ b/debian/systemd/ssh-agent.service
@@ -2,7 +2,6 @@
Description=OpenSSH Agent
Documentation=man:ssh-agent(1)
Before=graphical-session-pre.target
-ConditionPathExists=/etc/X11/Xsession.options
Wants=dbus.socket
After=dbus.socket
> PS: shellcheck reports some issues for the agent-launch script.
Fixed in git master, thanks.
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#958240: /usr/bin/ssh: ssh client should process arguments in the command line order
On Mon, Apr 20, 2020 at 12:04:57AM +, Witold Baryluk wrote: > $ ssh 10.0.0.1 -l baryluk -X -l root > baryluk@10.0.0.1's password: > > > > Well, that is wrong. The last parameter overwrite should win. Would you mind please filing this upstream at https://bugzilla.mindrot.org/, and then we can mark it forwarded here? It's not something we're going to change specifically in Debian. While I could file it upstream on your behalf, it's often better if the original reporter does so, because then upstream developers can talk to you directly rather than me having to be an inefficient go-between if there are any questions or disputes. Thanks, -- Colin Watson [cjwat...@debian.org]
Bug#954965: /etc/ssh/ssh_config: ssh_config: Include custom config files at the end, so they can overwrite the default settings
On Wed, Mar 25, 2020 at 10:33:20PM +0100, Jan wrote: > /etc/ssh/ssh_config now includes /etc/ssh/ssh_config.d/*.conf but does so > at the beginning. Thus custom config files cannot overwrite the default > options, all of which are set afterwards. But, as ssh_config(5) says, "the first obtained value for each parameter is used". I tested this and confirmed that it was possible to use files in /etc/ssh/ssh_config.d/*.conf to override default options in /etc/ssh/ssh_config. What tests did you perform? -- Colin Watson [cjwat...@debian.org]
Bug#951582: new upstream (8.2) for fido support
On Tue, Feb 18, 2020 at 12:29:08PM +0100, Daniel Baumann wrote: > I'm very much looking forward to get openssh 8.2 to test the fido > support in order to improve the security of my SSH keys. It would be > super nice if you could upload it to sid. Yep, already working on it :-) -- Colin Watson [cjwat...@debian.org]
Bug#948710: openssh-server: Fail to upgrade "ssh.service: Unit -.mount is masked"
Control: reassign -1 systemd 244-3 On Sun, Jan 12, 2020 at 02:48:39PM +0100, Christian Marillat wrote: > Setting up openssh-server (1:8.1p1-5) ... > rescue-ssh.target is a disabled or a static unit, not starting it. > Failed to restart ssh.service: Unit -.mount is masked. > invoke-rc.d: initscript ssh, action "restart" failed. > * ssh.service - OpenBSD Secure Shell server > Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: > enabled) > Active: active (running) since Sat 2020-01-11 08:26:51 CET; 1 day 6h ago >Docs: man:sshd(8) > man:sshd_config(5) >Main PID: 1119 (sshd) > Memory: 3.7M > CGroup: /system.slice/ssh.service > `-1119 /usr/sbin/sshd -D The OpenSSH units don't make any reference to a -.mount unit (explicitly or implicitly, as far as I can tell), so I can only assume that this is some kind of bug in systemd itself; reassigning over there. Feel free to reassign back if it seems that this is a bug in ssh.service after all, but in that case I'd appreciate some kind of specific advice on what it's doing wrong. (I upgraded a test system that I deliberately keep in a clean state for this sort of thing, and it worked fine for me.) -- Colin Watson [cjwat...@debian.org]
Bug#946242: fatal: privsep_preauth: preauth child terminated by signal 31
On Sat, Jan 11, 2020 at 01:20:49PM +, Colin Watson wrote: > I have some other things to do this weekend, but I'll chase this up with > upstream and arrange for this to get into appropriate Debian packages. It turned out that upstream had committed a fix a few days ago [1], so I cherry-picked that into unstable and have filed a stable update request as https://bugs.debian.org/948695. [1] https://anongit.mindrot.org/openssh.git/commit/?id=30f704ebc0e9e32b3d12f5d9e8c1b705fdde2c89 -- Colin Watson [cjwat...@debian.org]
Bug#946242: fatal: privsep_preauth: preauth child terminated by signal 31
Ian Jackson (CCed) just ran into this and we debugged it together on
IRC. This turns out to be a variant of https://bugs.debian.org/941663
that only affects certain architectures, because glibc implements
shmget/shmat/shmdt using the ipc syscall on certain architectures. For
example, shmget is:
int
shmget (key_t key, size_t size, int shmflg)
{
#ifdef __ASSUME_DIRECT_SYSVIPC_SYSCALLS
return INLINE_SYSCALL_CALL (shmget, key, size, shmflg, NULL);
#else
return INLINE_SYSCALL_CALL (ipc, IPCOP_shmget, key, size, shmflg, NULL);
#endif
}
And:
sysdeps/unix/sysv/linux/i386/kernel-features.h:#undef
__ASSUME_DIRECT_SYSVIPC_SYSCALLS
sysdeps/unix/sysv/linux/kernel-features.h:#define
__ASSUME_DIRECT_SYSVIPC_SYSCALLS 1
sysdeps/unix/sysv/linux/m68k/kernel-features.h:#undef
__ASSUME_DIRECT_SYSVIPC_SYSCALLS
sysdeps/unix/sysv/linux/mips/kernel-features.h:# undef
__ASSUME_DIRECT_SYSVIPC_SYSCALLS
sysdeps/unix/sysv/linux/powerpc/kernel-features.h:#undef
__ASSUME_DIRECT_SYSVIPC_SYSCALLS
sysdeps/unix/sysv/linux/s390/kernel-features.h:#undef
__ASSUME_DIRECT_SYSVIPC_SYSCALLS
sysdeps/unix/sysv/linux/sh/kernel-features.h:#undef
__ASSUME_DIRECT_SYSVIPC_SYSCALLS
sysdeps/unix/sysv/linux/sparc/kernel-features.h:#undef
__ASSUME_DIRECT_SYSVIPC_SYSCALLS
I think a fix for this that applies to buster would be:
diff --git a/sandbox-seccomp-filter.c b/sandbox-seccomp-filter.c
index e8f31555e..121760418 100644
--- a/sandbox-seccomp-filter.c
+++ b/sandbox-seccomp-filter.c
@@ -134,6 +134,9 @@ static const struct sock_filter preauth_insns[] = {
#ifdef __NR_fstat64
SC_DENY(__NR_fstat64, EACCES),
#endif
+#ifdef __NR_ipc
+ SC_DENY(__NR_ipc, EACCES),
+#endif
#ifdef __NR_open
SC_DENY(__NR_open, EACCES),
#endif
I have some other things to do this weekend, but I'll chase this up with
upstream and arrange for this to get into appropriate Debian packages.
--
Colin Watson [cjwat...@debian.org]
Bug#946997: /usr/sbin/sshd: sshd doesn't restart after dying
On Thu, Dec 19, 2019 at 09:38:11AM +0100, Xavier Bestel wrote: > When sshd dies, it doesn't restart which makes the machine unreachable. > E.g. try "sudo killall sshd", and voilà you can't use a headless machine > anymore. > > Could this be fixed ? I see from the information that reportbug attached that you're using systemd. As far as I can tell, systemd doesn't have a way to express this in the particular example you gave. killall will kill processes using SIGTERM by default, and systemd considers that to be a deliberate administrative action, i.e. "you meant to do that", so Restart=on-failure won't apply. This seems correct to me. However, if you kill sshd in an unclean way, for example by sending SIGKILL, then systemd *will* restart it. systemd.service(5) says: If set to on-failure, the service will be restarted when the process exits with a non-zero exit code, is terminated by a signal (including on core dump, but excluding the aforementioned four signals [SIGHUP, SIGINT, SIGTERM or SIGPIPE]), when an operation (such as service reload) times out, and when the configured watchdog timeout is triggered. It feels like you filed a reduced bug report based on something more complex happened in real life. If so, could you share the more complex version? -- Colin Watson [cjwat...@debian.org]
Bug#946242: fatal: privsep_preauth: preauth child terminated by signal 31
On Sat, Dec 07, 2019 at 04:52:19PM +0100, Bernhard Übelacker wrote: > I could reproduce the issue in a i386 qemu VM with > a downgraded 3.16-3-686-pae kernel. > Attached file contains a debug session. > > At the sysenter instruction in function shmdt > the signal SIGSYS is received. Since you're building it locally already, it would be helpful if you could follow the debugging instructions in a comment near the top of sandbox-seccomp-filter.c (either the auditctl approach, or if that doesn't work on such an old kernel, the ""uncomment this macro" approach). -- Colin Watson [cjwat...@debian.org]
Bug#945295: Unnecessary "invalid attribute length" and "failed to fetch key" warnings with libsimple-tpm-pk11.so
On Fri, Nov 22, 2019 at 06:08:01PM +0100, Didier 'OdyX' Raboud wrote: > For some time now, ssh (openssh-client) unnecessarily warns for: > > > invalid attribute length > > failed to fetch key > > when SSH'ing to a host with libsimple-tpm-pk11.so as PKCS11Provider. > > Relevant lines from a verbose connection: > > $ ssh -vvv -oPKCS11Provider=libsimple-tpm-pk11.so ssh.example.com > … > debug1: Connecting to (…) > debug1: Connection established. > debug1: provider libsimple-tpm-pk11.so: manufacturerID manufacturer> cryptokiVersion 0.1 libraryDescription library> libraryVersion 0.1 > debug1: provider libsimple-tpm-pk11.so slot 0: label > manufacturerID model serial flags 0x400 > debug1: have 1 keys > invalid attribute length > failed to fetch key > … > debug1: Will attempt key: libsimple-tpm-pk11.so RSA > SHA256:(xxx-hash-of-my-tpm-key-xxx) token > … > > This was initially reported at > https://github.com/ThomasHabets/simple-tpm-pk11/issues/48, > and brought to Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1710832, > which fixed it. I haven't looked very far into this yet, but as far as I can tell that Fedora bug is *not* the same thing. Fedora carries a patch set that asks for the CKA_LABEL attribute, and that bug was because it was (apparently incorrectly) requiring that attribute to have non-zero length. However, Debian does not carry that patch. If you're seeing these errors in the RSA case, it's because at least one of CKA_MODULES or CKA_PUBLIC_EXPONENT is coming back as empty. -- Colin Watson [cjwat...@debian.org]
Re: Bug#941688: marked as done (openssl 1.1.1d security update breaks openssh login on old kernels)
On Sat, Oct 05, 2019 at 10:58:18PM +0200, Sebastian Andrzej Siewior wrote: > On 2019-10-05 21:34:22 [+0200], Salvatore Bonaccorso wrote: > > Or maybe it would be worth as an option to reassign to src:openssh an > > for such cases as for the reporter (if Colin is open to it obviously) > > to have it backported for a point release update? > > Could you please take look at > https://bugs.debian.org/941688 > > and say what you think about backporting it for stable as Salvatore > suggested? Hi, Looks like we raced on this - I'm already tracking this in https://bugs.debian.org/941663, and I just filed https://bugs.debian.org/941810 with a stable update request. Could you please follow up on the latter if you have views on where the update should go? > It affects people with a pre-v3.19 kernel running Buster. I could do > some testing if you want me to. That would be useful, thanks. -- Colin Watson [cjwat...@debian.org]
Bug#941663: openssh-server: fatal: privsep_preauth: preauth child terminated by signal 31
On Sat, Oct 05, 2019 at 08:21:09PM +0100, Adam D. Barratt wrote: > On Sat, 2019-10-05 at 12:16 -0400, James Cloos wrote: > > Using ed25519 keys (host and client) should work around this issue. > > FWIW according to #941665, this should also only affect users running > buster on kernels < 3.19. Thanks for the clue. I'll cherry-pick this into unstable now, and I've also filed a stable update request. -- Colin Watson [cjwat...@debian.org]
Bug#909374: sshd: syslogin_perform_logout: logout() returned an error
On Sat, Sep 22, 2018 at 07:39:40PM +0200, Christian Göttsche wrote: > When I logout from my SELinux enabled machine, I get the following > error message: > > Sep 22 19:23:52 server02 sshd[23234]: syslogin_perform_logout: > logout() returned an error <--- > Sep 22 19:23:52 server02 sshd[23234]: Received disconnect from > port 53300:11: disconnected by user > Sep 22 19:23:52 server02 sshd[23234]: Disconnected from user root > port 53300 > Sep 22 19:23:52 server02 sshd[23234]: pam_unix(sshd:session): session > closed for user root > > Nothing seems to break but what's the cause of this? Is it possible that the SELinux profile for sshd is denying it the ability to write to /var/run/utmp? (I think that's the path.) I don't use SELinux myself, but perhaps it has some debugging tools that would make it possible to see what accesses have been denied? > Maybe the error message > [https://sources.debian.org/src/openssh/1:7.8p1-1/loginrec.c/#L1433] > can be improved? Unfortunately logout() doesn't give sshd a way to get any more information that it could put in the error message; it just returns 1 on success and 0 on failure. -- Colin Watson [cjwat...@debian.org]
Bug#941443: openssh-client: Causes terminal corruption by disabling XON/XOFF unconditionally
On Mon, Sep 30, 2019 at 10:55:13AM -0500, John Goerzen wrote: > I am using an original DEC vt420 serial terminal connected to a Debian > box. As with many such terminals, it: [...] Hi, I think this needs to be forwarded upstream. I'm often happy to do that on people's behalf when I understand a bug well and/or can reproduce it, but in this case neither of those things is true. I also suspect that working out the best fix is going to involve some back-and-forth between you and upstream, and I'm going to add very little to that process other than being a rather slow proxy. Would you consider filing this directly upstream (https://bugzilla.mindrot.org/)? I know it's another account to create, but I think it would work better. Thanks, -- Colin Watson [cjwat...@debian.org]
Bug#935939: Does not respect local admin changes and recreates files in /etc/sv
Control: reassign -1 dh-runit Control: affects -1 openssh-server On Wed, Aug 28, 2019 at 09:42:31AM +0200, Michael Biebl wrote: > Since I have no use for runit, I removed the /etc/sv directory. > Unfortunately, if the openssh-server package is upgraded (or > reinstalled), the local admin choice is not respected and the files in > /etc/sv are recreated. > I have no idea if this is a bug in openssh-server or runit, please > reassign as necessary. Filed against openssh-server, since it is the > package exposing this behaviour. There's no maintainer script code (generated or otherwise) pertaining to /etc/sv; most of the files in there are just dpkg-handled conffiles. And it's not quite true that the files are recreated - the conffiles aren't. The exceptions are /etc/sv/ssh/supervise and /etc/sv/ssh/log/supervise, which are symlinks to /var/lib/runit/supervise/ssh and /var/lib/runit/log/supervise/ssh respectively, and those do get reinstalled. Symlinks can't really be conffiles, but perhaps this could be done using generated maintainer script code or in runit-helper? Reassigning to dh-runit, anyway, since there isn't much I can do about this in openssh-server at present. Empty directories also come back no matter what you do, so even after fixing this, /etc/sv/ssh/.meta and /etc/sv/ssh/log would still come back. But that's something you'd need to bring up with the dpkg maintainers; I don't know whether they'd consider it a bug. -- Colin Watson [cjwat...@debian.org]
Bug#935936: openssh-client should not depend on runit-helper
On Wed, Aug 28, 2019 at 12:35:52AM -0700, Josh Triplett wrote: > openssh-client 1:8.0p1-5 introduces a dependency on runit-helper. As the > *client* doesn't contain any runit script, it should not pull in any > such dependency. I'd guess that the dependency got added to every binary > package built from the openssh source package, rather than only to the > relevant binary package. Thanks - fixing. > (The server really shouldn't have that dependency, either, on platforms > that don't have runit installed, but that's a separate problem. Is there > any particular reason runit-helper couldn't just become a dependency of > runit, and then handle all installed packages when you install runit?) That would be something to bring up with the dh-runit maintainers. But fortunately it's a tiny package with no dependencies. -- Colin Watson [cjwat...@debian.org]
Bug#933999: openssh-server: please provide a runscript for runit
On Mon, Aug 05, 2019 at 11:07:47PM +0200, Lorenzo Puliti wrote: > here is a patch to add support for Runit initialization system. [...] > the git patch is attached, and there is also a MR on salsa > https://salsa.debian.org/ssh-team/openssh/merge_requests/7 Thanks for the contribution! I've followed up to the MR with a detailed review. -- Colin Watson [cjwat...@debian.org]
Bug#933665: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedKeyTypes
On Thu, Aug 01, 2019 at 08:32:54AM -0700, Gerald Turner wrote: > I've been running several servers, upgraded across many Debian stable > releases, with sshd_config that had been tightened down in various ways > (example attached) including explicit PubkeyAcceptedKeyTypes (containing > ssh-rsa). After upgrading to buster a user reported that he could no > longer login with his RSA key. > > sshd[17025]: userauth_pubkey: key type ssh-rsa not in > PubkeyAcceptedKeyTypes [preauth] > > I tested and found that explicitly defining PubkeyAcceptedKeyTypes in > sshd_config breaks RSA pubkey auth, even when the line merely states: > > PubkeyAcceptedKeyTypes ssh-rsa This is the scenario explained in the entry in /usr/share/doc/openssh-server/NEWS.Debian.gz for version 1:7.8p1-1, which was reproduced from upstream's release notes for OpenSSH 7.8: * sshd(8): The semantics of PubkeyAcceptedKeyTypes and the similar HostbasedAcceptedKeyTypes options have changed. These now specify signature algorithms that are accepted for their respective authentication mechanism, where previously they specified accepted key types. This distinction matters when using the RSA/SHA2 signature algorithms "rsa-sha2-256", "rsa-sha2-512" and their certificate counterparts. Configurations that override these options but omit these algorithm names may cause unexpected authentication failures (no action is required for configurations that accept the default for these options). I regret the inconvenience of the change, but given that it seems to have been a deliberate change upstream (mentioned in their release notes), I think it would be best to adapt to it. The debug output you quote is indeed a bit misleading (I think I'll take that up with upstream), but there's a clue hiding in the successful debug output: sshd[20199]: debug1: userauth_pubkey: test pkalg rsa-sha2-512 pkblob RSA SHA256:cN6+RJMBj25zximZ28B/CanFpjupWf/ABGrRGprS1LU [preauth] Note that the default for PubkeyAcceptedKeyTypes now ends with "rsa-sha2-512,rsa-sha2-256,ssh-rsa" rather than just "ssh-rsa". Therefore, things should work again if you set "PubkeyAcceptedKeyTypes rsa-sha2-512,rsa-sha2-256,ssh-rsa". Let me know if that works? -- Colin Watson [cjwat...@debian.org]
Bug#932281: Antw: Re: Bug#932281: /usr/bin/ssh: slogin and ssh behave different at starting remote mathematica session
On Wed, Jul 17, 2019 at 01:49:34PM +0200, Markus Hetzmannseder wrote: > >> Please add -vvv to both commands so that we can compare the debugging > >> output. > > Ok, i have done the same command sequence with: > > ssh -vvv offenbach 2> ssh.log > and > login -vvv offenbach 2> slogin.log > > the two logfiles are attached to this mail. OK, nothing obvious there, and I can't think of what else could possibly matter. It's worth checking for things like shell aliases that might be affecting it - try "type ssh" and "type slogin". Otherwise, I don't really have a useful way to reproduce this ... -- Colin Watson [cjwat...@debian.org]
Bug#932281: /usr/bin/ssh: slogin and ssh behave different at starting remote mathematica session
On Wed, Jul 17, 2019 at 11:52:50AM +0200, Markus Hetzmannseder wrote: > I found a problem to start mathematica (version 12.0) on a remote server via > slogin-command to do the login an the remote server. As far as i can see the > ssh-command and the slogin-command should behave identicall, because slogin > is just a symbolic link to ssh. > > How i can reproduce the bug on my network: > > haydn:~ $ ssh offenbach # ssh login to remote server > offenbach:~ $ xterm # X-forward test via simple xterm, xterm opens up > offenbach:~ $ mathematica# after closing xterm, startup mathematica > version 12.0, working > offenbach:~ $ exit # after closing mathematica, logout > > haydn:~ $ slogin offenbach # ssh login to remote server, now with slogin > command > offenbach:~ $ xterm# xterm working again > offenbach:~ $ mathematica# now no mathematica window is coming up and i > have to kill the > # hanging mathematica process (its the same with > older version 11.3 too) > > I cant see where this difference between ssh and slogin is coming from. I > could not find other built in programms from the debian distribution itself > to reproduce this. Please add -vvv to both commands so that we can compare the debugging output. -- Colin Watson [cjwat...@debian.org]
Bug#932089: openssh-server: Cannot log into openssh-server on buster/mipsel
On Sun, Jul 14, 2019 at 10:26:05PM -0700, Francois Marier wrote: > $ auditctl -a exit,always -F uid="$(id -u sshd)" > Error - audit support not in kernel > Cannot open netlink audit socket > > Looks like I might be missing some kernel features. Perhaps sandboxing in > openssh also relies on something that's not compiled in either? Is there an > easy way to check? audit was something that would have made this easier to debug, but isn't required for normal functionality. Now that you mention it, though, I do see this in your log: debug1: ssh_sandbox_child: prctl(PR_SET_SECCOMP): Invalid argument [preauth] ... which suggests that CONFIG_SECCOMP or CONFIG_SECCOMP_FILTER may be disabled in your kernel. However, openssh should just fall back to not using seccomp sandboxing in that case. It should make it easier to debug though! Perhaps you could run sshd under strace and we might be able to see where it goes wrong there? (Be careful with the strace output, as it will contain secrets such as the private host key.) > By the way, this machine is sadly not using a Debian kernel. It's using > librecmc-ramips-mt7621-gb-pc1-squashfs-sysupgrade_2017-11-28.bin from > https://github.com/gnubee-git/gnubee-git.github.io/blob/master/debian/. I hope that the source for this is available somewhere and that it isn't just a GPL violation? I couldn't easily find the source. -- Colin Watson [cjwat...@debian.org]
Bug#932089: openssh-server: Cannot log into openssh-server on buster/mipsel
On Sun, Jul 14, 2019 at 02:22:21PM -0700, Francois Marier wrote: > $ systemctl stop sshd > $ mkdir /run/sshd > $ /usr/sbin/sshd -ddd (You might find it more convenient to temporarily run sshd on a high port using the -p option, rather than having to stop the system's sshd service.) > debug3: user_specific_delay: user specific delay 0.000ms [preauth] > debug1: monitor_read_log: child log fd closed Judging from this, the crash (or is it a hang? I'm assuming a crash) is near the start of ensure_minimum_time_since, probably inside monotime_ts. I suspect there's something wrong with the seccomp sandboxing of the privileged monitor process on mipsel. Could you try installing the auditd package, and then running this before starting sshd: auditctl -a exit,always -F uid="$(id -u sshd)" (Replace -a with -d to undo this.) You should then get a log of syscalls made by sshd's privileged monitor process in /var/log/audit/audit.log; I'd like the lines containing the string 'exe="/usr/sbin/sshd"'. > 6. I explicitly disabled the sandbox using `UsePrivilegeSeparation yes` as > per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868009. You're right that this would once have been a good test to run to exclude the possibility of a seccomp sandbox bug. However, the ability to configure UsePrivilegeSeparation was withdrawn in OpenSSH 7.5, so this test is now ineffective. Thanks, -- Colin Watson [cjwat...@debian.org]
Bug#931631: Wrong dependency on virtual logind packages
On Tue, Jul 09, 2019 at 12:44:20AM +0200, Michael Biebl wrote: > Am 08.07.19 um 18:13 schrieb Colin Watson: > > CCing Adam, who suggested the default-logind | logind part of this; I > > know very little about elogind myself. > > > > I can see how an "artificial" dependency like this might make sense to > > avoid libpam-systemd being pulled in for people who aren't using > > systemd, though, even if other logind implementations don't provide the > > same session registration features. > > Well, if that is the sole reason why that alternative dependency was > added, then this is a poor choice. Assuming that my attempt to restate the requirement is correct, what's your concrete alternative proposal, implementable in openssh, that also satisfies that requirement? I'm not enthusiastic about simply reverting the change from #923199, unless the people who requested it tell me that it's not in fact needed. > Also, it would have been a good idea to mention that in the changelog. To be fair I'm reverse-engineering this from bug records and the like; it didn't seem a big deal to me at the time, so I didn't work out all the details sufficiently to describe them in the changelog. > What you really want to fix is apt trying to satisfy a recommends over > uninstalling/installing a new init system (which tbh I find kinda odd, > that apt prefers to uninstall a package over not installing a recommends). It's not in my power to change apt's dependency resolution in a reasonable time frame. > And also, this alternative dependency is completely useless if you don't > already have elogind installed, which I suspect is the case (about 1% > have sysvinit installed, the number for elogind is only statistic noise). Well, I may also have made a wrong guess as to the underlying reason for the request, so hopefully Adam can fill in more detail. -- Colin Watson [cjwat...@debian.org]
Bug#931272: openssh-server: incoming connections fail if openssl's afalg engine is enabled
On Sun, Jun 30, 2019 at 05:25:42AM -0300, Emilio López wrote: > After enabling afalg engine on OpenSSL and configuring OpenSSH server to use > the following > ciphers, incoming ssh connections stop working. When a client tries to > connect, you can > observe the following message on the server's dmesg output: > > [271686.264598] audit: type=1326 audit(1561879548.303:14): auid=1000 > uid=104 gid=65534 ses=99 subj==unconfined pid=8164 comm="sshd" > exe="/usr/sbin/sshd" sig=31 arch=4028 syscall=281 compat=0 ip=0xb6a5ee6c > code=0x0 > > The device is a Buffalo Linkstation LS-WXL (armel, kirkwood). I would like to > use the crypto > hardware accelerator (marvell_cesa) on SSH to get better performance out of > it, that's why > I enabled the afalg engine. > > This happens both with openssh-server from buster and experimental. Syscall > 281 appears to be > socket(...) from what I could gather. Maybe it is necessary to add a few more > allowed syscall > rules to the seccomp sandbox in OpenSSH? Thanks for your report. Would you mind filing this directly upstream? This is the sort of thing I'd much rather get upstream review of. https://bugzilla.mindrot.org/ Thanks, -- Colin Watson [cjwat...@debian.org]
Bug#905226: Acknowledgement (openssh-server: SSH AuthorizedKeysCommand hangs when output is too large)
On Tue, Jun 25, 2019 at 11:29:31AM +0200, Moritz Muehlenhoff wrote: > On Mon, Aug 06, 2018 at 12:04:46PM +0200, Dennis Schridde wrote: > > I confirm that the patch [1] to the upstream bug report [2] solves the > > issue > > for us. > > JFTR, we've also run into this at work at the Wikimedia Foundations's > Phabricator > installation (https://phabricator.wikimedia.org/T224677) and can confirm > that the attached patch fixes it. > > Colin, from my PoV this seems suitable for an update shipped in > a Stretch point release. I'd be happy to take care of an upload and > interacting with SRMs if you agree. I'm fine with this. Please go ahead. Thanks, -- Colin Watson [cjwat...@debian.org]
Bug#931631: Wrong dependency on virtual logind packages
On Mon, Jul 08, 2019 at 03:14:59PM +0200, Michael Biebl wrote: > in #923199, the recommends libpam-systemd was changed to > default-logind | logind | libpam-systemd > > This doesn't really make sense, as openssh does not use any of the > logind D-Bus interfaces that are supposed to be provided by those > virtual facilities. > The libpam-systemd recommends is there to ensure that login sessions are > registered by logind and properly moved into their own cgroups. > This is not a functionality that is provided by elogind or even relevant > for elogind. CCing Adam, who suggested the default-logind | logind part of this; I know very little about elogind myself. I can see how an "artificial" dependency like this might make sense to avoid libpam-systemd being pulled in for people who aren't using systemd, though, even if other logind implementations don't provide the same session registration features. -- Colin Watson [cjwat...@debian.org]
Bug#927792: new upstream (8.0)
On Tue, Apr 23, 2019 at 02:36:16PM +0200, Daniel Baumann wrote: > On 4/23/19 2:32 PM, Colin Watson wrote: > > to converge our GSSAPI key exchange patches > > oh.. that's nice to hear, we're using that at work. > > guess it doesn't make sense to upload 8.0 without it in the meanwhile > then.. Indeed, that would have been hard to rip out. > will patiently wait.. thanks for sharing. Sorry for the delay, but it's on its way into experimental now. -- Colin Watson [cjwat...@debian.org]
