[Dropping CC to the upstream mailing list.]
On Fri, Sep 27, 2024 at 04:56:21PM +0700, Arnaud Rebillout wrote:
> On 30/08/2024 17:11, Colin Watson wrote:
> > This is now implemented in Debian unstable. I called the packages
> > openssh-client-gssapi and openssh-server-gssapi, wit
ng new that's come to light more recently?
(I haven't yet had time to read the paper in depth.)
--
Colin Watson (he/him) [cjwat...@debian.org]
On Tue, Apr 02, 2024 at 01:30:11AM +0100, Colin Watson wrote:
> * for Debian trixie (current testing):
>
>* add dependency-only packages called something like
> openssh-client-gsskex and openssh-server-gsskex, depending on their
> non-gsskex alternatives
>
makes some sense to consider a repairing change there;
I'll see what upstream says.
--
Colin Watson (he/him) [cjwat...@debian.org]
he correct fix should be although
I have a couple of possible ideas.
I've also written an autopkgtest for this, so once we fix it, it
shouldn't come back in testing.
--
Colin Watson (he/him) [cjwat...@debian.org]
On Fri, Aug 02, 2024 at 05:16:57PM +0200, Andrea Zagli wrote:
> i have "sshd: ALL" in hosts.allow and "ALL: ALL" in hosts.deny...
Perfect, thanks, I see the problem now. Will upload a fix shortly.
--
Colin Watson (he/him) [cjwat...@debian.org]
On Fri, Aug 02, 2024 at 04:57:55PM +0200, Andrea Zagli wrote:
> Colin Watson writes:
> > In that case I need all the ssh-related log entries you can give me -
> > "journalctl -u ssh.service --lines=1000", /var/log/auth.log, and so on.
>
> the only log produced
&
need all the ssh-related log entries you can give me -
"journalctl -u ssh.service --lines=1000", /var/log/auth.log, and so on.
--
Colin Watson (he/him) [cjwat...@debian.org]
ou using socket activation (#1077765)?
--
Colin Watson (he/him) [cjwat...@debian.org]
but it may take a little while.
I think we should probably also add an autopkgtest for the socket
activation case. Since it's not the default and not otherwise
automatically tested right now, it's easy for it to break accidentally.
--
Colin Watson (he/him) [cjwat...@debian.org]
rot.org, which IME is usually more reliable anyway.
--
Colin Watson (he/him) [cjwat...@debian.org]
e a while to sort
out.
> built including the deprecated ciphers?
I don't know exactly what you mean by this, but if you mean DSA, then
no, I will be disabling support for that in line with upstream's new
compile-time default. See also
https://salsa.debian.org/ddp-team/release-note
fig,
along with the output of the relevant apt run (which should be preserved
in /var/log/apt/term.log)?
--
Colin Watson (he/him) [cjwat...@debian.org]
annoying in the best case. ;-)
I would hope that people editing configuration files would generally
recognize comments!
--
Colin Watson (he/him) [cjwat...@debian.org]
ream in some way. Why does it matter?
--
Colin Watson (he/him) [cjwat...@debian.org]
Control: forwarded -1 https://bugzilla.mindrot.org/show_bug.cgi?id=3701
On Thu, Jun 13, 2024 at 08:00:56AM +0100, Colin Watson wrote:
> 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
> *def
on, 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]
27;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]
unning / 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]
27;ll have to report that as a separate bug - I don't maintain the
dropbear packages.
--
Colin Watson (he/him) [cjwat...@debian.org]
s 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
| 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]
, that's https://bugs.debian.org/1068311 which I linked to elsewhere
in this thread.
--
Colin Watson (he/him) [cjwat...@debian.org]
een packages. But maybe.
--
Colin Watson (he/him) [cjwat...@debian.org]
bian.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]
e to point out that
DNS-based ACLs are supported by Match blocks without needing a separate
library.
--
Colin Watson (he/him) [cjwat...@debian.org]
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 li
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
ler
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]
essary 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]
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]
g 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]
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.
Than
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 prope
C 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]
et 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
ination 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]
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 Wats
rewall 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]
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]
actionable mitigation at the level of OpenSSH.
--
Colin Watson (he/him) [cjwat...@debian.org]
en 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]
lates.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]
ckage 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
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 -Nr
* 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]
s 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
f
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]
e 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]
.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]
tions 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]
es
@@ -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]
ld 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]
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
> > fil
ients 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]
00028 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]
ar - the
syscall is different).
--
Colin Watson (he/him) [cjwat...@debian.org]
oll_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]
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 pr
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
> > >
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/
systemctl disable ssh.service" would also work, but masking avoids
+accidentally starting the service manually.)
+
This may be appropriate in environments where minimal footprint is critical
(e.g. cloud guests). Be aware that this bypasses MaxStartups, and systemd's
MaxConnections cannot
o 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]
-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]
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)
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]
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 i
emely 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 b
e 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]
running ssh-agent processes using ptrace(2); it's not intended to have
users added to it.
--
Colin Watson (he/him) [cjwat...@debian.org]
rsion of the
> package.
Thanks, I'll cherry-pick this too then.
--
Colin Watson (he/him) [cjwat...@canonical.com]
s, which is:
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
--
Colin Watson (he/him) [cjwat...@debian.org]
ck 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]
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]
ournalctl -b -u ssh.service"
that show when sshd stopped and started.
--
Colin Watson (he/him) [cjwat...@debian.org]
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
e(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-de
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,
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]
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 di
On Mon, Feb 15, 2021 at 01:52:59AM +0100, Andreas Henriksson wrote:
> On Sun, Feb 14, 2021 at 01:05:11PM +0000, Colin Watson wrote:
> > How about this approach instead? Given the choice between a
> > packaging-only change and one that requires another patch against
> > upst
+= --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)
atic on systems with modern GNU coreutils.
--
Colin Watson (he/him) [cjwat...@debian.org]
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
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,
> >
g 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]
ors.
>
> 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
messag
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]
hat 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]
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]
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]
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 service
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]
than me having to be an inefficient go-between if
there are any questions or disputes.
Thanks,
--
Colin Watson [cjwat...@debian.org]
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]
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 :-)
--
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]
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
ch
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]
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]
1 - 100 of 1123 matches
Mail list logo
