[Bug 3647] New: Correct the catalogue number of PROTOCOL

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3647

Bug ID: 3647
   Summary: Correct the catalogue number of PROTOCOL
   Product: Portable OpenSSH
   Version: -current
  Hardware: All
OS: All
Status: NEW
  Severity: trivial
  Priority: P5
 Component: Documentation
  Assignee: unassigned-b...@mindrot.org
  Reporter: rmsh1...@163.com

Created attachment 3777
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3777=edit
Correct the catalogue number of PROTOCOL

The protocol number should be 1.10 instead of 1.9 which is documented
in previous commit

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3645] -fzero-call-used-regs=used detection seems to fail on Linux ppc64el

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3645

Damien Miller  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #3 from Damien Miller  ---
thanks - committed (on master and on the V_9_6 stable branch)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3646] The configure file in the ssh directory is missing

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3646

Damien Miller  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 CC||d...@mindrot.org
 Status|NEW |RESOLVED

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3646] The configure file in the ssh directory is missing

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3646

Darren Tucker  changed:

   What|Removed |Added

 CC||dtuc...@dtucker.net

--- Comment #1 from Darren Tucker  ---
That's the OpenBSD tarball.  You want the portable one:
https://www.openssh.com/portable.html

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #28 from JM  ---
> I'd like to reproduce this locally.  Could you please attach /etc/os-release 
> and the output of "dpkg -l" from the affected device?

Attached in `RPi4-dpkg-l.txt` and `RPi4.info`.

> Also, if you can catch the sandbox-violation in gdb, getting a disassembly of 
> instructions around the violation would be instructive.

I'll give it a shot.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3645] -fzero-call-used-regs=used detection seems to fail on Linux ppc64el

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3645

bbhtt.zn...@slmail.me changed:

   What|Removed |Added

 CC||bbhtt.zn...@slmail.me

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3645] -fzero-call-used-regs=used detection seems to fail on Linux ppc64el

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3645

--- Comment #2 from Colin Watson  ---
sshkey_set_filename (in the branch where WITH_XMSS is false) in
sshkey.c elicits it as well, according to the build log.

That extended autoconf test seems to do the trick, thanks!

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3646] The configure file in the ssh directory is missing

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3646

fengyan <597238...@qq.com> changed:

   What|Removed |Added

 CC||597238...@qq.com

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3646] New: The configure file in the ssh directory is missing

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3646

Bug ID: 3646
   Summary: The configure file in the ssh directory is missing
   Product: Portable OpenSSH
   Version: 9.6p1
  Hardware: ix86
OS: Linux
Status: NEW
  Severity: major
  Priority: P5
 Component: Build system
  Assignee: unassigned-b...@mindrot.org
  Reporter: 597238...@qq.com

After decompressing openssh-9.6.tar.gz to the ssh directory, the
configure file in the ssh directory is missing,causing the installation
to fail.
The installation package (openssh-9.6.tar.gz) image under the
https://www.openssh.com/ftp.html website has this problem.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3641] Improved SELinux support for openssh

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3641

--- Comment #2 from jseg...@suse.de ---
thank you. I'll started to work on this, but it'll take a while since
there are other tasks and the upcoming holiday season. I'll attach
something here in January when I reworked the patches

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3645] -fzero-call-used-regs=used detection seems to fail on Linux ppc64el

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3645

Damien Miller  changed:

   What|Removed |Added

 CC||d...@mindrot.org

--- Comment #1 from Damien Miller  ---
Created attachment 3776
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3776=edit
better detection of broken compiler maybe?

AFAIK this is a gcc bug and it's super weird that this one, trivial,
function elicits it but nothing else.

This extends the autoconf test that we use to detect broken compilers
to do something similar to the function in question. Can you see if it
works? I don't have a ppc-anything box around to test with.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3645] New: -fzero-call-used-regs=used detection seems to fail on Linux ppc64el

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3645

Bug ID: 3645
   Summary: -fzero-call-used-regs=used detection seems to fail on
Linux ppc64el
   Product: Portable OpenSSH
   Version: 9.6p1
  Hardware: PPC64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P5
 Component: Build system
  Assignee: unassigned-b...@mindrot.org
  Reporter: cjwat...@debian.org

9.6p1 failed to build on Debian ppc64(el) with this error:

  ../../cipher.c: In function ‘compression_alg_list’:
  ../../cipher.c:151:1: sorry, unimplemented: argument ‘used’ is not
supported for ‘-fzero-call-used-regs’ on this target
151 | }
| ^

A complete build log is at
https://buildd.debian.org/status/fetch.php?pkg=openssh=ppc64el=1%3A9.6p1-1=1702942848=0.

I have a shell on a relevant machine and am happy to try adding more
things to the conftest.c code that tries to provoke this sort of error,
but I'm not quite sure what to try for myself.  Any suggestions?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #27 from Damien Miller  ---
Could you please provide this information so we can try to replicate it
ourselves:

(In reply to Darren Tucker from comment #11)
> I'd like to reproduce this locally.  Could you please attach
> /etc/os-release and the output of "dpkg -l" from the affected device?

Also my request from comment #25:

> Could you add try adding a similar printf+getpid+exit sequence to
> (say) the start of ssh-keygen.c, rerunning make and repeating the
> test using the resultant binary? You probably only need to do this
> on the rpi4

Also, if you can catch the sandbox-violation in gdb, getting a
disassembly of instructions around the violation would be instructive.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #26 from JM  ---
tl;dr a seccomp sandbox violation `20` occurs from a `read` (still).
  This is just a more detailed retelling of what was previously
discussed.
  Scroll to end for thoughts...

### problem specifics

Failed `read` in parent process

read(fd, s + pos, n - pos);

which is

read(5, '\014\221b', 4);

returns `0`.

Failed `read` will cause the following audit event (journalctl -f -x)

Dec 17 15:59:35 host1 kernel: audit: type=1326
audit(1702857575.824:3180): auid=4294967295 uid=107 gid=65534
ses=4294967295 pid=1920 comm="sshd"
exe="/root/Projects/openssh-9.2p1-WIP/sshd" sig=31 arch=4028
syscall=20 compat=1 ip=0xf7afd80c code=0x0

And the same when compiled with
`CFLAGS="-DDSANDBOX_SECCOMP_FILTER_DEBUG"`

Dec 17 22:37:50 pifuboo audit[10678]: SECCOMP auid=4294967295
uid=107 gid=65534 ses=4294967295 pid=10678 comm="sshd"
exe="/root/Projects/openssh-9.2p1-WIP/sshd" sig=31 arch=4028
syscall=20 compat=1 ip=0xf77de80c code=0x0
Dec 17 22:37:50 pifuboo audit[10678]: ANOM_ABEND auid=4294967295
uid=107 gid=65534 ses=4294967295 pid=10678 comm="sshd"
exe="/root/Projects/openssh-9.2p1-WIP/sshd" sig=31 res=1

The failed linux system call `20` is `epoll_create1` according to
`ausyscall`

$ ausyscall 20
epoll_create1

So the `read` at some point calls syscall `20`. See section "Summary
Thoughts" about this.

Here is the failed `read` call
https://github.com/openssh/openssh-portable/blob/V_9_2_P1/atomicio.c#L66
It is always the `read` call with values `fd=5`, `n=4`.
`read` returns `0`.
`errno` is not changed after `read` returns.

The stack just before the failed `read` call is:

#1  0x004701f8 in atomicio6
(f=f@entry=0xf7c65478 , fd=fd@entry=5, _s=0xfffeead8,
_s@entry=0xfffeead0, n=n@entry=4, cb=cb@entry=0x0,
cb_arg=cb_arg@entry=0x0)
at atomicio.c:67
#2  0x00470284 in atomicio
(f=f@entry=0xf7c65478 , fd=fd@entry=5,
_s=_s@entry=0xfffeead0, n=n@entry=4)
at atomicio.c:101
#3  0x00434520 in mm_request_receive
(sock=5, m=m@entry=0x4f2b88)
at monitor_wrap.c:149
#4  0x00431178 in monitor_read
(ssh=ssh@entry=0x4f3388, pmonitor=pmonitor@entry=0x4f2498,
ent=0x4e0114 , pent=pent@entry=0xfffeeb78)
at monitor.c:501
#5  0x00433b5c in monitor_child_preauth
(ssh=ssh@entry=0x4f3388, pmonitor=0x4f2498)
at monitor.c:301
#6  0x0040a388 in privsep_preauth
(ssh=0x4f3388)
at sshd.c:502
#7  main
(ac=, av=0x4e31a0)
at sshd.c:2240

(line numbers in `atomicio.c` slightly off due to insertion of
`raise(SIGINT);`)

The debug log from the start of client connection is:

debug3: fd 5 is not O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug3: send_rexec_state: entering fd = 8 config len 3296
debug3: ssh_msg_send: type 0
debug3: send_rexec_state: done
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
process 32277 is executing new program:
/root/Projects/openssh-9.2p1/sshd
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/arm-linux-gnueabihf/libthread_db.so.1".
debug3: recv_rexec_state: entering fd = 5
debug3: ssh_msg_recv entering
debug3: recv_rexec_state: done
debug2: parse_server_config_depth: config rexec len 3296
debug3: rexec:14 setting Port 55222
debug3: rexec:22 setting HostKey
/root/Projects/openssh-9.2p1/ssh_host_ecdsa_key
debug3: rexec:23 setting HostKey
/root/Projects/openssh-9.2p1/ssh_host_ed25519_key
debug3: rexec:24 setting HostKey
/root/Projects/openssh-9.2p1/ssh_host_rsa_key
debug3: rexec:45 setting AuthorizedKeysFile .ssh/authorized_keys
debug3: rexec:113 setting Subsystem sftp   
/usr/libexec/sftp-server
debug1: sshd version OpenSSH_9.2, OpenSSL 1.1.1w  11 Sep 2023
debug1: private host key #0: ecdsa-sha2-nistp256
SHA256:7OUDaY7vmsaJPDkqGWPmdiw5kjY4bVSwCd94nJqT7/o
debug1: private host key #1: ssh-ed25519
SHA256:CuPO+bnbHMCkaNEybTHeYSjdNpiNdAlntO9gh0V9lxs
debug1: private host key #2: ssh-rsa
SHA256:ZYZLLhbWdOMFKDGw3pcn954Wz6RhwtDoI5WjJsZpXhk
debug1: inetd sockets after dupping: 3, 3
debug3: process_channel_timeouts: setting 0 timeouts
debug3: channel_clear_timeouts: clearing
Connection from 192.168.124.214 port 57930 on 192.168.124.214 port
55222 rdomain ""
debug1: Local version string SSH-2.0-OpenSSH_9.2
debug1: Remote protocol version 2.0, remote software version
OpenSSH_8.4p1 Raspbian-5+deb11u2
debug1: compat_banner: match: OpenSSH_8.4p1 Raspbian-5+deb11u2 pat
OpenSSH* compat 0x0400
debug2: fd 3 setting O_NONBLOCK
debug3: ssh_sandbox_init: preparing seccomp filter sandbox
[Detaching after fork from child process 32308]
debug2: Network child is on pid 32308
debug3: preauth child monitor started
debug3: privsep user:group 107:65534 [preauth]
debug1: 

[Bug 3644] New: Pass the number of attempt to SSH_ASKPASS

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3644

Bug ID: 3644
   Summary: Pass the number of attempt to SSH_ASKPASS
   Product: Portable OpenSSH
   Version: 9.4p1
  Hardware: All
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P5
 Component: ssh
  Assignee: unassigned-b...@mindrot.org
  Reporter: flafyar...@gmail.com

I'm working on a script to make `ssh` request a passphrase from a
command of my choice instead of prompting me for a passphrase directly.

If the script doesn't find a passphrase through the command, it should
prompt me to input a passphrase.

Additionally, if the script got a passphrase from the command but the
passphrase was not correct, it should prompt me to input a passphrase
as well.

I've set
```
SSH_ASKPASS_REQUIRE=prefer
SSH_ASKPASS=
```

bash script:
```
#!/usr/bin/env bash

key_name=$(echo "$1" | sed -n "s/.*\/\([^\/]*\)'.*/\1/p")

pass=$(get-passphrase-command "$key_name")

if [ $? -eq 0 ]; then
  echo "$pass"
else
  echo "Couldn't find passphrase from Bitwarden." >&2
  read -s -p "$1" passphrase
  echo "" >&2
  echo "$passphrase"
fi
```

`ssh` will run this script every time it wants to request a passphrase.
If a passphrase returned by the script is not correct, `ssh` will run
the script 2 more times.

The script does exactly what I've described except prompt me for a
passphrase if it got an incorrect passphrase from the command. I can't
pass information from one attempt to another, so the script has no idea
if it failed already.


`ssh` passes the prompt it usually shows as the first argument(`$1`) to
SSH_ASKPASS.

To make my script possible, I propose also passing the number of
attempted passphrases so far to SSH_ASKPASS as the second
argument(`$2`). 
This way I'll be able to detect it is the script's second attempt at
inputting a passphrase and not run the passphrase command again.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3628] tracking bug for openssh-9.6

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3628

Damien Miller  changed:

   What|Removed |Added

 Depends on||3643


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=3643
[Bug 3643] order_hostkeyalgs can't find host-key in KnownHostsCommand
if it contains port
-- 
You are receiving this mail because:
You are watching the reporter of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3628] tracking bug for openssh-9.6

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3628
Bug 3628 depends on bug 3643, which changed state.

Bug 3643 Summary: order_hostkeyalgs can't find host-key in KnownHostsCommand if 
it contains port
https://bugzilla.mindrot.org/show_bug.cgi?id=3643

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching the reporter of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3643] order_hostkeyalgs can't find host-key in KnownHostsCommand if it contains port

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3643

Damien Miller  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
 Blocks||3628

--- Comment #3 from Damien Miller  ---
committed with the name fixed - it should be 'hostname' instead of
'hostaddr'

Thanks - this will be in OpenSSH 9.6, due next week.


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=3628
[Bug 3628] tracking bug for openssh-9.6
-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3643] order_hostkeyalgs can't find host-key in KnownHostsCommand if it contains port

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3643

Darren Tucker  changed:

   What|Removed |Added

   Attachment #3775|ok?(dtuc...@dtucker.net)|ok+
  Flags||

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3643] order_hostkeyalgs can't find host-key in KnownHostsCommand if it contains port

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3643

Damien Miller  changed:

   What|Removed |Added

   Assignee|unassigned-b...@mindrot.org |d...@mindrot.org
 CC||d...@mindrot.org,
   ||dtuc...@dtucker.net
 Status|NEW |ASSIGNED
   Attachment #3775||ok?(dtuc...@dtucker.net)
  Flags||

--- Comment #2 from Damien Miller  ---
Created attachment 3775
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3775=edit
use hostaddr (host[:port]) instead of plain host

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3643] order_hostkeyalgs can't find host-key in KnownHostsCommand if it contains port

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3643

--- Comment #1 from Anton Lundin  ---
Sorry for the inconsistent port number in the redacted log-snippet.
s/1234/9022/ and everything is ok.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3643] New: order_hostkeyalgs can't find host-key in KnownHostsCommand if it contains port

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3643

Bug ID: 3643
   Summary: order_hostkeyalgs can't find host-key in
KnownHostsCommand if it contains port
   Product: Portable OpenSSH
   Version: 9.5p1
  Hardware: Other
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P5
 Component: ssh
  Assignee: unassigned-b...@mindrot.org
  Reporter: glance+mind...@ac2.se

I have a KnownHostsCommand which emits :
[targethost]:1234 ssh-rsa ...

ssh -vvv -o KnownHostsCommand=cmd -p 1234 targethost shows:
...
debug1: Authenticating to targethost:9022 as 'user'
debug3: put_host_port: [targethost]:9022
debug3: subprocess: KnownHostsCommand-ORDER command "cmd" running as
user (flags 0x1a)
debug3: subprocess: KnownHostsCommand-ORDER pid 12345
debug3: sigaction(Killed): Invalid argument
debug3: sigaction(Stopped (signal)): Invalid argument
debug3: sigaction(Unknown signal 32): Invalid argument
debug3: sigaction(Unknown signal 33): Invalid argument
debug3: order_hostkeyalgs: no algorithms matched; accept original


I've diagnosed this down to sshconnect2.c:142:
load_hostkeys_command(hostkeys, options.known_hosts_command,
"ORDER", cinfo, NULL, host);

It calls load_hostkeys_command with host, which in this context is just
targethost and not hostname that will in this context be
[targethost]:1234 .

Right above the load_hostkeys_command are the load_hostkeys calls which
uses hostname instead.


I'm guessing this is just a simple typo from development which caused
it to not work in the special case where one has a not prefered
ssh-host-key with a port in a KnownHostsCommand. If the ssh-host-key
the KnownHostsCommand emitted would be the prefered one, ssh-ed25519,
it would by accident, or if the default port was used.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3642] New: GSS treats hostnames case sensitive -> suggestion for docs of GSSAPIStrictAcceptorCheck setting

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3642

Bug ID: 3642
   Summary: GSS treats hostnames case sensitive -> suggestion for
docs of GSSAPIStrictAcceptorCheck  setting
   Product: Portable OpenSSH
   Version: 9.5p1
  Hardware: amd64
OS: FreeBSD
Status: NEW
  Severity: enhancement
  Priority: P5
 Component: Kerberos support
  Assignee: unassigned-b...@mindrot.org
  Reporter: alexander-opensshbugzi...@leidinger.net

Hi,

I have a host which has a different case in the kerberos DB than in
DNS.
   krb5: host/test.example.com@REALM
   DNS: test.Example.com(forward and reverse match in DNS)

If I try to do GSS API authentication, it fails. If I use
"GSSAPIStrictAcceptorCheck no" for sshd, it succeeds.

Searching in the net reveals that more people have this issue.

I suggest to add a note to the ssh docs that this setting is not only
for multihomed machines, but also for cases where the case of the
hostname may not match from all sources (command line vs DNS vs the
output of hostname).

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 2876] PAM_TEXT_INFO and PAM_ERROR_MSG conversation not honoured during PAM authentication

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=2876

Tim Connors  changed:

   What|Removed |Added

 CC||tim.w.conn...@gmail.com

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3641] Improved SELinux support for openssh

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3641

Damien Miller  changed:

   What|Removed |Added

 CC||d...@mindrot.org

--- Comment #1 from Damien Miller  ---
Happy to review the patches. There is support for SELinux already
integrated, but I don't run with SELinux enabled anywhere so testing of
it is largely up to the community.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #25 from Damien Miller  ---
ok, so now I have no idea what is going wrong. Maybe there is something
in OpenSSH's compile flags that is messing this up.

Could you add try adding a similar printf+getpid+exit sequence to (say)
the start of ssh-keygen.c, rerunning make and repeating the test using
the resultant binary? You probably only need to do this on the rpi4

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #24 from JM  ---
> Could you try building and running this program. E.g.
> 
> $ cc -o syscall syscall.c 
> $ ./syscall
> $ strace -n ./syscall


Raspberry Pi 4 (RPi4), aarch64, Raspbian-Debian 11, (openssh 9.5p1
client thread aborts):

$ (set -eux; wget -q
"https://bugzilla.mindrot.org/attachment.cgi?id=3774; -O syscall.c ; cc
-o syscall syscall.c ; ./syscall ; strace -n ./syscall )
+ wget -q 'https://bugzilla.mindrot.org/attachment.cgi?id=3774' -O
syscall.c
+ cc -o syscall syscall.c
+ ./syscall
__NR_getpid = 20
+ strace -n ./syscall
[  11] execve("./syscall", ["./syscall"], 0xffb2b5b4 /* 31 vars */)
= 0
[  45] brk(NULL)= 0x1ae5000
[ 122] uname({sysname="Linux", nodename="pifuboo", ...}) = 0
[  33] access("/etc/ld.so.preload", R_OK) = 0
[ 322] openat(AT_FDCWD, "/etc/ld.so.preload",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
[ 197] fstat64(3, {st_mode=S_IFREG|0644, st_size=54, ...}) = 0
[ 192] mmap2(NULL, 54, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0) =
0xf7d7f000
[   6] close(3) = 0
[  85] readlink("/proc/self/exe", "/tmp/syscall", 4096) = 12
[ 322] openat(AT_FDCWD,
"/usr/lib/arm-linux-gnueabihf/libarmmem-v8l.so",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
[   3] read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\254\3\0\0004\0\0\0"...,
512) = 512
[ 197] fstat64(3, {st_mode=S_IFREG|0644, st_size=17708, ...}) = 0
[ 192] mmap2(NULL, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7d7d000
[ 192] mmap2(NULL, 81964, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf7d3a000
[ 125] mprotect(0xf7d3e000, 61440, PROT_NONE) = 0
[ 192] mmap2(0xf7d4d000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0xf7d4d000
[   6] close(3) = 0
[  91] munmap(0xf7d7f000, 54)   = 0
[ 322] openat(AT_FDCWD, "/etc/ld.so.cache",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
[ 197] fstat64(3, {st_mode=S_IFREG|0644, st_size=63463, ...}) = 0
[ 192] mmap2(NULL, 63463, PROT_READ, MAP_PRIVATE, 3, 0) =
0xf7d2a000
[   6] close(3) = 0
[ 322] openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libc.so.6",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
[   3] read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\0y\1\0004\0\0\0"...,
512) = 512
[ 197] fstat64(3, {st_mode=S_IFREG|0755, st_size=1315688, ...}) = 0
[ 192] mmap2(NULL, 1385020, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf7bd7000
[ 125] mprotect(0xf7d15000, 61440, PROT_NONE) = 0
[ 192] mmap2(0xf7d24000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13d000) = 0xf7d24000
[ 192] mmap2(0xf7d27000, 8764, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf7d27000
[   6] close(3) = 0
[983045] set_tls(0xf7d7df80)= 0
[ 125] mprotect(0xf7d24000, 8192, PROT_READ) = 0
[ 125] mprotect(0xf7d4d000, 4096, PROT_READ) = 0
[ 125] mprotect(0x2, 4096, PROT_READ) = 0
[ 125] mprotect(0xf7d81000, 4096, PROT_READ) = 0
[  91] munmap(0xf7d2a000, 63463)= 0
[ 197] fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0),
...}) = 0
[  45] brk(NULL)= 0x1ae5000
[  45] brk(0x1b06000)   = 0x1b06000
[   4] write(1, "__NR_getpid = 20\n", 17__NR_getpid = 20
) = 17
[  20] getpid() = 21435
[ 248] exit_group(0)= ?
[ 248] +++ exited with 0 +++

Raspberry Pi 3 (RPi3), armv7l, Raspbian Debian 11, (openssh 9.5p1 runs
okay):

$ (set -eux; wget -q
"https://bugzilla.mindrot.org/attachment.cgi?id=3774; -O syscall.c ; cc
-o syscall syscall.c ; ./syscall ; strace -n ./syscall )
+ wget -q 'https://bugzilla.mindrot.org/attachment.cgi?id=3774' -O
syscall.c
+ cc -o syscall syscall.c
+ ./syscall
__NR_getpid = 20
+ strace -n ./syscall
[  11] execve("./syscall", ["./syscall"], 0x7eab2584 /* 30 vars */)
= 0
[  45] brk(NULL)= 0x1435000
[ 192] mmap2(NULL, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76fa5000
[  33] access("/etc/ld.so.preload", R_OK) = 0
[ 322] openat(AT_FDCWD, "/etc/ld.so.preload",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
[ 197] fstat64(3, {st_mode=S_IFREG|0644, st_size=54, ...}) = 0
[ 192] mmap2(NULL, 54, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0) =
0x76fa4000
[   6] close(3) = 0
[  85] readlink("/proc/self/exe", "/tmp/syscall", 4096) = 12
[ 322] openat(AT_FDCWD,
"/usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
[   3] read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\254\3\0\0004\0\0\0"...,
512) = 512
[ 197] fstat64(3, {st_mode=S_IFREG|0644, st_size=17708, ...}) = 0
[ 192] mmap2(NULL, 

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #23 from Damien Miller  ---
i.e. run it on a platform that works and the one that doesn't

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #22 from Damien Miller  ---
Created attachment 3774
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3774=edit
syscall dumper

Could you try building and running this program. E.g.

$ cc -o syscall syscall.c 
$ ./syscall
$ strace -n ./syscall 

This will tell you what the compiler thinks __NR_getpid is vs what the
actual syscall is.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #21 from JM  ---
A little more info about `__NR_getpid` and `__NR_epoll_create1` (not
sure if this is relevant but in case you were curious)

On RPi4 (has aborts)

$ grep -r -Ee '__NR_getpid|__NR_epoll_create1' -- /usr/include/
/usr/include/asm-generic/unistd.h:#define __NR_epoll_create1 20
/usr/include/asm-generic/unistd.h:__SYSCALL(__NR_epoll_create1,
sys_epoll_create1)
/usr/include/asm-generic/unistd.h:#define __NR_getpid 172
/usr/include/asm-generic/unistd.h:__SYSCALL(__NR_getpid,
sys_getpid)
/usr/include/arm-linux-gnueabihf/bits/syscall.h:#ifdef
__NR_epoll_create1
/usr/include/arm-linux-gnueabihf/bits/syscall.h:# define
SYS_epoll_create1 __NR_epoll_create1
/usr/include/arm-linux-gnueabihf/bits/syscall.h:#ifdef __NR_getpid
/usr/include/arm-linux-gnueabihf/bits/syscall.h:# define SYS_getpid
__NR_getpid
/usr/include/arm-linux-gnueabihf/asm/unistd-eabi.h:#define
__NR_getpid (__NR_SYSCALL_BASE + 20)
/usr/include/arm-linux-gnueabihf/asm/unistd-eabi.h:#define
__NR_epoll_create1 (__NR_SYSCALL_BASE + 357)
/usr/include/arm-linux-gnueabihf/asm/unistd-oabi.h:#define
__NR_getpid (__NR_SYSCALL_BASE + 20)
/usr/include/arm-linux-gnueabihf/asm/unistd-oabi.h:#define
__NR_epoll_create1 (__NR_SYSCALL_BASE + 357)

On RPi3 (runs okay)

$ grep -r -Ee '__NR_getpid|__NR_epoll_create1' -- /usr/include/
/usr/include/asm-generic/unistd.h:#define __NR_epoll_create1 20
/usr/include/asm-generic/unistd.h:__SYSCALL(__NR_epoll_create1,
sys_epoll_create1)
/usr/include/asm-generic/unistd.h:#define __NR_getpid 172
/usr/include/asm-generic/unistd.h:__SYSCALL(__NR_getpid,
sys_getpid)
/usr/include/arm-linux-gnueabihf/bits/syscall.h:#ifdef
__NR_epoll_create1
/usr/include/arm-linux-gnueabihf/bits/syscall.h:# define
SYS_epoll_create1 __NR_epoll_create1
/usr/include/arm-linux-gnueabihf/bits/syscall.h:#ifdef __NR_getpid
/usr/include/arm-linux-gnueabihf/bits/syscall.h:# define SYS_getpid
__NR_getpid
/usr/include/arm-linux-gnueabihf/asm/unistd-oabi.h:#define
__NR_getpid (__NR_SYSCALL_BASE + 20)
/usr/include/arm-linux-gnueabihf/asm/unistd-oabi.h:#define
__NR_epoll_create1 (__NR_SYSCALL_BASE + 357)
/usr/include/arm-linux-gnueabihf/asm/unistd-eabi.h:#define
__NR_getpid (__NR_SYSCALL_BASE + 20)
/usr/include/arm-linux-gnueabihf/asm/unistd-eabi.h:#define
__NR_epoll_create1 (__NR_SYSCALL_BASE + 357)

On NanoPi NEO3 (runs okay)

$ grep -r -Ee '__NR_getpid|__NR_epoll_create1' -- /usr/include/
/usr/include/asm-generic/unistd.h:#define __NR_epoll_create1 20
/usr/include/asm-generic/unistd.h:__SYSCALL(__NR_epoll_create1,
sys_epoll_create1)
/usr/include/asm-generic/unistd.h:#define __NR_getpid 172
/usr/include/asm-generic/unistd.h:__SYSCALL(__NR_getpid,
sys_getpid)
/usr/include/aarch64-linux-gnu/bits/syscall.h:#ifdef
__NR_epoll_create1
/usr/include/aarch64-linux-gnu/bits/syscall.h:# define
SYS_epoll_create1 __NR_epoll_create1
/usr/include/aarch64-linux-gnu/bits/syscall.h:#ifdef __NR_getpid
/usr/include/aarch64-linux-gnu/bits/syscall.h:# define SYS_getpid
__NR_getpid

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #20 from JM  ---
Created attachment 3773
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3773=edit
NanoPi-dpkg-l.txt

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #19 from JM  ---
Created attachment 3772
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3772=edit
RPi4.info

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #18 from JM  ---
Created attachment 3771
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3771=edit
RPi3.info

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #17 from JM  ---
Created attachment 3770
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3770=edit
NanoPi_NEO3.info

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #16 from JM  ---
Created attachment 3769
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3769=edit
RPi3-dpkg-l.txt

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #15 from JM  ---
Created attachment 3768
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3768=edit
RPi4-dpkg-l.txt

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #14 from JM  ---
Created attachment 3767
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3767=edit
config-9.2p1.h

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #13 from JM  ---
Created attachment 3766
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3766=edit
config-9.1p1.h

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #12 from JM  ---
tl;dr compiles and runs okay on a Raspberry Pi3 and NanoPi NEO3 running
similar OS

For comparison, I've included three similar, not the same, platforms:
- Raspberry Pi 4 (RPi4) (aarch64) (Raspbian) on which this bug report
originated
- Raspberry Pi 3 (RPi3) (armv7l) (Raspbian) on which openssh 9.5p1 runs
fine (client can login, no thread aborts)
- NanoPi NEO3 Rockchip RK3288 (aarch64) (Debian) on which openssh 9.5p1
runs fine (client can login, no thread aborts)

I attached three ".info" files with various dumps of info about each
system.

To be clearer about the OS, I'm using the DietPI-managed distribution
of Raspbian (for Raspberry Pis) or Debian (for NanoPi)
(https://dietpi.com/).

> JM: what compiler are you using?

On RPi4 (has aborts)

$ cc --version
cc (Raspbian 10.2.1-6+rpi1) 10.2.1 20210110

On RPi3 (runs okay)

$ cc --version
cc (Raspbian 10.2.1-6+rpi1) 10.2.1 20210110

On NanoPi NEO3 (runs okay)

$ cc --version
cc (Debian 10.2.1-6) 10.2.1 20210110

On RPi4 (has aborts)

$ grep -r -E '__NR.*20$' /usr/include
/usr/include/asm-generic/unistd.h:#define __NR_epoll_create1 20
/usr/include/asm-generic/unistd.h:#define __NR_sched_getscheduler
120
/usr/include/asm-generic/unistd.h:#define __NR_clone 220
/usr/include/asm-generic/unistd.h:#define __NR_semtimedop_time64
420

$ grep -E NR.*getpid /usr/include/asm-generic/unistd.h
#define __NR_getpid 172
__SYSCALL(__NR_getpid, sys_getpid)

On RPi3 (runs okay)

$ grep -r -E '__NR.*20$' /usr/include
/usr/include/asm-generic/unistd.h:#define __NR_epoll_create1 20
/usr/include/asm-generic/unistd.h:#define __NR_sched_getscheduler
120
/usr/include/asm-generic/unistd.h:#define __NR_clone 220
/usr/include/asm-generic/unistd.h:#define __NR_semtimedop_time64
420

$ grep -E NR.*getpid /usr/include/asm-generic/unistd.h
#define __NR_getpid 172
__SYSCALL(__NR_getpid, sys_getpid)

On NanoPi NEO3 (runs okay)

$ grep -r -E '__NR.*20$' /usr/include
/usr/include/asm-generic/unistd.h:#define __NR_epoll_create1 20
/usr/include/asm-generic/unistd.h:#define __NR_sched_getscheduler
120
/usr/include/asm-generic/unistd.h:#define __NR_clone 220
/usr/include/asm-generic/unistd.h:#define __NR_semtimedop_time64
420

$ grep -E NR.*getpid /usr/include/asm-generic/unistd.h
#define __NR_getpid 172
__SYSCALL(__NR_getpid, sys_getpid)

> which a test program confirms:

Results from RPi4 (has aborts), using the same `test.c` source code
show above.

$ cc test.c
$ ./a.out
__NR_epoll_create1 357
__NR_getpid 20

On RPi3 (runs okay) same results:

$ cc test.c
$ ./a.out
__NR_epoll_create1 357
__NR_getpid 20

On NanoPi NEO3 (runs okay) differs:

$ cc test.c
$ ./a.out
__NR_epoll_create1 20
__NR_getpid 172

> Another thing that might be interesting is to compare config.h
> and the output of configure from 9.1p1 with those of 9.2p1 and
> see if anything unexpectedly changed.

Compared on the RPi4 (has aborts) of 9.1p1 and 9.2p1:

$ diff -d -B -W 80 -y --suppress-common-lines -- config-9.1p1.h
config-9.2p1.h
#define DISABLE_WTMPX 1   | /* #undef DISABLE_WTMPX */
#define HAVE_DECL_MEMMEM 0| #define HAVE_DECL_MEMMEM 1
/* #undef HAVE_SIGHANDLER_T */| #define HAVE_SIGHANDLER_T 1
  > /* sockaddr_in has sin_len
*/
  > /* #undef SOCK_HAS_LEN */
#define USER_PATH "/usr/bin:/bin:/usr | #define USER_PATH
"/usr/bin:/bin:/usr

Attached both config.h files from RPi4; `config-9.1p1.h`,
`config-9.2p1.h`.

> Could you please attach /etc/os-release and the output of "dpkg -l"
> from the affected device?

Attached in `RPi4-dpkg-l.txt` and `RPi4.info`.

> My guess would be something in libcrypto, in which case
> configuring --without-openssl and retesting would be a good indicator).

Tried `--without-openssl` on RPi4 using 9.5p1. Same error occurs.

$ make clean
$ ./configure --prefix=/opt/openssh-9.5p1-noopenssl
--without-openssl
$ make
$ make install

---

In case anyone is curious, general installation steps are taken from my
gist https://gist.github.com/jtmoon79/745e6df63dd14b9f2d17a662179e953a

--James T Moon (https://github.com/jtmoon79/)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3641] Improved SELinux support for openssh

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3641

jseg...@suse.de changed:

   What|Removed |Added

 CC||jseg...@suse.de

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3641] New: Improved SELinux support for openssh

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3641

Bug ID: 3641
   Summary: Improved SELinux support for openssh
   Product: Portable OpenSSH
   Version: 9.5p1
  Hardware: Other
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P5
 Component: Miscellaneous
  Assignee: unassigned-b...@mindrot.org
  Reporter: jseg...@suse.de

We (openSUSE) recently added patches for openssh that Fedora already
carried for a long time:
https://build.opensuse.org/package/show/openSUSE:Factory/openssh

We added five patches:
* openssh-7.8p1-role-mls.patch
  Proper handling of MLS systems and basis for other SELinux
  improvements
* openssh-6.6p1-privsep-selinux.patch
  Properly set contexts during privilege separation
* openssh-6.6p1-keycat.patch
  Add ssh-keycat command to allow retrival of authorized_keys
  on MLS setups with polyinstantiation
* openssh-6.6.1p1-selinux-contexts.patch
  Additional changes to set the proper context during privilege
  separation
* openssh-7.6p1-cleanup-selinux.patch
  Various changes and putting the pieces together

I would like to get these changes upstream. SELinux is now pretty
common on Linux systems and without these patches some functionality
(e.g. proxy jump doesn't work).

I want to see if you're in general willing to take this. Because the
current state would need to be reworked to have this split up a bit
better, but I would not do this if you don't want to take it.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #11 from Darren Tucker  ---
I'd like to reproduce this locally.  Could you please attach
/etc/os-release and the output of "dpkg -l" from the affected device?

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #10 from Darren Tucker  ---
(In reply to Damien Miller from comment #9)
> It's likely that something is trying to use the epoll(3) API.
> OpenSSH itself doesn't use epoll, so it's likely to be something in
> libc, libcrypto or another library.

That's possible.  I checked /etc/os-release on my device, and it's
stock Debian not Raspbian.   My guess would be something in libcrypto,
in which case configuring --without-openssl and retesting would be a
good indicator).

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 1323] ssh-add: add an option to disable passphrase querying (batch mode)

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=1323

--- Comment #3 from Damien Miller  ---
This is possible now using SSH_ASKPASS_REQUIRE:

env SSH_ASKPASS_REQUIRE=force SSH_ASKPASS=/bin/false ssh-add ...
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #9 from Damien Miller  ---
hmm, it looks like I might have been wrong with the syscall number:

> [djm@djm linux]$ grep ' 20$' include/uapi/asm-generic/unistd.h
> #define __NR_epoll_create1 20

It's likely that something is trying to use the epoll(3) API. OpenSSH
itself doesn't use epoll, so it's likely to be something in libc,
libcrypto or another library.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3640] New: Document scp wildcards working only in one direction

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3640

Bug ID: 3640
   Summary: Document scp wildcards working only in one direction
   Product: Portable OpenSSH
   Version: 9.5p1
  Hardware: Other
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P5
 Component: scp
  Assignee: unassigned-b...@mindrot.org
  Reporter: jida...@jidanni.org

On the scp man page, perhaps mention that wildcards only work in one
direction:

$ set notes.txt
$ scp neurdpro.org:m.j*.o*/X/$@ .
notes.txt 100% 497615.5KX/s   00:00
$ scp $@ neurdpro.org:m.j*.o*/X/
scp: dest open "m.j*.o*/X/": No such file or directory
scp: failed to upload file notes.txt to m.j*.o*/X/

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #8 from Darren Tucker  ---
Created attachment 3765
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3765=edit
config.h from 9.2p1 working on rpi4

here's the configure output and config.h from my working system for
comparison.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #7 from Darren Tucker  ---
Created attachment 3764
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3764=edit
configure output from 9.2p1 working on rpi4

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #6 from Darren Tucker  ---
JM: what compiler are you using?

Another thing that might be interesting is to compare config.h and the
output of configure from 9.1p1 with those of 9.2p1 and see if anything
unexpectedly changed.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #5 from Darren Tucker  ---
(In reply to Damien Miller from comment #4)
> This is the details of the sandbox violation:
> 
> > ssh_sandbox_violation: unexpected system call (arch:0x4028,syscall:20 @ 
> > 0xf7ba380c
> 
> syscall 20 is getpid:
> 
> > [djm@djm linux]$ grep 'NR.* 20$' arch/arm64/include/asm/unistd32.h
> > #define __NR_getpid 20

That's not what it is on my rpi4.  I think that's for 32bit ARM.

$ uname -a
Linux hostname 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr  3 17:24:16 BST
2023 aarch64 GNU/Linux
$ grep -r -E '__NR.*20$' /usr/include
/usr/include/asm-generic/unistd.h:#define __NR_epoll_create1 20

$ grep -E NR.*getpid /usr/include/asm-generic/unistd.h
#define __NR_getpid 172

which a test program confirms:

$ cat test.c
#include 
#include 
int main(void)
{
printf("__NR_epoll_create1 %d\n", __NR_epoll_create1);
printf("__NR_getpid %d\n", __NR_getpid);
}
$ cc test.c && ./a.out
__NR_epoll_create1 20
__NR_getpid 172

Testing on a 32bit arm, that is indeed 20:
$ uname -a
Linux hostname 5.16.10-bone14 #1bullseye PREEMPT Tue Feb 22 00:07:39
UTC 2022 armv7l GNU/Linux

$ cc test.c && ./a.out
__NR_epoll_create1 357
__NR_getpid 20

So perhaps the problem here is that either it's picking up 32bit vs
64bit headers, or that the binary is some kind of 32bit compatibility
mode but the sandbox is expecting the 64bit syscalls.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

Damien Miller  changed:

   What|Removed |Added

 CC||d...@mindrot.org

--- Comment #4 from Damien Miller  ---
This is the details of the sandbox violation:

> ssh_sandbox_violation: unexpected system call (arch:0x4028,syscall:20 @ 
> 0xf7ba380c

syscall 20 is getpid:

> [djm@djm linux]$ grep 'NR.* 20$' arch/arm64/include/asm/unistd32.h
> #define __NR_getpid 20

but getpid is allowed by the sshd sandbox policy:

> [djm@djm openssh]$ grep -A1 getpid sandbox-seccomp-filter.c
> #ifdef __NR_getpid
>   SC_ALLOW(__NR_getpid),
> #endif

However, this only works in __NR_getpid is defined in a system header
than that header is correctly picked up during sshd's compilation. If
your system headers are messed up then sshd won't pick up the correct
syscall number and sandbox violations will occur.

You could try attaching ./configure output and config.h (please don't
paste them inline), which might help, but I suspect that the root cause
is going that your system headers are messed up in some way.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT due to ssh_sandbox_violation

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

JM  changed:

   What|Removed |Added

Summary|server thread aborts during |server thread aborts during
   |client login after  |client login after
   |receiving SSH2_MSG_KEXINIT  |receiving SSH2_MSG_KEXINIT
   ||due to
   ||ssh_sandbox_violation

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #3 from JM  ---
Created attachment 3763
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3763=edit
full formatted output of prctl(PR_SET_SECCOMP, ...)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

--- Comment #2 from JM  ---
tl;dr `strace` reveals error
`"\0\0\0c\0\0\0\1\0\0\0\0\0\0\0Wssh_sandbox_violation: unexpected
system call (arch:0x4028,syscall:20 @ 0xf7ba380c)"`
in response to a very large `prctl` Linux function call. (skip to the
end to see)

> try 9.5p1, 

Per my prior comment, I have tried 9.5p1. I tried 9.1p1 to 9.5p1. Only
9.1p1 didn't have this bug.

> I'd suggest building with -DSANDBOX_SECCOMP_FILTER_DEBUG to get additional 
> debugging on what's failing

I tried this with 9.5p1.

Built with the flag `DSANDBOX_SECCOMP_FILTER_DEBUG`

CFLAGS="-DDSANDBOX_SECCOMP_FILTER_DEBUG" ./configure
--prefix=/opt/openssh-9.5p1
make
make install

I could see in the output from `make` echoing the `cc` commands the
`-DSANDBOX_SECCOMP_FILTER_DEBUG` being passed, e.g.

cc -DSANDBOX_SECCOMP_FILTER_DEBUG -pipe
-Wno-error=format-truncation -Wall -Wpointer-arith -Wuninitialized
-Wsign-compare -Wformat-security -Wsizeof-pointer-memaccess
-Wno-pointer-sign -Wno-unused-result -Wimplicit-fallthrough
-Wmisleading-indentation -fno-strict-aliasing -D_FORTIFY_SOURCE=2
-ftrapv -fno-builtin-memset -fstack-protector-strong   -fPIC -I. -I..
-I. -I./..  -D_XOPEN_SOURCE=600 -D_BSD_SOURCE -D_DEFAULT_SOURCE
-D_GNU_SOURCE -DHAVE_CONFIG_H -c bindresvport.c

(so it looks like I passed `-DSANDBOX_SECCOMP_FILTER_DEBUG` correctly)

I added to /opt/openssh-9.5p1/etc/sshd_config

LogLevel DEBUG3

Then I ran `tail -f /var/log/auth.log` on the server.

Then I ran `strace sshd`, e.g.

strace --follow-forks --output-separately -o /tmp/sshd-9.5p1.out --
/opt/openssh-9.5p1/sbin/sshd -D

Elsewhere, login with an ssh client. The connection fails at the same
`debug1: SSH2_MSG_KEXINIT sent`. The `auth.log` has messages:

2023-12-02T20:01:24.242176-08:00 host1 sshd[5905]: debug3: fd 5 is
not O_NONBLOCK
2023-12-02T20:01:24.242601-08:00 host1 sshd[5905]: debug1: Forked
child 5951.
2023-12-02T20:01:24.242819-08:00 host1 sshd[5905]: debug3:
send_rexec_state: entering fd = 8 config len 3236
2023-12-02T20:01:24.243968-08:00 host1 sshd[5951]: debug3:
oom_adjust_restore
2023-12-02T20:01:24.244254-08:00 host1 sshd[5905]: debug3:
ssh_msg_send: type 0
2023-12-02T20:01:24.244408-08:00 host1 sshd[5905]: debug3:
send_rexec_state: done
2023-12-02T20:01:24.244559-08:00 host1 sshd[5951]: debug1: Set
/proc/self/oom_score_adj to 0
2023-12-02T20:01:24.244726-08:00 host1 sshd[5951]: debug1: rexec
start in 5 out 5 newsock 5 pipe 7 sock 8
2023-12-02T20:01:24.268631-08:00 host1 sshd[5951]: debug1: inetd
sockets after dupping: 4, 4
2023-12-02T20:01:24.269001-08:00 host1 sshd[5951]: debug3:
process_channel_timeouts: setting 0 timeouts
2023-12-02T20:01:24.269321-08:00 host1 sshd[5951]: debug3:
channel_clear_timeouts: clearing
2023-12-02T20:01:24.269677-08:00 host1 sshd[5951]: Connection from
10.0.1.2 port 42270 on 192.168.1.2 port 2234 rdomain ""
2023-12-02T20:01:24.269973-08:00 host1 sshd[5951]: debug1: Local
version string SSH-2.0-OpenSSH_9.5
2023-12-02T20:01:24.270263-08:00 host1 sshd[5951]: debug1: Remote
protocol version 2.0, remote software version OpenSSH_8.4p1
Debian-5+deb11u2
2023-12-02T20:01:24.270561-08:00 host1 sshd[5951]: debug1:
compat_banner: match: OpenSSH_8.4p1 Debian-5+deb11u2 pat OpenSSH*
compat 0x0400
2023-12-02T20:01:24.270834-08:00 host1 sshd[5951]: debug2: fd 4
setting O_NONBLOCK
2023-12-02T20:01:24.271097-08:00 host1 sshd[5951]: debug3:
ssh_sandbox_init: preparing seccomp filter sandbox
2023-12-02T20:01:24.271337-08:00 host1 sshd[5951]: debug2: Network
child is on pid 5952
2023-12-02T20:01:24.271573-08:00 host1 sshd[5951]: debug3: preauth
child monitor started
2023-12-02T20:01:24.272750-08:00 host1 sshd[5951]: debug3: privsep
user:group 107:65534 [preauth]
2023-12-02T20:01:24.273121-08:00 host1 sshd[5951]: debug1:
permanently_set_uid: 107/65534 [preauth]
2023-12-02T20:01:24.273369-08:00 host1 sshd[5951]: debug3:
ssh_sandbox_child_debugging: installing SIGSYS handler [preauth]
2023-12-02T20:01:24.273680-08:00 host1 sshd[5951]: debug3:
ssh_sandbox_child: setting PR_SET_NO_NEW_PRIVS [preauth]
2023-12-02T20:01:24.273938-08:00 host1 sshd[5951]: debug3:
ssh_sandbox_child: attaching seccomp filter program [preauth]
2023-12-02T20:01:24.274355-08:00 host1 sshd[5951]: debug1:
monitor_read_log: child log fd closed
2023-12-02T20:01:24.274650-08:00 host1 sshd[5951]: debug3:
mm_request_receive: entering
2023-12-02T20:01:24.274954-08:00 host1 sshd[5951]: debug1:
do_cleanup
2023-12-02T20:01:24.275832-08:00 host1 sshd[5951]: debug1: Killing
privsep child 5952
2023-12-02T20:01:24.241307-08:00 host1 sshd[5905]: debug3: fd 5 is
not O_NONBLOCK
2023-12-02T20:01:24.242538-08:00 host1 sshd[5905]: debug1: Forked
child 5951.
2023-12-02T20:01:24.242765-08:00 host1 sshd[5905]: debug3:
send_rexec_state: entering fd = 8 config len 3236

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

Darren Tucker  changed:

   What|Removed |Added

 CC||dtuc...@dtucker.net

--- Comment #1 from Darren Tucker  ---
(In reply to JM from comment #0)
[...]
> 2023-12-02T12:28:41.053381-08:00 host1 audit[3791]: SECCOMP
> auid=4294967295 uid=107 gid=65534 ses=4294967295 pid=3791
> comm="sshd" exe="/opt/openssh-9.2p1/sbin/sshd" sig=31 arch=4028
> syscall=20 compat=1 ip=0xf787080c code=0x0

This looks like a seccomp sandbox violation.  The first thing I'd
suggest is to try 9.5p1, because there were a couple of bugs fixed in
that specifically (bug#3512 and bug#3537).  There was also a thing
about RNG seeding, but that depended on an interaction between
different kernel and libc versions.

Failing that, I'd suggest building with -DSANDBOX_SECCOMP_FILTER_DEBUG
to get additional debugging on what's failing (but note that this
configuration is for debugging only and is not safe for production use)
and see what's in sshd's log.

FWIW I have an rpi4 with a very similar configuration to what you
describe ("Linux 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr  3 17:24:16 BST
2023 aarch64 GNU/Linux") but was not able to reproduce the failure.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3639] server thread aborts during client login after receiving SSH2_MSG_KEXINIT

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

JM  changed:

   What|Removed |Added

 CC||jtm.moon.forum.user+mindrot
   ||@gmail.com

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3639] New: server thread aborts during client login after receiving SSH2_MSG_KEXINIT

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3639

Bug ID: 3639
   Summary: server thread aborts during client login after
receiving SSH2_MSG_KEXINIT
   Product: Portable OpenSSH
   Version: 9.2p1
  Hardware: ARM
OS: Linux
Status: NEW
  Severity: critical
  Priority: P5
 Component: sshd
  Assignee: unassigned-b...@mindrot.org
  Reporter: jtm.moon.forum.user+mind...@gmail.com

tl;dr I downloaded and compiled openssh-9.2p1.tar.gz . When an openssh
client attempts to login it sends SSH2_MSG_KEXINIT, the server
immediately resets the connection

### Reproduction Steps

Using Raspbian 11 (based on Debian 11 Bullseye) on a Raspberry Pi 4
(ARM aarch64), I downloaded
https://mirror.edgecast.com/pub/OpenBSD/OpenSSH/portable/openssh-9.2p1.tar.gz

I compiled and installed it.

First, make sure necessary build packages are available

apt install \
libssl-dev \
gcc g++ gdb cpp \
make cmake \
libtool \
libc6 \
autoconf automake pkg-config \
build-essential \
gettext \
libzstd1 zlib1g \
libssh-4 libssh-dev libssl3 \
libc6-dev libc6 \
libcrypt-dev

Download, build, install

cd /tmp
wget
https://mirror.edgecast.com/pub/OpenBSD/OpenSSH/portable/openssh-9.2p1.tar.gz
tar -xvf openssh-9.2p1.tar.gz
cd openssh-9.2p1
./configure --prefix=/opt/openssh-9.2p1
make
make install

Adjust sshd_config

vim /opt/openssh-9.2p1/etc/sshd_config

Add lines for a unique port, 2232, increase the log level

Port 2232
LogLevel DEBUG3

Otherwise, the `sshd_config` is used as-is.

Manually start `sshd`

/opt/openssh-9.2p1/sbin/sshd -D

Tail the logs

tail -f /var/log/auth.log

On a different host, attempt to login using the openssh client

PS> ssh.exe root@192.168.1.2 -p 2232 -

The tail of the output shows

...
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: recv - from CB ERROR:10054, io:02E46F4CB690
Connection reset by 192.168.1.2 port 2232

That output is from Windows ssh.exe (OpenSSH_for_Windows_8.6p1,
LibreSSL 3.4.3).

Using Ubuntu 22 x64 ssh (OpenSSH_8.9p1 Ubuntu-3ubuntu0.4, OpenSSL 3.0.2
15 Mar 2022) the ssh client output looks like:

$ ssh root@192.168.1.2 -p 2232 -
...
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
Connection reset by 192.168.1.2 port 2232

Using Debian 11 ARM ssh client compiled from the same compilation
(OpenSSH_9.2p1, OpenSSL 1.1.1w  11 Sep 2023) the same error occurs.

$ /opt/openssh-9.2p1/bin/ssh -p 2232 root@192.168.1.2 -v
...
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
Connection reset by 192.168.1.2 port 2232

The server log messages from `/var/log/auth.log` are

 2023-12-02T12:28:41.051665-08:00 host1 sshd[3790]: Connection from
192.168.1.3 port 62155 on 192.168.1.2 port 2232 rdomain ""
2023-12-02T12:28:41.050817-08:00 host1 sshd[3790]: Connection from
192.168.1.3 port 62155 on 192.168.1.2 port 2232 rdomain ""
2023-12-02T12:28:41.053381-08:00 host1 audit[3791]: SECCOMP
auid=4294967295 uid=107 gid=65534 ses=4294967295 pid=3791 comm="sshd"
exe="/opt/openssh-9.2p1/sbin/sshd" sig=31 arch=4028 syscall=20
compat=1 ip=0xf787080c code=0x0


### Notes

This error does not occur using release 9.1p1.
This error does occur for release 9.2p1 up to 9.5p1 (I tried all of
them).

I attempted to reproduce this on a Ubuntu 22 x64 Virtual Machine as the
server. The error did not occur (logins succeeded).

Various information about the host on which the error occurs

$ lscpu
Architecture:aarch64
Byte Order:  Little Endian
CPU(s):  4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  4
Socket(s):   1
Vendor ID:   ARM
Model:   3
Model name:  Cortex-A72
Stepping:r0p3
CPU max MHz: 1500.
CPU min MHz: 600.
BogoMIPS:108.00
L1d cache:   128 KiB
L1i cache:   192 KiB
L2 cache:1 MiB
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf:  Not affected
Vulnerability Mds:   Not affected
Vulnerability Meltdown:  Not affected
Vulnerability Mmio stale data:   Not affected
Vulnerability Retbleed:  Not affected
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1:Mitigation; __user pointer
sanitization
Vulnerability Spectre v2:Vulnerable
Vulnerability Srbds: Not affected

[Bug 3638] Q

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3638

Bndrs21  changed:

   What|Removed |Added

URL||HTTPS://x.com

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3638] New: Q

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3638

Bug ID: 3638
   Summary: Q
   Product: Portable OpenSSH
   Version: 9.5p1
  Hardware: Other
OS: Mac OS X
Status: NEW
  Severity: enhancement
  Priority: P5
 Component: ssh-rand-helper
  Assignee: unassigned-b...@mindrot.org
  Reporter: whiskers91...@outlook.com

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3627] openssh 9.4p1 does not see RSA keys in know_hosts file.

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3627

--- Comment #18 from openssh bugs  ---
(In reply to Damien Miller from comment #15)
> Created attachment 3756 [details]
> Instrumented sshkey.c again
> 
> I still don't understand what is going wrong, sorry. Please give
> this a try.

Any more information from the latest set of diagnostics?

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3637] Q

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3637

Darren Tucker  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID
 CC||dtuc...@dtucker.net

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3637] New: Q

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3637

Bug ID: 3637
   Summary: Q
   Product: Portable OpenSSH
   Version: 9.3p1
  Hardware: Itanium
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P5
 Component: ssh-rand-helper
  Assignee: unassigned-b...@mindrot.org
  Reporter: whiskers91...@outlook.com

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 2627] Documentation update: semantic of ClientAliveCountMax 0 unclear

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=2627

--- Comment #8 from Christopher Maynard  ---
(In reply to Damien Miller from comment #7)
> If you were relying on an accidental, unreliable and undocumented
> behaviour for security then you always destined to have a bad time. 

The behavior was tested with the options we specified and it worked
exactly as desired.  You chose to make a change that broke that
behavior, seemingly without any regard to its implications, judging by
the lack of any discussions surrounding the change.  Yes, users are
going to have a bad time when developers behave in such ways.

> ClientAliveCountMax=0 *never* worked as a reliable inactivity
> timeout - ServerAliveInterval or a number of other things that
> caused non-session traffic could keep a connection alive
> indefinitely. A security control that appears to work but silently
> fails under common conditions is worse than useless.

You do realize that users control all their own options, don't you? 
And that users generally do test those options to ensure they work as
desired?  I would say a break in functionality that 100% ensures
failure is worse than useless, and borderline malicious.

> We've since added explicit, documented and supported inactivity
> timeout mechanisms (ChannelTimeout and UnusedConnectionTimeout), so
> the previous accidental behaviour of ClientAliveCountMax won't be
> coming back.

And when were those options added?  According to
https://www.openssh.com/releasenotes.html, they were added in OpenSSH
9.2.  So what about those of us using older versions such as OpenSSH
8.2 
 The fact that ClientAliveCountMax=0 behavior changed in OpenSSH 8.2
without regard to backward-compatibility and without those 2 new
options being added in conjunction with that behavioral change in order
to provide a mechanism by which the same behavior could be realized as
before just goes to show how poorly and sloppily the change was made
with barely a thought to its implication.  I sincerely hope that
considerably more thought is given to future changes that break
backward-compatibility than what has been demonstrated here.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3636] New: Public key authentication fails with incorrect message if authorized_keys is not UTF-8 encoded

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3636

Bug ID: 3636
   Summary: Public key authentication fails with incorrect message
if authorized_keys is not UTF-8 encoded
   Product: Portable OpenSSH
   Version: 9.5p1
  Hardware: Other
OS: Other
Status: NEW
  Severity: minor
  Priority: P5
 Component: sshd
  Assignee: unassigned-b...@mindrot.org
  Reporter: alansa...@yahoo.com

Older Windows server. 

Generated the initial authorized_keys file in PowerShell by performing
echo "" >> authorized_keys. 

Received incorrect error: mm_answer_keyallowed: publickey
authentication test: ED25519 key is not allowed

Minor bug, but painful to diagnose that it was an encoding issue.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 2627] Documentation update: semantic of ClientAliveCountMax 0 unclear

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=2627

--- Comment #7 from Damien Miller  ---
If you were relying on an accidental, unreliable and undocumented
behaviour for security then you always destined to have a bad time. 

ClientAliveCountMax=0 *never* worked as a reliable inactivity timeout -
ServerAliveInterval or a number of other things that caused non-session
traffic could keep a connection alive indefinitely. A security control
that appears to work but silently fails under common conditions is
worse than useless.

We've since added explicit, documented and supported inactivity timeout
mechanisms (ChannelTimeout and UnusedConnectionTimeout), so the
previous accidental behaviour of ClientAliveCountMax won't be coming
back.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 2627] Documentation update: semantic of ClientAliveCountMax 0 unclear

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=2627

Christopher Maynard  changed:

   What|Removed |Added

 CC||christopher.mayn...@igt.com

--- Comment #6 from Christopher Maynard  ---
(In reply to Damien Miller from comment #2)
> I committed an alternate change: ClientAliveCountMax=0 will disable
> connection-killing entirely. This will be released in OpenSSH 8.2

I think this was the absolute wrong thing to do.  This bug report was
opened to clarify the documentation about the exact behavior of setting
ClientAliveCountMax=0, not to change the behavior of it, and in doing
so completely break backward-compatibility in the process.

Our organization has just been bitten by this change where previously
idle SSH sessions would automatically time out and terminate after the
configured value of ClientAliveInterval, as expected.  Now this no
longer happens and idle sessions remain active indefinitely.  I fail to
see any possible positive use case for SSH sessions to remain active
indefinitely, and in fact, the new behavior is now perceived as an
increased security risk.

How many idle SSH sessions are unknowingly remaining active now, I
wonder?  In today's security conscious world, this change in behavior
is simply terrible and quite frankly inexcusable.

For the benefit of all users, please revert this change.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 2765] ssh-copy-id appears to hang indefinitely when the target user has no password

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=2765

--- Comment #2 from ymbi...@gmail.com ---
So, I still occasionally get emails about this and keep meaning to come
back to it and here I am. I've just tried to reproduce this using the
version of ssh-copy-id in openssh-client-1:8.2p1-4ubuntu0.9, and
couldn't any more.

In particular, it seems as though this newer ssh client won't
successfully create a session with someone who has no password - I
still get prompted for a password, but since no password is defined I
can't successfully authenticate.

Though being prompted for a password against a user who has none still
feels like slightly odd behaviour, I'm happy that this bug is no longer
reproducible.

Thanks for keeping the ticket open all this time :)

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3526] Config option AddressFamily has no effect?

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3526

renmingshuai  changed:

   What|Removed |Added

 CC||rmsh1...@163.com

--- Comment #14 from renmingshuai  ---
The bz number in the git message of this patch should be 3526 instead
of 5326.
https://anongit.mindrot.org/openssh.git/commit/?id=26f3f3bbc69196d908cad6558c8c7dc5beb8d74a

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3629] Building with Clang-17 fails due to -fzero-call-used-regs

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3629

--- Comment #12 from Bill Wendling  ---
(In reply to David Bohman from comment #11)
> Thank you for the detailed note, I am reading the article now. It is
> about what I expected. Unfortunately, the llvm / clang folks were
> not able to reproduce the problem with this flag on Linux.

I'm going to try again on my MacBook Pro. It'll take a bit though as
it's slooowww.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3635] ssh-add -s always asks for PKCS#11 PIN

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3635

--- Comment #2 from quirin  ---
Just tried the supplied patch. Works like a charm.
Is the -P option going to be incorporated in one of the next releases?

Further do I now see the difficulty of requesting the flags. I didn't
had these different protocol layers in mind.

Thank you very much!

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3629] Building with Clang-17 fails due to -fzero-call-used-regs

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3629

--- Comment #11 from David Bohman  ---
Thank you for the detailed note, I am reading the article now. It is
about what I expected. Unfortunately, the llvm / clang folks were not
able to reproduce the problem with this flag on Linux.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3629] Building with Clang-17 fails due to -fzero-call-used-regs

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3629

--- Comment #10 from Darren Tucker  ---
(In reply to David Bohman from comment #9)
> I cherry-picked 2a19e02 ff220d4 99a2df5 on top of V_9_5_P1, and it
> does build successfully on my system.

Thanks, good to hear!

> Are there security implications associated with not using this flag?

Not immediately.  If there is a security bug in future this flag (and
similar hardening flags) may prevent a given exploit from working, or
make it less likely to work, but the exact effect would depend on the
details of the bug and exploit in question.

This flag makes it harder to write ROP exploits, where an attacker
chains together little fragments of existing code that end in a
"return" (called "gadgets") in a binary.  The attacker finds gadgets
that together do what they want and fakes up a call stack that returns
to each gadget in turn.  The flag zeros (some) registers before
functions return, which may disrupt the intended behaviour.

https://www.jerkeby.se/newsletter/posts/rop-reduction-zero-call-user-regs/
seems like a reasonable explanation.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3629] Building with Clang-17 fails due to -fzero-call-used-regs

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3629

--- Comment #9 from David Bohman  ---
I cherry-picked 2a19e02 ff220d4 99a2df5 on top of V_9_5_P1, and it does
build successfully on my system.

Are there security implications associated with not using this flag?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3629] Building with Clang-17 fails due to -fzero-call-used-regs

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3629

--- Comment #8 from Darren Tucker  ---
Sigh.  Looks like clang is not the only compiler to have problems with
this flag: gcc 11 on mips and mipsel (at least on OpenWRT, not sure if
it's specific to that or not) also does:

cc -g -O2 -pipe -Wno-error=format-truncation -Wall -Wpointer-arith
-Wuninitialized -Wsign-compare -Wformat-security
-Wsizeof-pointer-memaccess -Wno-pointer-sign -Wno-unused-result
-Wimplicit-fallthrough -Wmisleading-indentation -fno-strict-aliasing
-D_FORTIFY_SOURCE=2 -ftrapv -fzero-call-used-regs=used
-fno-builtin-memset -fstack-protector-strong   -fPIC -I. -I.. -I.
-I./..  -D_XOPEN_SOURCE=600 -D_BSD_SOURCE -D_DEFAULT_SOURCE
-D_GNU_SOURCE -DHAVE_CONFIG_H -c arc4random_uniform.c
during RTL pass: final
arc4random_uniform.c: In function 'arc4random_uniform':
arc4random_uniform.c:63:1: internal compiler error: in
mips_output_move, at config/mips/mips.c:5327
   63 | }
  | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
{standard input}: Assembler messages:
{standard input}: Warning: missing .end at end of assembly
{standard input}: Error: open CFI at the end of file; missing
.cfi_endproc directive

$ cc -v
Using built-in specs.
COLLECT_GCC=cc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/mipsel-openwrt-linux-musl/11.2.0/lto-wrapper
Target: mipsel-openwrt-linux-musl
Configured with:
/builder/shared-workdir/build/sdk/build_dir/target-mipsel_24kc_musl/gcc-11.2.0/configure
--target=mipsel-openwrt-linux --host=mipsel-openwrt-linux
--build=x86_64-pc-linux-gnu --program-prefix= --program-suffix=
--prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/lib --sysconfdir=/etc --datadir=/usr/share
--localstatedir=/var --mandir=/usr/man --infodir=/usr/info
--disable-nls 'CXXFLAGS_FOR_TARGET=-g -O2
-D_GLIBCXX_INCLUDE_NEXT_C_HEADERS' --build=x86_64-pc-linux-gnu
--host=mipsel-openwrt-linux-musl --target=mipsel-openwrt-linux-musl
--enable-languages=c,c++ --with-bugurl=https://dev.openwrt.org/
--with-pkgversion='OpenWrt GCC 11.2.0' --enable-shared
--disable-__cxa_atexit --with-default-libstdcxx-abi=gcc4-compatible
--enable-target-optspace --with-gnu-ld --disable-nls
--disable-libsanitizer --disable-libvtv --disable-libcilkrts
--disable-libmudflap --disable-libmpx --disable-multilib
--disable-libgomp --disable-libquadmath --disable-libssp
--disable-decimal-float --disable-libstdcxx-pch
--with-host-libstdcxx=-lstdc++ --prefix=/usr --libexecdir=/usr/lib
--with-local-prefix=/usr --with-stage1-ldflags=-lstdc++
--with-float=soft
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (OpenWrt GCC 11.2.0) 

We can reduce this to a fairly minimal testcase:

$ cat conftest.c 
unsigned int
arc4random_uniform(unsigned int upper_bound)
{
return arc4random() % upper_bound;
}

$ cc -O -fzero-call-used-regs=used -c conftest.c 
conftest.c: In function 'arc4random_uniform':
conftest.c:4:16: warning: implicit declaration of function 'arc4random'
[-Wimplicit-function-declaration]
4 | return arc4random() % upper_bound;
  |^~
during RTL pass: final
conftest.c:5:1: internal compiler error: in mips_output_move, at
config/mips/mips.c:5327
5 | }
  | ^

Prior to my change, the AC_COMPILE_IFELSE test in
OSSH_CHECK_CFLAG_COMPILE was sufficient to catch the problem with
-fzero-call-used-regs=all, but does not catch it with
-fzero-call-used-regs=used.  Expanding the testcase  in
OSSH_CHECK_CFLAG_COMPILE does seem to help:

-void f(int n) {}
+int f(int n) {return rand() % n;}

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3628] tracking bug for openssh-9.6

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3628

Darren Tucker  changed:

   What|Removed |Added

 Depends on||3629


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=3629
[Bug 3629] Building with Clang-17 fails due to -fzero-call-used-regs
-- 
You are receiving this mail because:
You are watching the reporter of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3628] tracking bug for openssh-9.6

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3628
Bug 3628 depends on bug 3629, which changed state.

Bug 3629 Summary: Building with Clang-17 fails due to -fzero-call-used-regs
https://bugzilla.mindrot.org/show_bug.cgi?id=3629

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are watching the reporter of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3629] Building with Clang-17 fails due to -fzero-call-used-regs

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3629

Darren Tucker  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
 Blocks||3628

--- Comment #7 from Darren Tucker  ---
OK,
https://github.com/openssh/openssh-portable/commit/ff220d4010717f7bfbbc02a2400666fb9d24f250
stops using -fzero-call-used-regs on all Apple clang versions.  Please
reopen if this does not solve your problem.

We can allowlist specific versions that are know to work if people
report those.


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=3628
[Bug 3628] tracking bug for openssh-9.6
-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3635] ssh-add -s always asks for PKCS#11 PIN

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3635

Damien Miller  changed:

   What|Removed |Added

 CC||d...@mindrot.org

--- Comment #1 from Damien Miller  ---
Created attachment 3762
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3762=edit
Add ssh-add -P flag to suppress request of PIN

Please try this patch.

This adds a ssh-add -P flag to suppress requesting a PIN. It's not
trivial to query PKCS#11 flags across ssh-add/ssh-agent because there
are two layers of protocol between the UI (ssh-add) and the process
that actually interacts with the PKCS#11 device (ssh-pkcs11-helper).

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3628] tracking bug for openssh-9.6

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3628
Bug 3628 depends on bug 3526, which changed state.

Bug 3526 Summary: Config option AddressFamily has no effect?
https://bugzilla.mindrot.org/show_bug.cgi?id=3526

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are watching the reporter of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3526] Config option AddressFamily has no effect?

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3526

Damien Miller  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #13 from Damien Miller  ---
I've just committed the EAFNOSUPPORT change. Thanks

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3635] New: ssh-add -s always asks for PKCS#11 PIN

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3635

Bug ID: 3635
   Summary: ssh-add -s always asks for PKCS#11 PIN
   Product: Portable OpenSSH
   Version: 9.0p1
  Hardware: Other
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P5
 Component: ssh-add
  Assignee: unassigned-b...@mindrot.org
  Reporter: quirin.bit...@zg.ch

Hi there!

Our HSM provides a PKCS#11 library to use it with software like the
OpenSSH client.
Credentials for the HSM are handled by a configuration file, read by
the PKCS#11 library, outside of the PKCS#11 protocol.
Therefore, no interactive PIN entrance is necessary, and skipping it by
providing an empty PIN, i.e., just pressing enter at the prompt,
hinders our automation.

When using a key, stored on the HSM, to login via ssh, we realized that
ssh -I /path/to/hsm_pkcs11_library and adding a key to a ssh agent with
ssh-add -s /path/to/hsm_pkcs11_library behaves differently.
Login with ssh -I works without any user interaction, but ssh-add -s
always asks interactively for the PIN.

Investigating this behavior, the following was found.

There seem to be two ways for an PKCS#11 token to signalize that no PIN
is required through the PKCS#11 library.
1. By not setting the CKF_LOGIN_REQUIRED flag, which indicates that no
login must be performed and therefore no pin is necessary.
2. By setting the CKF_PROTECTED_AUTHENTICATION_PATH flag which
indicates that the PIN is provided outside of the PKCS#11 library.
See the PKCS#11 3.0 standard for the details [1].

Looking into the code of ssh-add, it was found that with the -s
argument, it asks for a PIN regardless of the PKCS#11 flags.
In [2] it just checks if the add flag is set, which is the case if
neither -e nor -d is provided.

Looking into the code of ssh to understand the behavior of ssh -I
revealed, that it considers the presence of the PKCS#11 flags (at least
partly).
If the CKF_LOGIN_REQUIRED flag is not set, as done by our HSM PKCS#11
library, SSH derives the keys available through the PKCS#11 library as
follows.
1. pkcs11_add_provider [3][4] is called, which calls
pkcs11_register_provider [5] 
2. pkcs11_register_provider performs some sanity checks and setting up,
and then tries to derive keys for the slots available [6]
3. For deriving keys a PKCS#11 session is opened by calling
pkcs11_open_session [7]. pkcs11_open_session checks if the
CKF_LOGIN_REQUIRED flag is set [8] and fails if it is set but no PIN
was provided.
4. After establishing a session pkcs11_fetch_keys is called [9], to
derive keys
5. If it was not possible to derive at least one key and no login took
place yet and the session is interactive, pkcs11_login_slot [10] is
called to perform a login.
   pkcs11_login_slot checks for the CKF_PROTECTED_AUTHENTICATION_PATH
flag [11] and allows the PIN entry to happen outside the PKCS#11
library.
   If the login was successful, pkcs11_fetch_keys is called again to
derive keys.


With these findings, the following questions arises.
- Did I miss a way to login via ssh, besides ssh -I and
ssh-agent/ssh-add -s, using a key provided by a PKCS#11 library?
- Are there any plans to adjust the behavior of ssh-add -s regarding
PKCS#11 PIN prompts to the one of ssh -I?
- Shouldn't ssh check for the CFK_LOGIN_REQUIRED flag, before trying to
login & deriving keys in step 5., if no keys were derived without
login?
- Would it be a possibility to, besides checking the PKCS#11 flags,
introduce an CLI argument that skips the interactive PKCS#11 PIN
entrance at all? 
  I could imagine that some PKCS#11 libraries get the login data
elsewhere but may not set the flags accordingly.

Thanks in advance!

Quirin


[1]
https://docs.oasis-open.org/pkcs11/pkcs11-base/v3.0/os/pkcs11-base-v3.0-os.html
[2]
https://github.com/openssh/openssh-portable/blob/26f3f3bbc69196d908cad6558c8c7dc5beb8d74a/ssh-add.c#L453
[3]
https://github.com/openssh/openssh-portable/blob/26f3f3bbc69196d908cad6558c8c7dc5beb8d74a/ssh.c#L2303
[4]
https://github.com/openssh/openssh-portable/blob/26f3f3bbc69196d908cad6558c8c7dc5beb8d74a/ssh-pkcs11.c#L1672
[5]
https://github.com/openssh/openssh-portable/blob/26f3f3bbc69196d908cad6558c8c7dc5beb8d74a/ssh-pkcs11.c#L1511
[6]
https://github.com/openssh/openssh-portable/blob/26f3f3bbc69196d908cad6558c8c7dc5beb8d74a/ssh-pkcs11.c#L1598
[7]
https://github.com/openssh/openssh-portable/blob/26f3f3bbc69196d908cad6558c8c7dc5beb8d74a/ssh-pkcs11.c#L1622
 
[8]
https://github.com/openssh/openssh-portable/blob/26f3f3bbc69196d908cad6558c8c7dc5beb8d74a/ssh-pkcs11.c#L660
[9]
https://github.com/openssh/openssh-portable/blob/26f3f3bbc69196d908cad6558c8c7dc5beb8d74a/ssh-pkcs11.c#L1625
[10]
https://github.com/openssh/openssh-portable/blob/26f3f3bbc69196d908cad6558c8c7dc5beb8d74a/ssh-pkcs11.c#L1633
[11]
https://github.com/openssh/openssh-portable/blob/26f3f3bbc69196d908cad6558c8c7dc5beb8d74a/ssh-pkcs11.c#L260

-- 
You are receiving this mail 

[Bug 3526] Config option AddressFamily has no effect?

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3526

nix-mu...@gmx.net changed:

   What|Removed |Added

   Attachment #3746|0   |1
is obsolete||
 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED
   Assignee|unassigned-b...@mindrot.org |nix-mu...@gmx.net

--- Comment #12 from nix-mu...@gmx.net ---
Created attachment 3761
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3761=edit
filter addresses by AddressFamily at connect time

Whoa, wait a sec. As Damien pointed out, my patch was clearly faulty.

I am absolutely not a dev, fairly new to FOSS contributions, and as a
non native english speaker am still a bit concerned about the risk that
`errno = EAFNOSUPPORT` (Address family not supported by protocol
family) might be misleading and/or platform dependent. 
I thought I could find some time to learn enough C to work out
something smarter. That did so far not work out a bit. Sorry for
stalling this so long.

This patch restores Damien's correct position of the new code while
keeping EAFNOSUPPORT with a slightly more specific debug2 output.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3634] New: IPQoS default should be changed to "none"

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3634

Bug ID: 3634
   Summary: IPQoS default should be changed to "none"
   Product: Portable OpenSSH
   Version: 9.5p1
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P5
 Component: Miscellaneous
  Assignee: unassigned-b...@mindrot.org
  Reporter: daisuke.higa...@gmail.com

Created attachment 3760
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3760=edit
IPQoS none patch

In this trouble ticket, I propose to change the default value of IPQoS
option to "none none”. A patch is attached.


- Problem description

  Starting with OpenSSH 7.8, the DSCP value for packets sent by OpenSSH
has changed to AF21 (interactive) /CS1 (bulk) [1]. After this change,
there have been numerous reports of poor OpenSSH performance [2].  The
cause of this problem is that some networks enforce various
restrictions (rate-limiter or policer) on some DSCP traffic and
OpenSSH’s new DSCP values hits this restrictions. The workaround for
this problem is to set IPQoS cs0 (DSCP=0) or to use old OpenSSH
version’s value (IPQoS throughput).

  We cannot simply blame OpenSSH's new DSCP value for this problem. Nor
can we blame the behavior of the network; the real cause of this
problem is just that the combination of the network's QoS policy (which
varies from network to network) and OpenSSH's new DSCP values are not
compatible [3].

- Propose

  To address this mismatch issue, OpenSSH should use DSCP=0 by default,
which is corresponding to the default PHB. Since most platforms use
DSCP=0 by default, OpenSSH should use platform’s default value.  i.e.
“IPQoS none none" should be default setting for OpenSSH.


- DSCP=0 rationale

  The default PHB (a.k.a best effort forwarding behavior) is a class
that networks must implement in Diffserv architectures, and it is
recommended that DSCP=0 is mapped to the default PHB [RFC2474 4.1]. In
practice most network applications use DSCP=0 by default and have not
experienced problems like OpenSSH. So DSCP=0 by default is considered a
good practice.

- References

[1] AF21/CS1 changes.
 
https://lists.mindrot.org/pipermail/openssh-unix-dev/2018-April/036788.html

[2] Numerous reports of poor OpenSSH performance.
https://unix.stackexchange.com/questions/718686/unable-to-connect-to-anything-using-ssh
https://wiki.archlinux.org/title/OpenSSH#Broken_pipe
https://wiki.osuosl.org/howtos/ssh_ip_qos_fix.html
Or Google “IPQoS OpenSSH”


[3] A real example of mismatch.

  One of Japan's largest ISP is known that they treat CS1 (DSCP=8) as
high priority (low latency, low discard), but limit the amount of
incoming traffic to prevent the network from filling up with high
priority traffic. Many other ISPs use similar QoS policy (high priority
but rate-limited for certain traffic class) in practice.
  While this QoS policy was to protect their network and their purpose
was NOT to limit OpenSSH performance, the mismatch between this QoS
policy and OpenSSH's new DSCP values results in OpenSSH's poor
performance.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3627] openssh 9.4p1 does not see RSA keys in know_hosts file.

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3627

--- Comment #17 from openssh bugs  ---
(In reply to Damien Miller from comment #15)
> Created attachment 3756 [details]
> Instrumented sshkey.c again
> 
> I still don't understand what is going wrong, sorry. Please give
> this a try.



That is some neat diagnostic coding you put in. Hopefully this will
help.

I have uploaded the diagnostics.  bugzilla.11172023


Still getting:

hostfile_read_key: sshkey_read /export/home/user/.ssh/known_hosts:1:
invalid format

 /export/home/user/.ssh/known_hosts:1: parse error in hostkeys file


However OpenSSH_6.0p1, OpenSSL 1.0.2t can read the known_host file that
OpenSSH_9.4p1, OpenSSL 3.1.2 creates.

Thank you for your assistance with this.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3627] openssh 9.4p1 does not see RSA keys in know_hosts file.

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3627

openssh bugs  changed:

   What|Removed |Added

   Attachment #3754|0   |1
is obsolete||

--- Comment #16 from openssh bugs  ---
Created attachment 3759
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3759=edit
november 17 diagnostics.

That is some neat diagnostic coding you put in. Hopefully this will
help.

Still getting:

hostfile_read_key: sshkey_read /export/home/user/.ssh/known_hosts:1:
invalid format

 /export/home/user/.ssh/known_hosts:1: parse error in hostkeys file


However OpenSSH_6.0p1, OpenSSL 1.0.2t can read the known_host file that
OpenSSH_9.4p1, OpenSSL 3.1.2 creates.

Thank you for your assistance with this.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3531] Ssh will not exit when it receives SIGTERM before calling poll in client_wait_until_can_do_something until some events happen.

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3531

--- Comment #7 from Damien Miller  ---
this has been applied and will be in the openssh-9.6 release, due in
late December

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3628] tracking bug for openssh-9.6

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3628
Bug 3628 depends on bug 3526, which changed state.

Bug 3526 Summary: Config option AddressFamily has no effect?
https://bugzilla.mindrot.org/show_bug.cgi?id=3526

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching the reporter of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3526] Config option AddressFamily has no effect?

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3526

Damien Miller  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Damien Miller  ---
this has been applied and will be in openssh-9.6, due in late December

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3526] Config option AddressFamily has no effect?

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3526

Darren Tucker  changed:

   What|Removed |Added

   Attachment #3746|ok?(dtuc...@dtucker.net)|ok+
  Flags||

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3526] Config option AddressFamily has no effect?

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3526

Damien Miller  changed:

   What|Removed |Added

 CC||dtuc...@dtucker.net
   Attachment #3746||ok?(dtuc...@dtucker.net)
  Flags||

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3477] Support environment variable or %u token for User

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3477

--- Comment #1 from Ben Creasy  ---
I figured out how to make this work by using %r in the ProxyCommand and
an environment variable using ${VARIABLE}. The %r is for remote user -
I think it's configured in the bastion server or something?

I don't have the ssh config handy since it's work related but I may
reproduce it on my personal machine at some point.

Ultimately I was able to make an ssh config with no hardcoded
usernames, but I still think it would be useful and intuitive to allow
for a variable in the User configuration itself.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 2966] scp client-side filename matching problems

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=2966

--- Comment #11 from Damien Miller  ---
Sorry, that trace isn't any use because 1) it isn't from scp and 2)
it's not from scp in verbose mode (scp -vvv)

If you can attach a debug trace from scp that shows the problem
compiled from either github HEAD or from openssh-9.6 (which will be
released soon) then we can diagnose this further.

Alternately, if you're using Microsoft's version of OpenSSH on the
client then you should contact them for support.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3474] ssh_config can escape double quotes with a backslash

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3474

--- Comment #7 from Damien Miller  ---
Created attachment 3758
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3758=edit
Make Match keywords in ssh_config and sshd_config use argv rather than
strdelim

This changes the argument splitting of Match to use the argv tokeniser
that is used for the rest of config parsing. Please test.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 2966] scp client-side filename matching problems

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=2966

--- Comment #10 from Senku <197r1a0...@gmail.com> ---
It's a Windows client
I have attached the error trace.
The file I'm trying to fetch is "template_nt64.log", for copying from
the TeamCity Agent machine to the remote VM I'm not getting any error
but for fetching, I'm getting the protocol error
I have also added export ANSIBLE_SCP_EXTRA_ARGS="-T" to the build
steps.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 2966] scp client-side filename matching problems

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=2966

--- Comment #9 from Senku <197r1a0...@gmail.com> ---
Created attachment 3757
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3757=edit
Error Trace

Error Trace

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 2966] scp client-side filename matching problems

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=2966

--- Comment #8 from Damien Miller  ---
Is your client Windows or Unix?

Could you attach a debug trace? If you're able to compile and use
openssh git HEAD then there are were some extra diagnostics added in
https://github.com/openssh/openssh-portable/commits/c97520d23d1fe53d30725a2af25d26f2faff
that are likely to help figure out what is going wrong.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 3627] openssh 9.4p1 does not see RSA keys in know_hosts file.

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=3627

Damien Miller  changed:

   What|Removed |Added

   Attachment #3750|0   |1
is obsolete||
   Attachment #3755|0   |1
is obsolete||

--- Comment #14 from Damien Miller  ---
Created attachment 3755
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3755=edit
Updated sshkey.c

Please try again with the replacement sshkey.c file. I simply don't
understand what is going wrong here.

--- Comment #15 from Damien Miller  ---
Created attachment 3756
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3756=edit
Instrumented sshkey.c again

I still don't understand what is going wrong, sorry. Please give this a
try.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 2966] scp client-side filename matching problems

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=2966

Senku <197r1a0...@gmail.com> changed:

   What|Removed |Added

 CC||197r1a0...@gmail.com
 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #7 from Senku <197r1a0...@gmail.com> ---
I'm trying to fetch files from a remote VM to the agent machine.
The file path is "C:\\scripts\\template_windows.log"
It has no spaces and non ASCII characters, still I'm getting the error
"protocol error: filename does not match request"

any reason for this error? and any solutions
Thank you

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 2217] Allow using _ssh SVCB records

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=2217

--- Comment #4 from Jeremy Saklad  ---
I agree that SVCB is the way to go in the future. One nuance: in
keeping with
, I think
SSHFP records should be requested for the target server, and only used
if the SVCB records are also secured with DNSSEC.

SSHFP records could also be designated for automatic retrieval similar
to A/ records, with the support of resolvers.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 2217] Allow using _ssh SVCB records

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=2217

--- Comment #3 from chr...@fsfe.org ---
With the advent of RFC9460, I've updated the title (sorry for the
double edit) to using SVCB records instead of SRV.

While the essence stays the same, SVCB records are described better,
especially with respect to their security properties, and provide more
flexible metadata, so I think they are the way to go.

How it would work (2023 edition)


* When connecting to a hostname host.example.com, SSH sends in parallel
(as it does A and  records) a request for `SVCB
_ssh.host.example.com`. If the recursive resolver didn't already follow
the chain of alias records and eventually A(AAA) records, it follows
them on its own through the mechanism described in RFC9460.

* SSH selects any of the lowest priority results (usually just "the"
result, and IIRC from the RFC it's fine to just try one; failover can
still be added later). If specified it picks the port from it, and
connects to that address and port.

Complications
=

IIUC there should be a spec for using SSH with SVCB before using it --
at least there needs to be an entry in "Underscored and Globally Scoped
DNS Node Names"
.
I'm happy to help out with the paperwork there (even if it means
writing an internet draft), but I won't take any action unless there is
at least a friendly snort from the SSH community indicating that it
would be taken up.

Side benefits
=

I've mentioned the convenience of server-configured ports in the
original report already. With the state of the IPv6 migration, SVCB
records (or anything that allows server configured ports) bring
additional benefits: Some users' ISPs offer only either static IPv4
addresses and no IPv6, or regular IPv6 but CGNAT. This forces users who
need to reach their home servers (eg. from a work environment that has
no IPv6 yet) into a no-IPv6 situation. If they can use PCP, they can
open ports locally, and PCP will tell them a public IP address and port
(generally not 22, and generally neither stable) to use. Using dynamic
DNS and SVCB records, they can publish their home address including the
port on a stable location.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs