Win32-OpenSSH
Win32-OpenSSH copied to clipboard
UserKnownHostsFile parameter problems specifying paths with W
Only this weird construct works: ssh -v -o'UserKnownHostsFile="""C:\Program Files\whitespace test\known_hosts"""' -i 'C:\Program Files\whitespace test\id_ecdsa' user@ip
Nothing else worked for me so far when specifying a path with whitespaces via PowerShell. The -i parameter on the other side is capable of processing paths with a whitespace.
More badly, when executing the above command that works in PowerShell within a PowerShell module, we get: command-line: line 0: Bad configuration option: 'userknownhostsfile
So executing an SSH command that contains a user known hosts path with whitespace within a PS module does not work at all.
Observed on: Windows PowerShell 5.1 (Build 19041, Revision 906) Windows 10 Enterprise OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5 (FileVersion: 7.7.2.1)
I can confirm this issue, seams that Issue 1211 ist not fixed.
debug1: load_hostkeys: fopen C:\\Program: No such file or directory
debug1: load_hostkeys: fopen Files\\whitespace: No such file or directory
debug1: load_hostkeys: fopen test\\known_hosts: No such file or directory
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts2: No such file or directory
debug1: hostkeys_find_by_key_hostfile: hostkeys file C:\\Program does not exist
debug1: hostkeys_find_by_key_hostfile: hostkeys file Files\\whitespace does not exist
debug1: hostkeys_find_by_key_hostfile: hostkeys file test\\known_hosts does not exist
debug1: hostkeys_find_by_key_hostfile: hostkeys file __PROGRAMDATA__\\ssh/ssh_known_hosts does not exist
debug1: hostkeys_find_by_key_hostfile: hostkeys file __PROGRAMDATA__\\ssh/ssh_known_hosts2 does not exist
This does appear to still be broken -- affected the Steam Deck devkit utility on windows:
https://steamcommunity.com/groups/steamworks/discussions/27/3731827313770208491/
(we now ship a workaround that double-quotes everything)
This is also an issue on non-Windows machines as well.
For example, have a symlink target of $HOME/.ssh
that points to $HOME/some other/path/.ssh
and the error will occur. Of course you can disable strict host checking, but that's not a solution at all.
This is inherent to SSH itself. The only reason I'm posting here is because it does not seem to be mentioned anywhere in the Linux or Unix worlds.
The problem seems related to how fopen
reads paths with spaces in them: https://stackoverflow.com/questions/43970463/file-name-contains-spaces-cant-open-with-fopen
This issue was infuriating; I'm glad to see it's an open bug and not me going insane. It also impacts scp
.
Also, from the referenced issue, it's a problem from scanf
. Anyway, this triple-" workaround is perfectly fine once you know about it. Which is probably why there is no pressure to fix the issue.