I’m having a heck of a time getting RDP support to work on some SLES 11 SP2 servers. I have one in my lab that works if I RDP into it using CoRD from my Mac and login as root, but not Microsoft’s RDP client. I have another that I cannot RDP into at all no matter what I put in for a user and password. In all cases, when it fails, I get a box that says:
connecting to sesman ip 127.0.0.1 port 3350
sesman connect ok
sending login into to sesman
login failed
What trick am I missing here? What does this mean exactly and how do I troubleshoot it? I’m finding little info on this. Thanks.
What trick am I missing here? What does this mean exactly and how do
I troubleshoot it? I’m finding little info on this. Thanks.[/color]
Microsoft’s (Windows) RDP client uses port 3389 by default. Are you
sure you’re using the correct port(s) at each end?
Is there a reason why you’re using RDP? I use VNC to access my SLES
servers and it works quite well. I use it with SSH (PuTTY) to get a
secure connection. Have you tried that?
–
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
No, it’s not a port problem. I discovered more info. What I’m trying to do is tunnel it over ssh. That seems to be the problem. If I hit it directly with an RDP client, I can get it to work. But when I tunnel it, I get the login but then the sesman error and I’ll see this in the xrdp-sesman.log:
[20130305-23:12:11] [INFO ] granted TS access to user mweisberg
[20130305-23:12:11] [INFO ] starting X11rdp session…
[20130305-23:12:11] [CORE ] error X server died - user mweisberg - pid 5654
So it seems to have something to do with tunneling it over SSH.
What I’m trying to do is provide an easy way for customers to establish remote GUI sessions (especially for users new to Linux that say moved their GroupWise system there). I typically use NoMachine myself, but that requires installing software and a separate client. VNC is ok, but it is weak over slow/latent links and is overall kinda klunky with some GUI apps. RDP works nicely and the client is already there on every Windows machine. So it’s a great easy fit. I just want to be able to tunnel it over ssh if all I have is the ability to ssh to a host.
I just want to be able to
tunnel it over ssh if all I have is the ability to ssh to a host.[/color]
I do see your problem: RDP on Windows; SSH on SLES.
What are you using for SSH on Windows? PuTTY?
Another option is to install Xming on the Windows workstation and use
X11 over PuTTY but that is kind of iffy over slow links.
I once tried RDP over SSH (PuTTY) but didn’t have much luck. I didn’t
spend any time trying to figure out why it wouldn’t work.
RDP does encrypt it’s sessions and for remote access to some of my
systems where I do not use a VPN, I use an obscure high port number and
at the remote sight map that high port to 3389. It seems to work well.
Yet another option is to install the free (open source) ShrewSoft ipsec
VPN client on your Windows workstations and establish a VPN connection
to the remote site. RDP works well over a VPN.
But I digress…
If your only option is to make this work, I would suggest using
WireShark and capture packets at the Windows workstation and the SLES
server to try and understand what is happening. You have to know where
the problem lies before trying to correct it.
–
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
Yeah, doing remote X11 using Xming works, but it is way too slow over the Internet. Plus, Xming is technically not free anymore so the customer would have to buy it.
Frankly, NoMachine is still my favorite. It’s fast and works well (although I’m having trouble with it at this customer where I’m trying to tunnel RDP, the session comes up, but mouse and keyboard input don’t work).
And yes, using putty (actually I was using SecureCRT, but same idea) to create the SSH connection and port-foward on 3389. That’s exactly what I was trying to do.
So yes, there are tons of alternatives, but I’m at the point of wanting to know why I cannot tunnel the XRDP traffic! I may never use it, but I want to know now why it doesn’t work as I think it should.
I guess I’ll grab those traces and try and figure it out. Thanks.
I guess I’ll grab those traces and try and figure it out.[/color]
Let us know what you learn. You’ve made me curious.
–
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
The only problem is, it’s all encrypted SSH traffic, so I’m not sure how I’ll be able to see anything.
Matt
[QUOTE=KBOYLE;12287]matt wrote:
[color=blue]
I guess I’ll grab those traces and try and figure it out.[/color]
Let us know what you learn. You’ve made me curious.
–
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…[/QUOTE]
And insert into there ${client:+client=$client,}
as one of the parms in that large list
and see if that doesn’t fix up your NX problem
On 03/06/2013 01:34 PM, matt wrote:[color=blue]
Yeah, doing remote X11 using Xming works, but it is way too slow over
the Internet. Plus, Xming is technically not free anymore so the
customer would have to buy it.
Frankly, NoMachine is still my favorite. It’s fast and works well
(although I’m having trouble with it at this customer where I’m trying
to tunnel RDP, the session comes up, but mouse and keyboard input don’t
work).
And yes, using putty (actually I was using SecureCRT, but same idea) to
create the SSH connection and port-foward on 3389. That’s exactly what
I was trying to do.
So yes, there are tons of alternatives, but I’m at the point of wanting
to know why I cannot tunnel the XRDP traffic! I may never use it, but I
want to know now why it doesn’t work as I think it should.
I guess I’ll grab those traces and try and figure it out. Thanks.
The only problem is, it’s all encrypted SSH traffic, so I’m not sure how
I’ll be able to see anything.
[/color]
Wireshark does have the ability to decrypt a traffic stream if you can
give it the applicable certificate.
Wireshark does have the ability to decrypt a traffic stream if you
can give it the applicable certificate.[/color]
I thought it had that capability. I was going to look for a reference
but got sidetracked. Glad you were able to jump in.
–
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
I was going to look for a reference
but got sidetracked. Glad you were able to jump in.
[/color]
The fun of tag teaming it
I’ve only needed the process once so far, but it is certainly a useful
capability.
