On 2018-05-23 13:44, Stefan Baur wrote:
> I am the community manager of X2Go, an open-source remote desktop and
> remote application solution for Linux servers. While our server
> component only runs on Linux, our client software is available for macOS
> and Windows as well. The Windows version of X2GoClient relies on some
> executables available through Cygwin.
> On Windows 10, we are encountering the issue mentioned here in the FAQ:
> <https://cygwin.com/faq/faq.html#faq.using.ssh-pubkey-stops-working>
> Especially, we're getting hit by the fact that Microsoft has changed the
> default group for %USERPROFILE% (and all files and directories created
> in it) from "None" to <Username>.
> This is why the second-to-last suggestion in that FAQ item doesn't help:
> chgrp `id -g` ~/.ssh/*
> will simply set the default group to the value it already has, and that
> doesn't fix the issue.
> The last suggestion in that FAQ item suggests using
> chgrp None ~/.ssh/*
> but also notes that the group name will vary depending on the operating
> system language.
> chgrp does work with numeric group identifiers, and it seems the "None"
> group always gets the numeric id 197121 - so
> chgrp 197121 ~/.ssh/*
> would fix the issue regardless of the operating system language.
> (In our case, it would be
> chgrp 197121 %USERPROFILE%/.x2go/etc/ssh_host_key*
> because it actually affects the host keys of an sshd running on the
> Windows side, which we need for file sharing via sshfs, but you get the
> idea.)
> Can anyone with authority on the issue confirm that 197121 always
> corresponds to the "None" group (whatever it may be called due to the
> language setting - in German, it is "Kein", for example)?
> Or is this a faulty assumption and merely coincidence that we got that
> result on the handful of machines we used for testing?
> I'm seriously hoping this id is always the same, similar to the
> well-known SIDs in Windows, but would really like a confirmation from
> someone knowledgeable before we make the corresponding change in our
> code and hose a large percentage of our users' systems once they deploy
> the update.
> In case it is of relevance, we are calling the executables (ssh-keygen,
> sshd, and now chgrp and possibly setfacl as well) directly from a native
> Windows application written in Qt and C++, not from a Cygwin bash window
> or similar. In fact, there is no cygwin installation, it's just the
> required executables and dlls residing in our own installation
> directory. I can provide more detail or get you in contact with one of
> our developers, if needed.
Cygwin id 197121 == RID 513 == 0x201 - in range of reserved RIDs < 1000.
See:
https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-how
https://msdn.microsoft.com/en-us/library/aa379649.aspx
https://en.wikipedia.org/wiki/Security_Identifier
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
--
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
