seteuid problem with sshd

seteuid problem with sshd

[Bruce Halco]

I'm having to update a number of cygwin installations that are about a 
year old (cygwin 2.9.0-3). Usually I just run the installer and 
everything goes fine.  Occasionally I've run into a problem and had to 
remove the existing installation and reinstall.

Apparently something has changed with ssh.  I now go though the same 
installation process I've been using for years, but sshd logins fail 
after connection with

     "fatal: seteuid xxxxxx: No such file or directory"

The ssh client gets as far as offering the key. The last two lines from 
the client side are

     debug1: Offering public key: bhalco.ssh RSA 
SHA256:DDFVOXwQIpPODxXJPxp8Mxj1Y1mXsMqdmrvVYi5P51c agent
     Connection closed by 192.168.0.12 port 32000

I've reproduced the problem on two computers. Both are running Windows 
7, although the same update will need to be applied to Windows 10 systems.

I haven't found any info using Google or the cygwin archives.

I don't even have a good guess what file or directory is missing.

I'd greatly appreciate any suggestions.

Bruce Halco


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

Re: seteuid problem with sshd

[Houder]

On Wed, 13 Mar 2019 19:26:11, Bruce Halco  wrote:
> I'm having to update a number of cygwin installations that are about a 
> year old (cygwin 2.9.0-3). Usually I just run the installer and 
> everything goes fine.  Occasionally I've run into a problem and had to 
> remove the existing installation and reinstall.
> 
> Apparently something has changed with ssh.  I now go though the same 
[snip]

> I haven't found any info using Google or the cygwin archives.
> 
> I don't even have a good guess what file or directory is missing.
> 
> I'd greatly appreciate any suggestions.

Look for "sshd" in the mailinglists of March and February (2019).

Yes, Cygwin has changed mid-February (end of February).

Examples:

 - https://cygwin.com/ml/cygwin/2019-02/msg00326.html
 - https://cygwin.com/ml/cygwin/2019-03/msg00316.html

Henri


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

Re: seteuid problem with sshd

[Andrey Repin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 1625 bytes --]

Greetings, Bruce Halco!

> I'm having to update a number of cygwin installations that are about a 
> year old (cygwin 2.9.0-3). Usually I just run the installer and 
> everything goes fine.  Occasionally I've run into a problem and had to 
> remove the existing installation and reinstall.

> Apparently something has changed with ssh.  I now go though the same 
> installation process I've been using for years, but sshd logins fail 
> after connection with

>      "fatal: seteuid xxxxxx: No such file or directory"

> The ssh client gets as far as offering the key. The last two lines from 
> the client side are

>      debug1: Offering public key: bhalco.ssh RSA 
> SHA256:DDFVOXwQIpPODxXJPxp8Mxj1Y1mXsMqdmrvVYi5P51c agent
>      Connection closed by 192.168.0.12 port 32000

> I've reproduced the problem on two computers. Both are running Windows 
> 7, although the same update will need to be applied to Windows 10 systems.

> I haven't found any info using Google or the cygwin archives.

Please don't lie. The archive is full of recent reports.

> I don't even have a good guess what file or directory is missing.

> I'd greatly appreciate any suggestions.

Try changing the owning user of sshd service to LocalSystem for a starter.


-- 
With best regards,
Andrey Repin
Thursday, March 14, 2019 2:48:44

Sorry for my terrible english...\x03B‹KCB”\x1c›Ø›\x19[H\x1c™\^[ܝ\x1cΈ\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÜ\x1c›Ø›\x19[\Ëš\x1d^[[\x03B‘TNˆ\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÙ˜\KÃB‘^[ØÝ[Y[\x18]\x1a[ÛŽˆ\b\b\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÙ^[ØÜËš\x1d^[[\x03B•[œÝXœØÜšX™H\x1a[™›Îˆ\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÛ[\vÈÝ[œÝXœØÜšX™K\Ú[\^[\x19CBƒB

Re: seteuid problem with sshd

[Bruce Halco]

I had found nothing referencing "No such file or directory", which 
sounds rather different from a permissions problem.

Running sshd under the Local System account made no difference.

passwd -R was no help.

What I did discover was that cygwin/sshd apparently now requires the 
Windows account to be Enabled.  That was not the case previously.

The target systems in my application are in restaurant offices, and only 
use a single Windows login.

As the people who use ssh do not need local Windows accounts, I've 
always used the practice of Disabling those user accounts in Windows. 
The credentials were available to ssh, without the security issues of 
all those extra active accounts.

Unless someone can suggest an alternative, I'll have to leave all those 
accounts Enabled. I can put some long, nasty passwords on them to keep 
the risk acceptable.

Thanks.

Bruce


On 3/13/19 7:50 PM, Andrey Repin wrote:
> Greetings, Bruce Halco!
>
>> I'm having to update a number of cygwin installations that are about a
>> year old (cygwin 2.9.0-3). Usually I just run the installer and
>> everything goes fine.  Occasionally I've run into a problem and had to
>> remove the existing installation and reinstall.
>> Apparently something has changed with ssh.  I now go though the same
>> installation process I've been using for years, but sshd logins fail
>> after connection with
>>       "fatal: seteuid xxxxxx: No such file or directory"
>> The ssh client gets as far as offering the key. The last two lines from
>> the client side are
>>       debug1: Offering public key: bhalco.ssh RSA
>> SHA256:DDFVOXwQIpPODxXJPxp8Mxj1Y1mXsMqdmrvVYi5P51c agent
>>       Connection closed by 192.168.0.12 port 32000
>> I've reproduced the problem on two computers. Both are running Windows
>> 7, although the same update will need to be applied to Windows 10 systems.
>> I haven't found any info using Google or the cygwin archives.
> Please don't lie. The archive is full of recent reports.
>
>> I don't even have a good guess what file or directory is missing.
>> I'd greatly appreciate any suggestions.
> Try changing the owning user of sshd service to LocalSystem for a starter.
>
>


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

Re: seteuid problem with sshd

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1909 bytes --]

On Mar 13 22:20, Bruce Halco wrote:
> I had found nothing referencing "No such file or directory", which sounds
> rather different from a permissions problem.
> 
> Running sshd under the Local System account made no difference.
> 
> passwd -R was no help.
> 
> What I did discover was that cygwin/sshd apparently now requires the Windows
> account to be Enabled.  That was not the case previously.
> 
> The target systems in my application are in restaurant offices, and only use
> a single Windows login.
> 
> As the people who use ssh do not need local Windows accounts, I've always
> used the practice of Disabling those user accounts in Windows. The
> credentials were available to ssh, without the security issues of all those
> extra active accounts.
> 
> Unless someone can suggest an alternative, I'll have to leave all those
> accounts Enabled. I can put some long, nasty passwords on them to keep the
> risk acceptable.

I'm sorry to say that, but there is no alternative.  This has been
discussed at great length on thlis mailing list, starting at

https://cygwin.com/ml/cygwin/2019-01/msg00197.html

For starters, I added a special check to disable logging in with a
disabled account.  However, the S4U logon method used by Cygwin now in
place of the old "Create user token from scratch" method(*) even checks
that automatically and does not allow disabled accounts to logon.

Same goes for the `passwd -R' method as well as for normal password logon
since they have been introduced, btw, given they use the same underlying
WIndows function which actively checks for disabled accounts.

Last but not least, the fact that some logon methods allowed disabled
accounts to logon and some didn't wasn't really a good idea to begin
with.


Corinna

(*) https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: seteuid problem with sshd

[Bruce Halco]

On 3/14/19 5:47 AM, Corinna Vinschen wrote:
> On Mar 13 22:20, Bruce Halco wrote:
>> I had found nothing referencing "No such file or directory", which sounds
>> rather different from a permissions problem.
>>
>> Running sshd under the Local System account made no difference.
>>
>> passwd -R was no help.
>>
>> What I did discover was that cygwin/sshd apparently now requires the Windows
>> account to be Enabled.  That was not the case previously.
>>
>> The target systems in my application are in restaurant offices, and only use
>> a single Windows login.
>>
>> As the people who use ssh do not need local Windows accounts, I've always
>> used the practice of Disabling those user accounts in Windows. The
>> credentials were available to ssh, without the security issues of all those
>> extra active accounts.
>>
>> Unless someone can suggest an alternative, I'll have to leave all those
>> accounts Enabled. I can put some long, nasty passwords on them to keep the
>> risk acceptable.
> I'm sorry to say that, but there is no alternative.  This has been
> discussed at great length on thlis mailing list, starting at
>
> https://cygwin.com/ml/cygwin/2019-01/msg00197.html
>
> For starters, I added a special check to disable logging in with a
> disabled account.  However, the S4U logon method used by Cygwin now in
> place of the old "Create user token from scratch" method(*) even checks
> that automatically and does not allow disabled accounts to logon.
>
> Same goes for the `passwd -R' method as well as for normal password logon
> since they have been introduced, btw, given they use the same underlying
> WIndows function which actively checks for disabled accounts.
>
> Last but not least, the fact that some logon methods allowed disabled
> accounts to logon and some didn't wasn't really a good idea to begin
> with.
>
>
> Corinna
>
> (*) https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1
>
Thank you for the information.

I will adjust my practices to the new situation.

Bruce


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