he 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]
rate bug - I don't maintain the
dropbear packages.
--
Colin Watson (he/him) [cjwat...@debian.org]
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 mai
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]
t's https://bugs.debian.org/1068311 which I linked to elsewhere
in this thread.
--
Colin Watson (he/him) [cjwat...@debian.org]
s
between packages. But maybe.
--
Colin Watson (he/him) [cjwat...@debian.org]
hat 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]
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 like th
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
tran
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]
wayscurious/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]
g 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]
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 proper com
ixed 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]
t 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
nation 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
wall 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]
anners 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]
able mitigation at the level of OpenSSH.
--
Colin Watson (he/him) [cjwat...@debian.org]
-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]
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
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
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
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]
s 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]
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]
round 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]
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
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]
the
syscall is different).
--
Colin Watson (he/him) [cjwat...@debian.org]
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]
'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 tha
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/
dated 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]
sion 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]
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]
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.
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
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]
es using ptrace(2); it's not intended to have
users added to it.
--
Colin Watson (he/him) [cjwat...@debian.org]
he
> package.
Thanks, I'll cherry-pick this too then.
--
Colin Watson (he/him) [cjwat...@canonical.com]
on 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]
onfiguring
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]
alctl -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 me t
_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
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,
vailable."
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
pt
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)
stems with modern GNU coreutils.
--
Colin Watson (he/him) [cjwat...@debian.org]
se 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)
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,
>
Is it possible you upgraded some other piece of systemd-related
machinery at around the same time?
--
Colin Watson (he/him) [cjwat...@debian.org]
>
> 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 fro
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]
ackage 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]
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 services sin
hical-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]
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 :-)
--
Col
t 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
cherry-
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]
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]
ved.
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&q
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]
ting if you want me to.
That would be useful, thanks.
--
Colin Watson [cjwat...@debian.org]
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]
ve 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 retur
ld 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]
er 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 b
on 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
on! I've followed up to the MR with a detailed
review.
--
Colin Watson [cjwat...@debian.org]
edKeyTypes 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]
gin".
Otherwise, I don't really have a useful way to reproduce this ...
--
Colin Watson [cjwat...@debian.org]
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]
ysupgrade_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]
u'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]
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&
thing I'd much rather get upstream review of.
https://bugzilla.mindrot.org/
Thanks,
--
Colin Watson [cjwat...@debian.org]
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]
entations don't provide the
same session registration features.
--
Colin Watson [cjwat...@debian.org]
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 withou
a month, so if the problem
only started a week ago then it was probably caused by something else.
Perhaps something at the network layer?
--
Colin Watson [cjwat...@debian.org]
1 - 100 of 831 matches
Mail list logo