DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 50HEekUR708478
Authentication-Results:	delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com
Authentication-Results:	delorie.com; spf=pass smtp.mailfrom=cygwin.com
DKIM-Filter:	OpenDKIM Filter v2.11.0 delorie.com 50HEekUR708478
Authentication-Results:	delorie.com;
	dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=PNsxQK6h
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 05DC43847705
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1737124845;
	bh=+n9oY9Jb9g4MfOTya7E3wq/L9ItPcLYfyFLd3jqolww=;
	h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	From;
	b=PNsxQK6hEP+I5LbE63io83Y8PSmXd1K2PKMHpV3xbQNj83Djsxk0+WJDHBNDWku3m
	6ta8xByLkqC1YGlT0yaCmW6psvjiQ9BQo4IN2Slu5GJcLy/A7zEA+DbMO0yWaqsCoT
	eKFCJ5Zibf8isiDg7NW5FL09zvRJ8B4aR4GOli8o=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org BD5D63847704
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org BD5D63847704
ARC-Seal:	i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1737124814; cv=none;
	b=JYqVVLSiHPs7v6T0qQsGu9E61WQP2uR/m3tAupQIt6+oWNm9onPpgTZIjBA4TUAsiJznMeERBUWbLEult2lVOgfsxd76varjqMgWu8gkesibpsDi0rNLKnqFfCNQg4K2KJReYaL8b0V9MUdEPqELFd0rAn740h2yHqu0/zAlS5Q=
ARC-Message-Signature:	i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1737124814; c=relaxed/simple;
	bh=vLi7olJMahyUo64RbXwJ80vE3CofPSofwoJAgPsnx2c=;
	h=DKIM-Signature:Message-ID:Date:MIME-Version:To:From:Subject;
	b=VBX8sLbBRDZIxR/B8OsP0NVu8GQCNjAagb+0+pgbX/G6MTNfe/cEll1csPwAoKPKXWWGRJUJT3Mtv6J42ubGSYh6L2e2rN/CoCKIy44XwuN/sGQ4+VRSRrqh7RQcx9fzv2QEv980VYTnPFDnJexB4ak4VyE78JqGriaXI2dASkM=
ARC-Authentication-Results:	i=1; server2.sourceware.org
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org BD5D63847704
Message-ID:	<0da8b72e-f213-4535-b800-7d180757667b@emmenlauer.de>
Date:	Fri, 17 Jan 2025 15:37:56 +0100
MIME-Version:	1.0
User-Agent:	Mozilla Thunderbird
To:	cygwin AT cygwin DOT com
References:	<LTQOVCXmc0omW9pKR5Kf2VV2rkqMLBgNy-HyfSog-h2-eEjbnJroxxEUCUTKQSQrMGXaZJ7FH2qocwS-hpfW3RveKOrq-HlRtJqh7NDg8w4=@proton.me>
	<CAL63K1XbYdKYGxacM-ifuakReCQefYB1K5MmWS2YuT2+La=RdQ AT mail DOT gmail DOT com>
	<6c39972b-43ef-4e32-a238-f2778f3cc4e5 AT emmenlauer DOT de>
	<Z4pSUtv0CdZNZSo4 AT calimero DOT vinschen DOT de>
	<6e459d03-150e-4dd3-8fed-9fbe7dbcff40 AT SystematicSW DOT ab DOT ca>
	<Z4pikbPJz1kDINbY AT calimero DOT vinschen DOT de>
In-Reply-To:	<Z4pikbPJz1kDINbY@calimero.vinschen.de>
X-SA-Exim-Connect-IP:	77.24.102.157
X-SA-Exim-Mail-From:	mario AT emmenlauer DOT de
Subject:	Re: sshd not working properly
X-SA-Exim-Version:	4.2.1 (built Tue, 16 Feb 2021 15:21:40 +0000)
X-SA-Exim-Scanned:	Yes (on merope.marssoft.de)
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.30
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe:	<https://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From:	Mario Emmenlauer via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	Mario Emmenlauer <mario AT emmenlauer DOT de>
Errors-To:	cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>

On 17.01.25 15:00, Corinna Vinschen via Cygwin wrote:
> On Jan 17 06:41, Brian Inglis via Cygwin wrote:
>> On 2025-01-17 05:51, Corinna Vinschen via Cygwin wrote:
>>> On Jan 17 11:59, Mario Emmenlauer via Cygwin wrote:
>>>> I am under the impression that there may be a misbehavior in more recent
>>>> Cygwin OpenSSH :-(
>>>>
>>>> I observe the same problem as Andy Wood was having, and found another
>>>> very recent identical report at https://serverfault.com/q/1168457/473559.
>>>> Their cases, as well as mine, seem to share, that OpenSSH can no longer
>>>> correctly authenticate as a user without having the plain text password
>>>> stored in the registry.
>>>>
>>>> In my case, this is exclusively limited to domain users. Local users
>>>> work correctly. I can see that at least one other report, the one at
>>>> Serverfault, is also for a domain user. Also, everything that is
>>>> reported at Serverfault applies basically identically to my case, i.e.
>>>> the connection being just dropped, and the only relevant message from
>>>> OpenSSH being "fatal: seteuid 4096: Function not implemented".
>>>
>>> I just tested this on my local W11 24H2 Enterprise installation with
>>> Cygwin 3.5.5 and OpenSSH 9.9p1 installed as service under the SYSTEM
>>> account, and it works fine for me in a Windows domain with one 2019 and
>>> one 2022 Domain Server.

I just realized that maybe I missed something important: My user accounts
are domain users from a company, but I think they are just registered with
Microsoft, is that possible? I'm an external user of that company, and the
computers are not in the company domain - I did not register them with any
particular domain server. From my naiive point of view, its just Microsoft
accounts, that happen to be for a company domain, and I can use them i.e.
with all the Microsoft online services like Office 365 or Visual Studio.
Could that be a problem, that I need to be in the company domain for things
to work, or that I need to register with a company domain server? I'm very
new to the whole Microsoft ecosystem :-/


>>> I tested with a user account in the administrators group as well as with
>>> a non-admin user account, and to both accounts I can login with pubkey
>>> authentication as expected.
>>>
>>> The error message "seteuid 4096: Function not implemented" is weird.
>>> The internal implementation only uses documented functions.

>>> Which Windows version are you running the service on exactly?

This is Windows 11 Pro 24H2, OS build 26100.2894, that was installed
newly from scratch just this week. Actually all my tested machines are
the same Windows and Cygwin versions, all newly installed this week,
albeit different hardware.


>>> Do you have any other entries in the server-side Windows Log, which may
>>> be connected, especially inside the Security log.  Kerberos or so.

Yes, I do. The message shown above is the only one in the Application
event log. However, in the Security event log, there are events of type
"Audit Failure". The most relevant section seems to be "EventData",
that I copy here (with some comments from me, added at the end):

----
An account failed to log on.

Subject:
	Security ID:		SYSTEM
	Account Name:		AIDAN07$          # my computer hostname
	Account Domain:		WORKGROUP
	Logon ID:		0x3E7

Logon Type:			3

Account For Which Logon Failed:
	Security ID:		NULL SID
	Account Name:		
	Account Domain:		MYCOMPANY          # the company name

Failure Information:
	Failure Reason:		An Error occured during Logon.
	Status:			0xC00000BB
	Sub Status:		0x0

Process Information:
	Caller Process ID:	0x3988
	Caller Process Name:	C:\cygwin64\usr\sbin\sshd-session.exe

Network Information:
	Workstation Name:	-
	Source Network Address:	-
	Source Port:		-

Detailed Authentication Information:
	Logon Process:		Cygwin.1
	Authentication Package:	MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
	Transited Services:	-
	Package Name (NTLM only):	-
	Key Length:		0

This event is generated when a logon request fails. It is generated on the computer where access was attempted.

The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local 
process such as Winlogon.exe or Services.exe.

The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

The Process Information fields indicate which account and process on the system requested the logon.

The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.
	- Transited services indicate which intermediate services have participated in this logon request.
	- Package name indicates which sub-protocol was used among the NTLM protocols.
	- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
----

I can not see any other relevant logs right now. I may need to enable
Cygwin logging, I guess? It will be more verbose? Is the guide at
https://superuser.com/a/1550243/1053994 suitable for modern Cygwin sshd
logging?


>>> Other than that, it might be prudent to run sshd in a SYSTEM shell
>>> under strace.
>>
>> Any chance the user is also running Windows sshd and tyhat has grabbed the port?
> 
> Good point, worth checking...
Sorry, that was missing from my list: I'm running Cygwin sshd on custom
port 22120, but also checked, Windows OpenSSH is disabled.

All the best,

    Mario



-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

- Raw text -