micahmo
commented
10 months ago Hi @Warudo, thanks for the post! Let's take a look at each of your issues!
when creating a server for accepting a reverse tunnel, the files C:\ProgramData\ssh\ssh_rdp_over_ssh_key, C:\ProgramData\ssh\ssh_rdp_over_ssh_key.pub and C:\ProgramData\ssh\administrators_authorized_keys are all created as existing but empty 0KB files. If I try to use the "Show SSH Server Key" GUI function, an empty window is shown.
That is very strange! I just downloaded and installed RDPoverSSH on a clean system. Then I simply clicked the arrow to make the tunnel incoming (for accepting a reverse tunnel) -- I didn't even fill out any of the details -- and all of these files were successfully created for me, and I could use the "Show SSH Server Key" function.
If this step is not working for you, perhaps you could check in Event Viewer > Windows Logs > Application. When the files are successfully created, there are log entries like the following. Otherwise, errors should be logged.
Created keys file 'C:\ProgramData\ssh\administrators_authorized_keys', and set secure ACLs. Added public key to authorized keys.
Also, the permissions for the file C:\ProgramData\ssh\administrators_authorized_keys are too permissive. I needed to run
icacls.exe "C:\ProgramData\ssh\administrators_authorized_keys" /inheritance:r /grant "Administrators:F" /grant "SYSTEM:F"on it (see this documentation).
I also have not had this issue. RDPoverSSH is supposed to set permissions just like that. See this block of code.
Again, if this didn't work for you, then it may go along with the above issue that these these files are just not getting initialized properly, and I would again consult Event Viewer for any issues!
Also, key files for the Windows native SSH client need a line feed at the end, which might not get copy&pasted (see here).
Thanks! When using the "Show SSH Server Key" and the "Copy" button, the newline is preserved in the copy buffer. Of course, what the user does with that data is another question. :blush: Also just a nitpick, RDPoverSSH does not use the native Windows SSH client. But the same is probably true about the trailing newline.
My current suspicion is that RDPoverSSH uses the wrong username
This is unlikely to be a problem, unless there was an error during RDPoverSSH's initialization. It actually creates a hidden user called RDPoverSSH on both the server and client system. That way, it can guarantee that the user always exists, so there's no need to specify it in the UI, and there's no issue of being mismatched between client and server.
You can check for the user on the server. It should not appear in the Control Panel (e.g., Control Panel\User Accounts\User Accounts\Manage Accounts), but it should appear in the registry under Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList.
If it's not there, then something went wrong! You can also try manually connecting with that user, like ssh -i C:\ProgramData\ssh\ssh_rdp_over_ssh_1_key -p [Same port as in GUI] rdpoverssh@[Same host as in GUI].
I hope that helps a bit, and I hope we can figure out what's going on to get this working for you! :blush:
Hi,
when creating a server for accepting a reverse tunnel, the files C:\ProgramData\ssh\ssh_rdp_over_ssh_key, C:\ProgramData\ssh\ssh_rdp_over_ssh_key.pub and C:\ProgramData\ssh\administrators_authorized_keys are all created as existing but empty 0KB files. If I try to use the "Show SSH Server Key" GUI function, an empty window is shown.
Also, the permissions for the file C:\ProgramData\ssh\administrators_authorized_keys are too permissive. I needed to run
icacls.exe "C:\ProgramData\ssh\administrators_authorized_keys" /inheritance:r /grant "Administrators:F" /grant "SYSTEM:F"on it (see this documentation).Same problem on the client that initiates the tunnel: The permissions of the file C:\ProgramData\ssh\ssh_rdp_over_ssh_1_key are too permissive. Also, key files for the Windows native SSH client need a line feed at the end, which might not get copy&pasted (see here).
Despite manually fixing all of this, I'm still stuck at "Permission denied (publickey)." on the client side. I can connect manually. I have verified that the command
ssh -i C:\ProgramData\ssh\ssh_rdp_over_ssh_1_key -p [Same port as in GUI] [Windows Username on server]@[Same host as in GUI]works without a password prompt. My current suspicion is that RDPoverSSH uses the wrong username, because that's the only part I can't set in the GUI. The Windows username of the user running RDPoverSSH is different on both systems. When using ssh without the "[Username of server]@" part, the connection fails because it ssh tries to use the current logged in user as the default. Since I have never told RDPoverSSH the username used on the system that accepts the tunnel, it can't know the correct one.