Hi List, 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. Kind Regards, Stefan Baur -- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243 -- 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
