Remote Access to SUSE

From openSUSE

Introduction

Purpose

This paper is designed to help you setup the remote access solution that best fits your needs

Like many people, you are reading this page looking for help on connecting to your SUSE Linux box via the network.

There are many ways to do this.

You may have a specific need which you (and I) hope this paper will help implement a solution for. Or you may not know enough about the available solutions to decide what best fits your needs.

Therefore this paper must start with a discussion on the diferent types of remote access methods. As a reader you are expected to choose the method that most closely meets your needs. Then you can go to the implementation section to see how to set it up!

Please read the security section to evaluate your security needs. Allowing remote access to a machine is literally inviting people to connect to your machine via the network. Security is the only way to keep the thieves out.

Okay, let's get started...

What is meant by Remote Access

By Remote access we really mean "Running programs on your SUSE Linux box while you sit in front of another machine".

Now "Running programs on your SUSE box" could be done in a shell, or may require a full GUI environment. "while you sit in front of another machine" implies that you already have a running network, correctly setup, with TCP/IP communication between the 2 machines working.

That is a prerequisite. This paper will not help you set up your network or cover the requirements of opening ports in the firewall or port forwarding.

Different Remote Access Requirements

So you got at least 2 computers. One of them is a SUSE Linux (we'll call it "Server"). And from the other "client" computer you want to run programs on "Server".

Well let's start by listing the possible ways:

Maybe all you need is a "Remote Shell" on "Server". That is easy. But sometimes a shell is not enough. You may need to run a GUI (X-Windows) program remotely. There are several ways to do this. Each method fullfills different needs. Each method has it's advantages and disadvanteges. But in general the methods to execute GUI programs fall into the following categories:

- Running Individual GUI Programs from a remote shell. (ssh -X) This method is secure. This method is simple to use

- X-Windows Remote, where (on "client") you log into a remote machine ("Server"), instead of logging into your local machine. This method uses your local X-Windows system (on "Client") as display. As this method is not secure, it should only be used as a last resort.

- Terminal Services, where many people start virtual displays on "Server". Each "Virtual Display" works independantly, but any number of them can run simultaneously on "Server". This is similar to the Windows Terminal Service (hence the name). Here we don't need a local x-windows on "client".

- Desktop Sharing is where you can remotetly see and use another existing session. This allows for a shared session where what is done can be seen both localy and remotely. This is mainly used for helping out other people while talking to them over the phone.

- And lastly, you can execute programs on "Server" without user intervention. This is used in shell scripts on the clients. I call this "Remote Program Submision". This method is different from the preveous methods in that a different method for indetification / authorization is required. Specifically, one that does not have the user type a password. The second difference is that I don't do this often, and thereby probably need help writing the document...

If your requirements fall into one of the above, then read on!

Remote Access and Security

Administration

The development and publication of security policies, standards, procedures, and guidelines, the screening of personnel, security awareness training, the monitoring of system activity, and change control procedures.
How to administer openSUSE remote access?

Authentication

The process of identifying some subject or object, which can be checked and verified. Due to their characteristics, it is usually differentiated between the authenticity (integrity) of a message or file and the authenticity of a transaction. How to verify that the person asking for a remote connection is actually the person he says he is?
How to authenticate openSUSE remote access?

Authentication recommendations

In general, you should group your passwords into categories: Open Passwords: Yahoo mail, Google account, Mailing lists, etc Secure Passwords: Passwords you use in a secure way with 3rd parties. By allowing remote connections to you machine, you move your computer password from the first category to the second category.

On the internet there are people constantly trying to guess your password to break into your machine. These attempts use a list of "easy to remember" passwords. The number of machines that have been broken into with this simple method is astonishing!

Authorization

The process of determining what types of activities are permitted. Usually, authorization is in the context of authentication. Once you have authenticated a user, the user may be authorized different types of access or activity. Now that we've verified who is on the other side of the line, is he allowed to do this?

Audit

An independent examination of a work product or set of work products to assess compliance with specifications, standards, contractual agreements, integrity, or other criteria. How can we tell who? how? from where? at what time?
How to audit openSUSE remote access?

Access Control

Protection of system resources against unauthorized access; a process by which use of system resources is regulated according to a security policy and is permitted by only authorized entities. What kind of policies are in use?

Assessment

The method of identification of risks and assessing the possible damage that could be caused in order to identify appropriate security safeguards.
How to assess openSUSE remote access risks?

Different Remote Access methods

Remote Shell - SSH

To access the shell of a remote computer you can type:

• ssh REMOTEIP -p PORT For example: ssh 192.168.1.1 -26
• ssh SERVERNAME -p PORT Example: ssh SuseServer -8732
• ssh URL -p Example: ssh www.suserules.org -p 22

You can also access the shell of a linux computer from Windows remotely using PuTTY.

Configuring Extra SSH Security

It is simple to setup, and secure. For extra security the following changes need to be made for SSH:

Create User Group for Authorization

Create Group “remotessh”, Add users that are allowed remote access to the group.

Use User Group For Authorization

In file /etc/ssh/sshd_config add the following lines to bottom of file:

  #
  # OpenSUSE wiki Configuration
  #
  Port			26
  AllowGroups		remotessh
  GatewayPorts		yes
  X11DisplayOffset	50
  X11Forwarding		yes

Restart SSHD

restart ssh server typing as root: “/etc/rc.d/sshd restart”

SSH Client Configuration

In order that your clients use the new port 26 you need to change the file /etc/ssh/ssh_config Add lines:

  ForwardAgent		yes
  ForwardX11		yes

Then for each known host with alternate port add following lines before “Host *” line:

  Host	jerry.westrick.com
    Port 26

Remote Individual GUI Program

Terminal Services

VNC and NxServer can create a "Virtual" GraphicCard, Keyboard, and Mouse on server. In this form you can start as many "Virtual Sessions" as "Server" has resources to handle. This allows multiple persons to work on "Server" simultaneously (using his/her local keyboard/mouse/screen ) without needing X-Windows running on the client. This is similar to the windows "Terminal Server" functionality.

Remote Program Submision

Remote X Login

This section will explain how to configure an X terminal and/or a SUSE Linux machine to run an X session on a remote host. You can also use a remote X session if you're stuck on a windows system and want the pleasure of running an X session on a remote Linux system. Required settings on both the host and the client are explained.

If you use X terminals ("thin client") or you want to start a remote X session from a Linux machine, you have to enable the X display manager on the host to listen to XDMCP requests. Note that this type of session is inherently insecure, but there are valid uses for it, such as where both machines are behind a secure firewall.

To enable this on the "server" side (the "remote" system), select "Security and Users" in YAST, then click on "Security Settings" and proceed to the 4th form. There put an X before "Allow remote Graphical Login". This changes the file /etc/sysconfig/displaymanager and takes effect with the next boot-up (the file /etc/X11/xdm/xdm-config will be modified on the fly by the rc script). If you wish you can run "rcxdm restart." Do this by switching to a non-graphical console such as with the key combination ctrl-alt-F1 to go to console #1. Login as root and run "rcxdm restart." Note that alt-ctrl-F7 returns you to the default graphical console, but you'll be returned there automatically as the display manager is reset.

You must also adjust the default settings of the Firewall. Go to YAST then "Security Settings" and choose "Firewall." Once there choose "Allowed Services" and go into the "Services to Allow" pull down. Pull it down (down arrow if you're running the non-graphical version) and choose "Remote Access to Display Manager" then "Add."

Once the above two steps are done, you should be able to run a remote X on the server. For instance, from Windows using cygwin/X (see http://x.cygwin.com/) run "X -query <server name>" and after a minute or two you'll see the usual X login screen. If testing from another Linux system, you can run "X :1 -query <hostname>" where ":1" specifies to use graphical console 1 (alt-ctrl-F8) as opposed to the one you are already presumably using (":0"). This will also require adjustments to the firewall on the client Linux machine (see below). Once you get remote login working, you can (KDE) choose menu->leave->switch user->start a new session and from the login screen select Session->Remote Login and log into the remote.

If you're doing a remote X login from SUSE Linux, you must set the Firewall to allow remote X login as a client also. You'll know you have a problem if all you get is an "X" on a hatched background and the session goes nowhere else. One way to open up the client machine's firewall for x11 protocol is: Yast->Security and Users->Firewall->Allowed Services->Advanced and then add "6000:6063" to TCP and UDP, i.e. the range of x11 ports (see /etc/services).

Working from an X Terminal, you have to configure your X terminal to make a direct XDMCP request to the Linux server, other methods (e.g. "indirect") will not work (at least did not work for me on SuSE 10.3). The often mentioned setting in /opt/kde3/share/config/kdm/kdmrc ([Xdmcp]Enable=true) seems to be completely useless, so leave it alone.

SSH -X

VNC

So what is VNC?

VNC gives you a window on the client in which a remote session is running on the server, which for all practical purposes is equivalent to sitting at "Server" and using the Monitor/Keyboard/Mouse there.

VNC can use a "Virtual" GraphicCard, Keyboard, and Mouse on server. In this form you can start as many "Virtual Sessions" as "Server" has resources to handle. This allows multiple persons to work on "Server" simultaneously (using his/her local keyboard/mouse/screen ). This is similar to the windows "Terminal Server" function.

VNC can also copy the contents of the real Graphic Card giving access to the real screen on "Server" (Remote Desktop). Since you got access to the Physical screen, both the remote and the local users share this session and can see what the other is doing. That is why these methods are used for remote support, and called "Remote Desktop Sharing".

As you can see VNC is very flexible, and therefor has lots of options each suited for diferent needs. Infact you can even "Remote Desktop" share a VNC Terminal Session, by combing 2 of the methods together!

Strengths vs. Weaknesses

   * + Easy to use web browser as a client
   * + Comes with most Linux distributions
   * - Difficult to install and use (... lets not dwell.)
   * - Slow
   * - UnSecure
   * - Can not adjust to different client monitor sizes easily
   * - Bad server and client management (... lets not dwell.)

VNC - Installation

VNC - Installation with Yast

The easiest way to achieve this is to install the default OpenSUSE package "tightvnc".

VNC - Installation from RPM's

VNC - Connectivity

For VNC client connection remember to open ports 5901-> in the firewall. (1 port/Xsession.)
For HTTP connection with Java, remember to open ports 5801-> in the firewall. (1 port/Xsession.)

By default VNC connections will start at port 5900 (or port 5800 for HTTP connections) and then add the display number of the Xsession that has been started. i.e. if the Xsession has been started as display :1 then the port to use to connect to this VNC Xserver session is 5901 (or 5801), likewise the port will be 5902 (or 5802) if the Xsession has been started as display :2.

VNC - Terminal Server

VNC - Remote X Login

Here we use a VNC setup designed to use minimal resources on the server. This is done by not starting the VNC session until someone tries to connect, and shutting the VNC session down as soon as client disconnects from it.

The VNC sessions are identical to the sessions on the physical screen of "Server", they even start of with the identical logon screen.

VNC - User Sessions

Here we "Prestart" vnc sessions for specific users, therefore no login screen is presented. This uses more resources as the VNC Session is running even when no client is connected to the session watching it. But there in lies it's advantage, "watching a session" and "using a session" are not the same thing! This method is very usefull for starting long running programs before going home. Once home you can re-connect to the session and see how things are going.

VNC - Remote Desktop Sharing

VNC - Sharing a Users Session

Here VNC is used to "Share" the current user's Desktop by copying the contents of the physical Graphic Card giving access to the real screen on "Server" (Remote Desktop). Since you get access to the Physical screen, both the remote user and the local user share this session and can see what the other is doing. That is why these methods are used for remote support, and called "Remote Desktop Sharing".

As both users have complete control over the desktop, it can be a lot of fun watching people 200 miles apart fighting for control over a single mouse pointer. However this fun can be stopped by making the session "viewonly", where the remote user can see what is going on but cannot have any input via the keyboard or mouse.

Using the Built-in Desktop Sharing Feature of KDE

To use this feature within KDE you should install the package "kdenetwork3-vnc" (or "KDE4-krfb" if you want to use the KDE4 version) within YAST. The application can then be run as "krfb" from the command line or found as "Desktop Sharing - krfb" in the SUSE menu under Applications - System - Remote Access.

Using this application will allow your local Xsession to become a shared Xsession that others can join. Krfb will automatically make the required changes and create an invitation for the remote user to join your session, that can then be sent either via an email or by letting them know the ipaddress, screen number and password which have been assigned by some other suitable means. Remember that if the remote connection is coming from an external network the ipaddress reported by krfb will be incorrect and the remote user will need to replace it with the external ipaddress of your router. It is likely that the required ports will also have to be forwarded within your router so that it will connect to the intended PC. When the remote user attempts to connect to the shared desktop the issuer of the invitation will be required to accept the connection first and can choose at that time to allow either full or view only access.

NOTE: Just a word of warning. As of SuSE11.0 and 11.1 the KDE apps krfb and krdc are broken. In particular krfb does not serve up a valid rendering of the display and it is badly corrupted with false color blocks and dual images. KRDC will often crash and lock up regardless of what type of server it is connecting to. Both problems have been reported but there appears to be very little activity happening to get these tools repaired.. See below on how to use x11vnc to establish a VNC connection to a live remote desktop for some alternate methods.

  note added by Marc Chamberlin...3/14/2009

Manually Creating a Shared Xsession

If you are not running a KDE desktop or simply want to have complete control over the process, then you can do this manually. One example of this is the application "x11vnc". This comes standard with OpenSUSE but will probably have to be installed first. This can be done easily from within YAST by searching for and then installing the package "x11vnc".

Once installed you can run this from the command line and have complete control over how the Xsession is shared. There are many options available and if want to investigate them the man page for x11vnc is perhaps the best place to start. If you just want to get something going then a quick and dirty default would be the command below:

x11vnc -usepw -ncache -display :0

Broken down this calls the application "x11vnc", tells it to use a password for connection "-usepw", turns on cacheing to speed things up "-ncache" and tells the vnc server to use the first session "-display :0". This is not very fancy and you can even get away with just specifying the display and nothing else but it is generally a much better idea to at least use a password. Experimenting with the different methods of compressing or eliminating some of the network traffic will likely also get you a much faster response on the remote side. But keeping things simple at the start will at least tell you that things are working.

Note that the initial Xsession started at login is labeled as display 0 by default. Subsequent sessions will be started by default as display 1 , 2 ... etc. A password can be created by using the command "x11vnc -storepasswd actual_password /path/to/password_file" or just "x11vnc -storepasswd" if you wish to use the password from an existing VNC installation.

You should be able to test this now by using a VNC viewer from another PC on your internal network to connect remotely. If this is not possible then you can use your own PC to connect "remotely" to your own desktop. This should only be used if you do not have another PC on the local network to use, as you may get some strange screen behavior from it.

Using ssh to establish a secure VNC session remotely

If x11vnc and ssh services are available on the remote machine and you wish to establish a secure VNC session to remotely control an active live desktop try using the following two steps. In one console enter the following command but fill in the user and domain names as needed -

ssh -t -L 5900:localhost:5900 loggedInUserName@computername.domain 'x11vnc -localhost -nolookup -nopw -display :0'

This establishes a secured encrypted connection from your machine to the remote machine. The -t option allows you to run a screen based program and the -L option binds your local VNC port (5900) to the remote machines VNC port. Then you log in as the user on the remote machine and of course you will be asked for a password. Once connected, this will launch the x11vnc server on the remote machine. The parameters given to the x11vnc server allow the local host to establish a connection (-localhost), limits how host name and IP address lookups are done (-nolookup), stops the warning message about not supplying a password (-nopw) and connects to display 0

Next, from a separate console, on your machine, start a vncviewer window with the following command -

vncviewer -encodings "tight copyrect hextile" localhost:0

This will connect to port 5900 which you bound to the remote host port 5900 and pass the encoding parameters that you desire (-encodings "tight copyrect hextile") to the remote x11vnc server and give you a display of the remote desktop on your local display.

This effectively accomplishes the same thing as using the KDE tools Krfb and Krdc (which as of SuSE11.0,11.1 are broken) and gives you a VNC session with a live desktop. (useful for sysadmins, helping mothers, etc..) PLUS it is all done over a secured connection and does not require the user on the other end to do anything!

VNC - Sharing the local X-Windows Session

Here we setup vnc to allow remote access directly to the physical graphic card (X-Windows system), allowing us to see / use the real screen on "Server". This is most used in support where operators do not want 2 people working on the same machine at the same time. In this method the person physically at server can watch everything the remote user is doing.

NOTE: (the windows version of VNC server only supports this mode, as windows does not support virtual screens)

Nx

http://www.nomachine.com

NxServer is a more recent attempt to gain remote access to Linux Desktop. Unlike VNC it normally tunnels its connections trough SSH port (TCP22). It also uses much more advanced algorithms to compress the data.

Strengths vs. Weaknesses

   * + Fast
   * + Easy to install and use
   * + Secure (Very secure. Uses SSH.)
   * + Easily Adjusts to different client monitor sizes.
   * - Not yet standard Linux Remote Desktop system (It should be.)
   * - Not so good server and client management on the free version
   * - Difficult to use web browser as a client

Nx - Installation

You can install NX in several different ways. (Applies to openSUSE 10.2)

Nx - Installation with Yast

Its easy to install using Yast. In Menu start Terminal Program. (On KDE Graphical User Interface - GUI) Enter these commands...

yast -i nxclient
yast -i nxnode
yast -i nxserver

Nx - Installation from RPM's

Its easy to install from the RPM files. In Menu start Terminal Program. (On KDE Graphical User Interface - GUI) Enter these commands...

rpm -ivh client-xxxx.rpm
rpm -ivh node-xxxx.rpm
rpm -ivh server-xxxx-rpm

Then just install the client for your Windows or Linux OS and you are ready to connect to your remote desktop.

Nx - Connectivity

Remember to open port 22 in your server firewall.

Other

XRDP (Alive and kicking.)
CygwinX (Dead, someone should revive it or give it a decent burial.)
RDESKTOP (Somebody help these people, take charge.)
Win2VNC & X2VNC
2X (NX clone.)

External links

• TightVNC on openSUSE
• RDP/XRDP on openSUSE

Internal wiki links

• VNC_Desktop_Sharing