Add a switch to get around private key permission check on network share.

[mijioij]

Summary of the new feature / enhancement

I need to use private key that is stored on a sambashare, but win32-openssh won't use it because it is owned by the samba user and not the user running the command. Relevant output of ssh -vvvT -i J:.ssh\ed25519 [email protected]:
debug3: Bad owner on J:/.ssh/ed25519
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions for 'J:\.ssh\ed25519' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "J:\.ssh\ed25519": bad permissions

It looks like this lines 96 -99 here https://github.com/PowerShell/openssh-portable/blob/bdacf9868fe9e8024a5312861b7aaa6faba1821f/contrib/win32/win32compat/w32-sshfileperm.c#L96 have to do with this and it's intended to make sure only the user running the command has access to the private key.

The problem is, short of making a samba ad server and logging into the domain on the client (I don't know if there are any gotchas in the process that would still prevent the private key working), makes using private key on at least a samba share impossible. Even if the samba ad server solution works, it's still a large hassle for a largely artificial restriction.

I request a switch to allow insecure private key on network share. This request is probably out of scope for this project given this is intended behavior and upstream has made clear of this. But to be fair on Linux I could get around this by simply creating the user locally and using sudo/doas. I can't do this on Windows.

Interesting thing is if in WSL I do sudo mount -t drvfs J: /mnt/test and do ssh -vvvT -i J:.ssh\ed25519 [email protected] on the mount, the command is able to work flawlessly even though the actual folder is owned by a completely different user and permissions show as rwxrwxrwx. Unfortunately, I can't use a workaround using the drvfs mount because I need to account for symbolic link creation being accessible on the Windows host and vice versa which drvfs seems to have limitations with at the moment.

Proposed technical implementation details (optional)

No response

[jborean93]

The check is part of the upstream openssh-portable repo and is just slightly modified to work on the ACLs rather than mode bits you see on *nix hosts. I can't speak for the team who maintain this fork but as the upstream openssh does't allow you to ignore this check I think it would be unlikely for such an option to also be implemented here.

Instead what you can do is to copy the file locally when you need to use it. You could also look at building your own ssh-agent implementation but that's quite complicated and involved. You could also look at adding it to the ssh-agent with something like Get-Content $keypath | ssh-add.exe but I'm unsure if ssh-add on Windows supports reading a key from stdin. Keep in mind if you add a key to ssh-agent it will stay there even beyond reboots so you might want to remove the key after you've used it.

[mijioij]

@jborean93 copying the file locally, even temporarily, is what I'm trying to avoid but looks like immediate short-term solution.

UPDATE: Get-Content $keypath | ssh-add.exe needed - added to the end (like Get-Content $keypath | ssh-add.exe -) to work.

[mgkuhn]

short of making a samba ad server and logging into the domain on the client (I don't know if there are any gotchas in the process that would still prevent the private key working)

If the client is logged into the domain, you should have there obtained a Kerberos ticket, and thus can use Kerberos (GSSAPI) authentication instead of public-key authentication, so the entire problem disappears, as no secret key is needed any more.