Score:0

Remote Desktop Connection not working - not enabled or not available

cn flag

I'm using Ubuntu 18.04

I tried installing xrdp but it didn't work.

I used some methods like

  1. apt-get install xrdp apt-get install xfce4 apt-getecho xfce4-session >~/.xsession

  2. install xrogxrdp

  3. install tightvncserver

  4. install gnome-session

and I tried some more other processes but they didn't work and i have tried enabling the respective port for xrdp xorg.

root@incrcomnetpp:/home/abb# netstat -lntp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      1925/smbd    
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      704/systemd-resolve
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1393/sshd    
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      5725/cupsd   
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      1996/master  
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      1925/smbd    
tcp        0      0 127.0.0.1:8000          0.0.0.0:*               LISTEN      1338/gen4agent-linu
tcp        0      0 127.0.0.1:8009          0.0.0.0:*               LISTEN      1338/gen4agent-linu
tcp6       0      0 :::139                  :::*                    LISTEN      1925/smbd    
tcp6       0      0 :::22                   :::*                    LISTEN      1393/sshd    
tcp6       0      0 ::1:3350                :::*                    LISTEN      1365/xrdp-sesman
tcp6       0      0 ::1:631                 :::*                    LISTEN      5725/cupsd   
tcp6       0      0 ::1:25                  :::*                    LISTEN      1996/master  
tcp6       0      0 :::445                  :::*                    LISTEN      1925/smbd    
tcp6       0      0 :::3390                 :::*                    LISTEN      1399/xrdp    

root@incrcomnetpp:/home/abb# iptables-save | grep 5900
-A ufw-user-input -p tcp -m tcp --dport 5900 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 5900 -j ACCEPT
root@incrcomnetpp:/home/abb# iptables-save | grep 5901
-A ufw-user-input -p tcp -m tcp --dport 5901 -j ACCEPT
-A ufw-user-input -p tcp -m multiport --dports 5901:5910 -j ACCEPT
root@incrcomnetpp:/home/abb# iptables-save | grep 3389
-A ufw-user-input -p tcp -m tcp --dport 3389 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 3389 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 3389 -j ACCEPT

rdp connection refusing

hu flag
It is not clear what exactly did not work. You need to provide details - copy/paste errors, etc.
Score:1
br flag

You can find out if it is application issue or network connection issue. I suggest list of checks. Begin on device which should be managed remotely:

1. Is application TCP port listening?

Install net-tools if not installed: sudo apt-get install net-tools and use netstat for first check:

sudo netstat -lntp

Search for listening port. Application/service name is in last column of command response. Typical TCP ports are: 5900 or 5901... for VNC, 3389 for RDP etc. Port numbers are in third column after colon, eg. 0.0.0.0:5900

If no remote access listening port is opened, it is usually application setting problem or service is not started. Check logs in /var/log/ and service status.

2. Does your firewall allow incomming connection?

sudo iptables-save
sudo iptables-save | grep <a TCP port number>

First command displays details about local firewall. If no output is visible it means firewall is not active. No action is needed. Go to step #3.

In case some lines are listed you can filter them by second command. Replace <a TCP port number> by your real port number (e.g. 5900) from step #1 explained above. If your port is not listed with ACCEPT clause at end of line, you must open the port in firewall. There are more possibilities how to do it, I do not know what kind of firewall management do you use (iptables only, UFW, GUFW...).

3. Is your Ubuntu 18.04 system reachable from another PC via network?

ip address show
ip a

Second command is short version of first one. Use this command on both sides, i.e. in Ubuntu 18.04 (PC-A) and in another PC (PC-B) from which you will try to connect remotely to PC-A. Search for their IP addresses.

Put command in PC-B:

ping <PC-A IP address>

If you see positive ping response (response time in miliseconds) from PC-A, the PC-A is reachable in network. In case none or negative response is displayed you must solve network connection issue.

Put command in PC-B:

telnet <PC-A IP address> <a TCP port number>

where <a TCP port number> is listening port from step #1. If response is "Connected to .." you verified the PC-A is reachable for remote access.

If response is "telnet: Unable to connect to remote host: Connection refused" or no response for a long time, it means some blocking point is between PC-B and PC-A.

If the PC-B operating system is Windows, then telnet is not available by default. You must install it by adding feature to Window system (Control Panel, Uninstall or change a program, Turn Windows features on or off, search for Telnet client, enable it).

4. Do you use correct remote access application and port on PC-B?

It is next possible problem source. Install and try a Remmina application on PC-B. It is useful and universal. It can be used for VNC, RDP, SSH... type of access. Be careful concerning TCP port you use. In case PC-A is listening on 5901, you cannot use default 5900 port in VNC access. Etc.

If the PC-B operating system is Windows, use mstsc command instead of the Remmina.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.