Remote Access to SUSE

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.

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

- 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 Requirements

A very important requirement you need to consider is security. Here we can break security into 3 parts:

Authentication

The first security requirement is authentication. That is verifying that the person asking for a remote connection is actually the person he says he is.

The methods used in this paper do this by requiring the user to identify himself with his username, and verifying it with a password known only to that user.

This is a common scheeme, used many times. The difference is that this time It's not a joke. This is not one of those places where you can use the password "welcome", or any of the other "easy to remember" passwords (such as the name of your pet!).

This is also not the place to use a password which you have preveously used in a mailling list, or as the password to your email account.

In general, you need to 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 connctions 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 be broken into with this simple method is astonishing! I do not want to help you get on that list! So, Please take this warning seriously...

Authorization

The second requirement is authorization. Now that we've verified who is on the other side of the line, is he allowed to do this?

Encryption

And last, but in no way least, comes encryption. The Internet is basically insecure. With the event of WLANs, most home networks are also Insecure! So you need to realize when it's possible for outsiders to spy on your remote connections.

Please considder this seriously, as with many of these methods a third person could easily read your bank account number, Username and even your password, giving him all he needs to financially ruin you!

Installing SSH Security

In this document SSH (configured for username / password checking) is used for all 3 security needs. It is simple to setup, and secure. But only as your passwords are :-)

SSH Configuration

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 with: “rcsshd 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

To Here... Rest is not structured correctly

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 Desktop Sharing

VNC can also copy the contents of the physical 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".

Security

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!

VNC as 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 as Remote Desktop Sharing

Sharing a Users Session

Here VNC is used to "Share" the current user's Desktop. This is most used for Remote Support, and is provided by KDE directly.

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)