Mail Archives: cygwin/2025/04/22/04:58:01
Hi,
On 8/04/2025 9:14 pm, Corinna Vinschen via Cygwin wrote:
> On Apr 4 16:23, Shaddy Baddah via Cygwin wrote:
>> On 4/04/2025 10:02 am, Shaddy Baddah via Cygwin wrote:
>>> Hi,
>>>
>>> On 4/04/2025 4:49 am, ASSI via Cygwin wrote:
>>>> Shaddy Baddah via Cygwin writes:
>>>>> If I connect an SSH session via the "native" OpenSSH instance
>>>>> integrated into Windows, I can do something like the following to a,
>>>>> at the time, online only, not yet downloaded file, and OneDrive will
>>>>> download it ahead of outputing it:
>>>> […]
>>>>> But if I connect an SSH session via the Cygwin instance running on a
>>>>> different port to 22, it does not trigger the provider to download the
>>>>> file, and I see this error:
>>>> […]
>>>>> The fact that the native SSH session is OK suggests to me that there
>>>>> is some newer type of security token that that service obtains that
>>>>> the Cygwin SSH service does not. But I've not looked into it too hard.
>>>> No, that suggests that you have logged into your SSh session without
>>>> providing a password. Windows will revoke all network access that
>>>> requires authentication for such sessions.
>>> Thanks for the reminder, but it's not that. I definitely logged in. And
>>> amazingly, it's more than 20 years ago I was helped on this list to
>>> understand this nuance, I think with regards to running Oracle's sqlplus
>>> command line. Speculating... it appears registry keys for the sync'ed
>>> portions of the filesystem are usually subkeys under
>>> HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/Explorer/SyncRootManager/
>>> That suggests tie-in with Explorer... which suggests the Shell
>>> extensions are not active somehow? I speak with complete lack of
>>> authority of course. One thing I could maybe do though, is profile the
>>> forked process layout in Process Explorer, maybe look at which DLLs are
>>> in scope for the relevant shell processes. I don't know how much that
>>> would help. -- Regards, Shaddy
>>>
>> Apologies for the formatting error.
>>
>> Thanks for the reminder, but it's not that. I defintiely logged
>> in. And amazingly, it's more than 20 years ago I was helped on this
>> list to understand this nuance, I think with regards to running
>> Oracle's sqlplus command line.
>>
>> Speculating... it appears registry keys for the sync'ed portions of
>> the filesystem are usually subkeys under
>> HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/Explorer/SyncRootManager/
>> That suggests tie-in with Explorer... which suggests the Shell
>> extensions are not active somehow? I speak with complete lack of
>> authority of course.
> I checked the Windows OpenSSH code and I don't see any relevant
> difference between the way MSFT OpenSSH uses LsaLogonUser and the way
> Cygwin does it. If it's using something with Shell Extensions, we're
> probably out.
>
> What you still can do is using password auth the good old Interix way:
> https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd3
Thanks. I took up the suggestion (I think), but I still get different
behaviour.
I think I should clarify a couple of things. When I said "I definitely
logged in.", I meant logged in with a password. As I mentioned, it was
your good self who helped me those 20-odd years ago to get past the
sqlplus issue. So I always try that ahead of key authentication.
Also, I should point out that, "native" SSH works even if the logged
in user isn't also logged in via console/RDP session. ie. you can SSH
to the newly restarted host, try to dump the contents of the
online-only text file, and it will be downloaded, presumably by a
forked instance of the One Drive executable.
Works for both One Drive, and surprisingly, for Nextcloud.
With regards to the old Interix way... I realised that I am quite out
of date. I recall, I think in the Vista days, forcing LSA on to
overcome some issue... turning it on for any other installation I
made, and then encountering some years ago, cyglsa-config
disappearing... noting it didn't seem to matter to my original issue,
and just not bothering anymore.
If I am in the right ballpark, is the suggestion to just cygserver on
it's own? If that is the case, I did configure one using
cygserver-config, restarted, logged in to check it was running (tick)
and attempting the same above scenario (cat an online-only text
file).
I still see permission denied. I think at this stage, this is just an
FYI, unless I've missed the point on cygserver. Because if cygserver
can't solve this, I suspect some MS special magic here.
Small diversion, it should be noted that cygserver-config is
effectively broken. It looks like (from an old cygcheck.old of mine),
the service used to be installed under the name cyg_server. The
(overridable) default is now just cygserver.
Well the script appears to now have some oversight in how it checks for
an existing cygserver "service" process in this code:
# Check for running cygserver processes first.
if ps -ef | grep -v grep | grep -q ${service_name}
then
echo
echo "There is a cygserver (${service_name}) already running. Nothing to do, apparently."
echo
exit 1
fi
Obviously it's trying to filter out it's own grep process and
expecting that no other process is listed to proceed. But the script
matches ${service_name} by name... which used to be fine, because it
wasn't an exact match (as cyg_server).
To overcome, I just copied the script and commented it out, because
I want to retain the default name... and I don't remember how I have
performed exact matches in the past to suggest the patch.
--
Regards,
Shaddy
--
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 -