Okay, I've found out more about the cause:
sshd is compiled as PIE (position independent executable), but only
Linux, NetBSD and MirBSD can execute them; FreeBSD, OpenBSD and
DragonflyBSD cannot. (The DragonFly gcc ignores -pie because it
knows that its kernel can't execute them anyway.)
So the
Aurelien Jarno dixit:
Thorsten Glaser a C)crit :
Could you give us more details?
Sure, these are however also in the PR.
What problem do you get with this binary?
It's not executable.
Which architecture are you
kfreebsd-i386
And which kernel are you using?
Both 5.4 and 7.0 show the bug
close 430455
thanks
Aurelien Jarno dixit:
An upgrade to a 6.1 kernel may fix the bug.
It did. So the bug is closed for openssh.
How about, we either nuke the 5.4 and 7.0 kernels, or fix them too,
so that no other user will experience this problem?
bye,
//mirabile
--
I believe no one can
Source: openssh
Version: 6.0p1-3
Severity: important
Hi!
While building src:openssh, I noticed unusually high CPU load and
1517 pts/1S+ 0:00 /usr/bin/make -C build-deb -j 2
ASKPASS_PROGRAM=/usr/bin/ssh-askpass
and later, in the build logs as they scrolled past:
[…]
make[2]: Leaving
Colin Watson dixit:
Nothing in policy forbids using -j if parallel *isn't* set; it only
specifies behaviour when parallel is set.
Hmm. Not in the wording, but that’s why I said that’s my reading.
But you could just have
pointed out that it's wrong without trying to use policy as a stick.
I
Jakub Wilk dixit:
* Colin Watson cjwat...@debian.org, 2012-11-25, 15:53:
Nothing in policy forbids using -j if parallel *isn't* set; it only
specifies behaviour when parallel is set.
Hmm. Not in the wording, but that’s why I said that’s my reading.
To clarify, I think this would be a
#!/bin/sh
exec ssh-agent env LD_LIBRARY_PATH=$LD_LIBRARY_PATH $@
Doing ssh-agent in the background and killing it if the
children exit is *not* the same as doing it this way…
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393
Hi *,
binNMUing src:openssh locally, against the new OpenSSL, fixes
the problem. The problem with binNMUs is that you cannot guarantee
that the new OpenSSL is already used for the build (nothing in the
buildd network can give that guarantee, not even when OpenSSL has
already been built for that
On Mon, 23 Dec 2013, Kurt Roeckx wrote:
On Mon, Dec 23, 2013 at 10:03:08AM +0100, Thorsten Glaser wrote:
tglase@tglase:~ $ ssh localhost
OpenSSL version mismatch. Built against 1000105f, you have 10001060
This is already the 4th time this is reported.
Interesting, because this did
On Tue, 3 Jan 2017, Colin Watson wrote:
> > Can you please forward this to someone at the kernel side (either Debian
> > or upstream) who can have a look? In the meantime, I’ll point this issue
> > out in #debian-x32 on IRC, so the other porters can also look.
>
> I've cloned a kernel bug for
retitle 849923 openssh-server: (default) UsePrivilegeSeparation sandbox broken
on x32
thanks
On Mon, 2 Jan 2017, Thorsten Glaser wrote:
> After upgrading from 1:7.3p1-5 to 1:7.4p1-3 I can no longer
> 'ssh localhost' on x32; switching to openssh-server:i386 with
> the exact same conf
Package: openssh-server
Version: 1:7.4p1-3
Severity: important
After upgrading from 1:7.3p1-5 to 1:7.4p1-3 I can no longer
'ssh localhost' on x32; switching to openssh-server:i386 with
the exact same configuration works, though.
Server log:
tglase@tglase:~ $ sudo cleanenv / /usr/sbin/sshd
On Mon, 2 Jan 2017, Aurelien Jarno wrote:
> Looking at the issue, it actually appears in __vdso_clock_gettime, which
> is provided by the kernel. This code handle the simple cases (REALTIME,
> MONOTONIC, REALTIME_COARSE and _MONOTONIC_COARSE) and fallbacks to
> the syscall in otherwise,
Colin Watson dixit:
>I have forwarded your report upstream as
Thanks.
>https://bugzilla.mindrot.org/show_bug.cgi?id=2766. If you can, please
>(if necessary) create an account on that Bugzilla instance and add
Hm, that bugzilla was not listed on their site either. But for a
drive-by bugreport
Package: openssh-client
Version: 1:8.0p1-4
Severity: normal
│ 1|tglase@tglase-nb:~ $ cat .ssh/id_pvt.pub
│ ssh-rsa AAA…riqh id_...@tglase-nb.lan.tarent.de
│ tglase@tglase-nb:~ $ ssh-add .ssh/id_pvt
│ Enter passphrase for .ssh/id_pvt:
│ Identity added: .ssh/id_pvt (tgl...@tglase-nb.lan.tarent.de)
Timo WeingДrtner dixit:
>If
>
>$ file .ssh/id_pvt
>
>shows "OpenSSH private key" (instead of "PEM RSA private key") try:
Oh, indeed, it does.
tglase@tglase-nb:~ $ file .ssh/id_!(*.*)
.ssh/id_maven: PEM RSA private key
.ssh/id_pvt: OpenSSH private key
.ssh/id_rsa: PEM RSA private key
>$
Package: openssh-client
Version: 1:8.2p1-4
Severity: normal
An ssh session with port forwarding just crashed for me.
Backtrace:
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0xf7a75513 in __GI_abort () at abort.c:79
#2 0xf7acc82c in __libc_message
Package: openssh-server
Version: 1:8.2p1-3
Severity: wishlist
Tags: upstream wontfix
Feb 27 16:00:07 tglase-nb sshd[11219]: Unable to negotiate with 192.168.178.24
port 42930: no matching key exchange method found. Their offer:
> Has somebody already filed a bug against vx.connectbot?
Next on my TODO…
bye,
//mirabilos
--
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm
Hi Colin,
>sshd.c:privsep_preauth_child. But its setgroups() call seems
>straightforward, and I don't see how it could produce EFAULT:
thanks for also looking at it, yes, I tracked it down in gdb,
and the __nptl_setxid code is compiled differently, and I’m
fresh out of ideas how to track it
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:
tglase@tglase:~ $ ssh localhost
Connection reset by 127.0.0.1 port 22
Jul 15 22:33:17 tglase sshd[27084]: fatal:
For the record, -hpn is a contemporary patchset for high-performance
SSH throughput and actively maintained, from what I gather from the
OpenSSH mailing list.
And the bug isn’t restricted to that… I had the corresponding Launchpad
bug subscribed, so it must have hit me at some point.
I agree
Colin Watson dixit:
>I don't love overriding snprintf here, since it seems possible that that
Agreed.
>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,
Yes, but not
Colin Watson dixit:
>Thanks! No rush - I won't be at a proper computer until Sunday or so
>anyway.
OK sure… no rush is not the reason, the Atari VM I’m using having
only 98 MHz is the one here ;-)
But I already see:
checking if cc supports compile flag -fzero-call-used-regs=used and linking
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.
bye,
//mirabilos
--
18:47⎜ well channels… you see, I see everything in the
same window anyway 18:48⎜ i know, you have some kind of
Source: openssh
Version: 1:9.7p1-2
Severity: important
Justification: FTBFS on d-ports arch
Tags: ftbfs
X-Debbugs-Cc: t...@mirbsd.de, debian-...@lists.debian.org
On m68k, gcc-13 currently ICEs when -fzero-call-used-regs=used is
used (see #1066891) in moduli.c, packet.c, etc. but the configury
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,
//mirabilos
--
you introduced a merge commit│ % g rebase -i HEAD^^
sorry, no
27 matches
Mail list logo
