Can't SSH tunnel over Remmina (RDP) #756

Closed
mgruben opened this Issue Feb 2, 2016 · 21 comments

Projects

None yet

3 participants

@mgruben
mgruben commented Feb 2, 2016

Hey there,

Am able to ssh -L 9001:localhost:8444 tunnel@host -p 22 then connect in remmina to localhost:9001.

Am now unable to configure remmina to connect directly to host, even though I used to be able to (earlier version unknown?) with the following options:
Server host:8444
Enable SSH tunnel
Tunnel via loopback address
Same server at port 22
SSH Authentication -- User name tunnel
Public key (automatic)

within the terminal which launched remmina, I receive:

[20:31:27:129] [25235:25506] [ERROR][com.freerdp.core.nego] - Protocol Security Negotiation Failure
[20:31:27:129] [25235:25506] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_SECURITY_NEGO_CONNECT_FAILED [0x2000C]
[20:31:27:129] [25235:25506] [ERROR][com.freerdp.core.connection] - Error: protocol security negotiation or connection failure

within remmina's debug window, level SSH_LOG_FUNCTIONS, I receive:

[SSH] ssh_packet_process: Dispatching handler for packet type 52
[SSH] ssh_packet_userauth_success: Authentication successful
[SSH] ssh_packet_userauth_success: Received SSH_USERAUTH_SUCCESS
[SSH] ssh_userauth_publickey_auto: Successfully authenticated using /home/clientuser/.ssh/id_rsa

Running Arch Linux 4.3.3-3, remmina 1:1.2.0rcgit.8-1, and freerdp 1:1.2.0_20160107-2

edit: forgot how to uname
edit2: corrected log code display

@antenore
Member
antenore commented Feb 3, 2016

Can you please try with xfreerdp from the command line? Just to see if it's a Remmina or a FreeRDP, because the SSH logs looks good to me!

@mgruben
mgruben commented Feb 4, 2016

Am successfully able tossh -L 9001:localhost:8444 tunnel@host -p 22
then xfreerdp /u:person@domain /v:localhost:9001

Does xfreerdp have built-in ssh tunneling functionality? If so, I'm happy to test that too.

@mgruben
mgruben commented Feb 4, 2016

More information about my setup:
host has an open ssh tunnel through another host (otherhost), which itself forwards to a third host (finalhost)

This is initiated from otherhost via the following command:
autossh -M 0 -R 8444:finalhost.domain:3389 tunnel@host.global.ip.address -p 443 -N -o ServerAliveInterval=600 which is itself a systemd service and timer pair as follows:

The service:

Description=Keeps a tunnel to 'finalhost.domain' open
After=network.target

[Service]
User=someuser
#Group=someuser
# -p [PORT]
# -l [user]
# -M 0 --> no monitoring
# -N Just open the connection and do nothing (not interactive)
# LOCALPORT:IP_ON_EXAMPLE_COM:PORT_ON_EXAMPLE_COM

#Be sure not to use the -f tag!

ExecStart=/usr/lib/autossh/autossh -M 0 -R 8444:finalhost.domain:3389 tunnel@host.global.ip.address -p 443 -N -o ServerAliveInterval=600

[Install]
WantedBy=multi-user.target

The timer:

Description=Run autosshservice 60 seconds after boot

[Timer]
OnBootSec=60

[Install]
WantedBy=timers.target
@antenore
Member
antenore commented Feb 4, 2016

The ssh tunnel part is quite broken, I'll work on it in the future.
In the meanwhile what about using the "Pre and Post command" option? You can provide the full path of a script (don't add any arguments) that will be execute just before and after the RDP connection.

@antenore antenore added bug SSH labels Feb 4, 2016
@mgruben
mgruben commented Feb 4, 2016

I've saved in /home/client/ the following precommand.sh (chmod +x as well):

ssh -L 9001:localhost:8444 tunnel@host -p 22

Executing ./precommand.sh successfully opens the desired tunnel in xterm.
In remmina, I placed under "Pre Command" /home/client/precommand.sh.
Upon clicking connect, I see Please Wait for at most a few seconds, then "Unable to connect to RDP server localhost".

edit: path clarity

@antenore
Member
antenore commented Feb 4, 2016

I've tested on my PC, but I don't have the same setup as your.

I've created a bash script with inside

 ssh -f -L 3389:myrdpserver.ch:3389 127.0.0.1 -N

Left is the local port and I used the standard RDP port
On the right the server RDP port, for me it's the standard one, again 3389.
127.0.0.1 is my local IP address, becuase I don't have an SSH server that can connect to the RDP server :-(

In remmina I've created a new profile.

Server: 127.0.0.1
User name. myusername
Domain: myrdpdomain
SSH Tunnel: Disabled

Unlucky I cannot test a setup like your at the moment.

@giox069
Contributor
giox069 commented Feb 4, 2016

@mgruben: just to clean up things and ensure that is not one of the freerdp certificate problems:

cd ~/.config/freerdp

If you find a file named known_hosts here, delete it. You can keep known_hosts2 as is, if you need it. But deleting also known_hosts2 will be a good idea.

@antenore
Member
antenore commented Feb 4, 2016

I always forget about this 👍

@antenore
Member
antenore commented Feb 5, 2016

I found the origin of the problem

remmina/src/remmina_ssh.c:762:          if (ssh_channel_open_forward (channel, tunnel->dest, tunnel->port, "127.0.0.1", 0) != SSH_OK)

Beside that the local host/port are hardcoded, 0 it's not a good port to use at all!!!!

I'm investigating further to fix it, because we should not have it hard-coded at all.
Stay tuned.

@mgruben
mgruben commented Feb 5, 2016

@giox069: I executed the following:

cd .config/freerdp/
mkdir unnecessary
mv known_hosts* unnecessary/

After which I started remmina but failed to connect to host:8444 using the ssh tunnel settings mentioned above

[x] Enable SSH tunnel
[x] Tunnel via loopback address
(o) Same server at port 22
User name: tunnel
(o) Public key (automatic)

Edit: Unfortunately, now neither does connecting to localhost:9001 with a manual ssh tunnel work, even after cd ~/.config/freerdp/unnecessary && mv known* ../
xfreerdp reports

[20:35:59:528] [1288:1289] [ERROR][com.freerdp.core.nego] - Protocol Security Negotiation Failure
[20:35:59:533] [1288:1289] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_SECURITY_NEGO_CONNECT_FAILED [0x2000C]
[20:35:59:533] [1288:1289] [ERROR][com.freerdp.core.connection] - Error: protocol security negotiation or connection failure
[20:35:59:533] [1288:1289] [ERROR][com.freerdp.client.x11] - Freerdp connect error exit status 1

and the ssh tunnel reports channel 3: open failed: connect failed: Connection refused
ssh -vvv tunnel reports:

tunnel@host:~$ debug1: Connection to port 9001 forwarding to localhost port 8444 requested.
debug2: fd 9 setting TCP_NODELAY
debug2: fd 9 setting O_NONBLOCK
debug3: fd 9 is O_NONBLOCK
debug1: channel 3: new [direct-tcpip]
channel 3: open failed: connect failed: Connection refused
debug2: channel 3: zombie
debug2: channel 3: garbage collecting
debug1: channel 3: free: direct-tcpip: listening port 9001 for localhost port 8444, connect from 127.0.0.1 port 56740 to 127.0.0.1 port 9001, nchannels 4
debug3: channel 3: status: The following connections are open:
  #2 client-session (t4 r0 i0/0 o0/0 fd 6/7 cc -1)

edit2: This could well mean that something is amiss at finalhost's home, but also otherhost lives there and has been keeping the remote ssh tunnels to host alive. Maybe finalhost changed domains / computer names without telling me today
edit3:(also see below comment), something was amiss with otherhost's configuration

@mgruben
mgruben commented Feb 5, 2016

Update:
The service I quoted above was improperly configured. I changed relevant portions quoted below
ExecStart=/usr/lib/autossh/autossh -M 0 -R 8444:finalhost:3389 tunnel@host.global.ip.address -p 443 -N -o ServerAliveInterval=600

It's curious, but neither the subject of this bug request, nor has the behavior persisted, that I was ever able to use the service above to correctly connect. I was previously using, to be more specific, finalhost.domain.com, when in fact the host is not located at domain.com, it's just a member of domain. Also, removing domain entirely still allows a proper connection.

However, this breakthrough is just for manual ssh tunnels. remmina-initiated ssh tunnels still appear to be broken.

Happy to provide any additional information or logs as needed.

@antenore
Member
antenore commented Feb 5, 2016

Thanks for these additional infos.

As soon as I'll have some time, I'll work on this.
It won't be quick because it's awfully intricate.

Just confirm me if you can work or not (somehow).

@mgruben
mgruben commented Feb 5, 2016

I definitely have a working connection method.

Edit (and see below): At this time this was written, that working connection method used remmina, from within finalhost's domain (but accessing finalhost through a tunnel opened by otherhost to host). That is, the client machine and finalhost were on the same network, in the same room, but client machine localssh'd to host via its external ip address, which has an existing tunnel established by otherhost to forward host's 8444 to finalhost's 3389.

After I returned to host's home, remmina ceased to work for finalhost, and instead would only work for finalhostxp.

@mgruben
mgruben commented Feb 5, 2016

Edit: I was able to resolve the problem outlined in the comment below:
I changed Advanced>Security to "RDP" rather than "Negotiate." Unfortunately, the remmina ssh-tunnel connection was already set to "RDP," so that's not a fix to enable remmina-native ssh tunneling

This may be a separate issue, and I'm happy to split it off and start a new issue, but finalhost is not accepting my localhost:9001 connections

Authentication to RDP server localhost failed.
Check username, password and domain.

This occurs whether or not I check the "Ignore certificate" option
However, I am able to xfreerdp /u:person /d:domain /v:localhost:9001 to finalhost just fine

Edit: finalhost is a Windows 7 Professional machine.
finalhostxp is Windows XP Professional machine, just now introduced in the discussion. I am able to successfully remmina to finalhostxp without receiving the authentication error above, and of course am able to xfreerdp to finalhostxp without issue.

@giox069
Contributor
giox069 commented Feb 6, 2016

@mburgen: I have just started to try to understand what's happening. But I stopped at the 3rd post. You said that you already have an autossh tunnel setup, which exposes the remote RDP server port on localhost:8444.
So your port localhost:8444 accepts pure RDP connections, no need to ask for a second ssh tunnel. Why don't you just disable SSH tunnel on remmina and tell remmina to connect to localhost:8444 ?

@mgruben
mgruben commented Feb 6, 2016

@giox069: different localhosts (or, alternatively, GatewayPorts no);
(1) otherhost executes the following command autossh -M 0 -R 8444:finalhost:3389 tunnel@host.global.ip.address -p 443 -N -o ServerAliveInterval=600, thus connecting host:8444 (as localhost:8444) to finalhost:3389.
(2) Notably, host has GatewayPorts no in sshd_config to limit access to known tunnelers (and further has specified PermitOpen localhost:8444 to prevent even a known a tunneler from volleying anything other than finalhost:3389, otherwise a rogue tunneler with unrestricted access could effect great mischief).
(3) Also, I don't actually do user-space work on host, but rather on client.
(4) As such, client must ssh tunnel to host:8444.
(5) To do this, client executes the following command ssh -L 9001:localhost:8444 tunnel@host, thus (gloriously) connecting client:9001 (as localhost:9001) to finalhost:3389.

In hindsight, I might well have named otherhost as middleman, firewall-breaker, or Rapunzel, as it was because of restrictive firewalling around finalhost that I require an in-firewall-initiated ssh tunnel (indeed, the firewall even prevents outgoing port 22 connections, thus the -p 443 in the autossh command), and have named host as man-on-the-outside or DameGothel, as the ssh tunnel from the inside must point to a dedicated rig on the outside.

@giox069
Contributor
giox069 commented Feb 6, 2016

I'm a bit closer to understand (there are 4 hosts involved here: client-->host-->otherhost-->server) and I think there is a couple of firewalls between host and otherhost. Right ?
Client must connect to host via ssh, because host has GatewayPorts no, right ?
Have you tried also to remove (uncheck) the option "Tunnel via loopback address" in the SSH settings ?

@mgruben
mgruben commented Feb 6, 2016

That's correct, client-->host-->otherhost-->finalhost
finalhost and otherhost are both behind the same firewall, and client and host are both behind the same firewall (over which I have control, and so can open ports at will).
Indeed, client cannot simply xfreerdp /v:host:8444 because of GatewayPorts no

Unchecking "Tunnel via loopback address" did not have any impact, as indicated by logs below:
within the terminal which launched remmina, I receive:

[15:54:06:892] [30880:30930] [ERROR][com.freerdp.core.nego] - Protocol Security Negotiation Failure
[15:54:06:893] [30880:30930] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_SECURITY_NEGO_CONNECT_FAILED [0x2000C]
[15:54:06:893] [30880:30930] [ERROR][com.freerdp.core.connection] - Error: protocol security negotiation or connection failure

within remmina's debug window, level SSH_LOG_FUNCTIONS, I receive:

[SSH] ssh_packet_process: Dispatching handler for packet type 52
[SSH] ssh_packet_userauth_success: Authentication successful
[SSH] ssh_packet_userauth_success: Received SSH_USERAUTH_SUCCESS
[SSH] ssh_userauth_publickey_auto: Successfully authenticated using /home/clientuser/.ssh/id_rsa

The remmina dialog window stated Unable to connect to RDP server 127.0.0.1

edit: When I posted the above logs, I had "Security" set to "Negotiate." Setting the security to "RDP," oddly, produced the same Protocol Security Negotiation Failure, reproduced below:

[16:01:37:957] [30880:31311] [ERROR][com.freerdp.core.nego] - Protocol Security Negotiation Failure
[16:01:37:957] [30880:31311] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_SECURITY_NEGO_CONNECT_FAILED [0x2000C]
[16:01:37:957] [30880:31311] [ERROR][com.freerdp.core.connection] - Error: protocol security negotiation or connection failure
@giox069
Contributor
giox069 commented Feb 6, 2016

In SSH tunnel settings, don't use "Same server at port 22", but "Custom", and on "Custom" field type the address of "host" (port 22 will be used to ssh to "host"). Unckeck "Tunnel via loopback address".

Then on the "Basic" tab put localhost:8444 as "Server" field.

It's just a test... maybe I'm totally wrong. If it will fail, I will setup a similar setup to reproduce it in the next days.

@mgruben
mgruben commented Feb 7, 2016

@giox069 HA
That fixed it.
That was definitely not how I had it set up before, but excellent to have it working again.
.remmina file below for posterity

[remmina]
sound=off
sharefolder=
name=finalhost test
cert_ignore=0
console=0
ssh_enabled=1
exec=
clientname=
server=localhost:8444
colordepth=0
keyboard_grab=1
loadbalanceinfo=
ssh_auth=3
group=
sharesmartcard=0
quality=0
username=
ssh_charset=
ssh_loopback=0
password=
ssh_username=tunnel
gateway_server=
disablepasswordstoring=0
window_maximize=1
execpath=
gateway_usage=0
viewmode=4
resolution=
security=rdp
domain=
precommand=
ssh_server=host
shareprinter=0
protocol=RDP
disableclipboard=0
ssh_privatekey=/home/clientuser/.ssh/id_rsa.pub
@mgruben mgruben closed this Feb 7, 2016
@giox069 giox069 removed the bug label Feb 7, 2016
@giox069
Contributor
giox069 commented Feb 7, 2016

👍 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment