Secure Shell + Remote Access

Secure Shell + Remote Access
— print (last updated: Jul 15, 2009) — print

Personalize this online document by providing values relevant to you.

Replace the generic LOGIN by the actual login:

ok
Replace the generic MACHINE name by its actual name:

ok
Replace the generic TAZLOGIN by your actual taz login:

ok

man and info pages

This document explores in some detail several of the secure-shell commands, including ssh, scp, and rsync. To get a deeper understanding of the options and usages of these commands. Linux provides on-line documentation of virtually all its commands through its man pages. The man page for a typical command, say ssh, is invoked by:

$ man ssh

Doing this throws you into a "more-like" pager. Here are useful things to do:

up/down arrow       move up and down in the document
q                   leave the pager
G                   go to the end
g                   go to the beginning
/keyword            search for a keyword
n                   move down the document by keyword occurrences
N                   move up the document by keyword occurrences

If you want to study a man page in more depth, it's useful to have a more "permanent" version that is easier to page through, or to print. The miscellaneous notes have a section, Converting Man Pages to PDF, which addresses this exact issue.

Info pages

There is an alternative online documentation reader called info. Nevertheless, some of the online documentation is written exclusively in this format. A good example is

$ info coreutils

This categorizes and provides information on some of the most basic executables in a Linux system, like echo, cat, sort, head, tail, etc.

Access through taz

If you're on any of the linux systems, you can access the server

taz.cs.wcupa.edu

in it's unqualified form simply as taz. The reason is that you entered information of the form:

search cs.wcupa.edu

when you set up the Networking. You can see the "name resolver" file contents by doing:

$ cat /etc/resolv.conf

Outside the Linux system, you must use the fully qualified form taz.cs.wcupa.edu. For simplicity, I'll use the unqualified form in this document.

ssh

The ssh executable established secure-shell access from client to server. Both the student taz machine and your machine can act like servers. The difference is that taz is accessible from the outside world, whereas your machine is accessible only within the firewall of which taz is a member. Try these commands from your computer (subsitute appropriately for TAZLOGIN):

[MACHINE] $ ssh TAZLOGIN@taz
[taz] $ exit
[MACHINE] $ ssh TAZLOGIN@taz ls
[MACHINE] $ ssh TAZLOGIN@taz "(cd /usr/share/doc; ls)"

If you're on taz, ssh back to your computer:

[MACHINE] $ ssh TAZLOGIN@taz
[taz] $ ssh LOGIN@MACHINE

using cryptographic key

This sequence of steps will illustrate how to allow ssh access from your MACHINE to taz without password entry. Use two shells, one on your machine, the other ssh'd into taz.

On your machine, create your public/private key pair. This key-pair can use either the RSA (the default) or the DSA algorithm. Both RSA and DSA at reasonable strengths (# bits) are considered quite secure. Both implement the necessary asymmmetric public key/private key validation used to establish a secure connection.
```
$ ssh-keygen
```
This will prompt for a passphrase (empty), and a place to store the public key (the default). Therefore, hit "Enter" three times.

View the results by typing:

$ ls ~/.ssh
id_rsa             this is the private key
id_rsa.pub         this is the public key

$ cat ~/.ssh/id_rsa.pub

Then send this file to taz via scp:
```
$ scp ~/.ssh/id_rsa.pub TAZLOGIN@taz:
```
From your taz shell create, if necessary, the directory ~/.ssh/ and concatenate the contents of id_rsa.pub (sent from your machine) onto the file ~/.ssh/authorized_keys2:
```
[taz]$ cat id_rsa.pub >> ~/.ssh/authorized_keys2
[taz]$ rm id_rsa.pub
```

Now test drive your access to taz from your machine by running the ssh commands from the above section.

Install NX Server on MACHINE

NX is a secure-shell based service which does highly-compressed, highly-cached, X forwarding software package. It touts itself as being able to effectively run X sessions remotely over a 56K modem line (I've never tested that myself). The nxclient software package available through

http://www.nomachine.com/

is equivalent to (but better than) Windows' remote desktop. With respect to Linux, NX software offers an effective replacement for VNC. There are both free and commercial versions of this software, but everything is proprietary. Some of the library code is the basis of an "open source" version called freenx which can be installed; however, in the past I have had compatibility problems in combining the proprietary client with the open source server, and decided to abandon it.

From the NX site, go to the download for Linux. You need all three of these packages (client, node, server). The following recent versions are downloadable from these links:

nxclient_3.3.0-6_i386.deb
nxnode_3.3.0-17_i386.deb
nxserver_3.3.0-22_i386.deb

Install (or update older versions of) all three Debian packages. By default, Firefox downloads to the Desktop, and so you would do:

$ cd ~/Desktop
$ sudo dpkg -i nx*.deb
$ rm nx*deb                   (so as not to clutter up Desktop)

The service is started automatically. All the installation files are within the directory:

/usr/NX/

Create client key and make it accessible

You need to create a client key and make it accessible to clients. Open a shell in your home directory and run:

$ sudo /usr/NX/bin/nxserver --keygen
$ cd ~
$ ln -s  /usr/NX/share/keys/default.id_dsa.key  MACHINE.id_dsa.key

This file, MACHINE.id_dsa.key, is what you will need to supply to any nxclient installation, so transfer it to taz to make it accessible.

$ scp MACHINE.id_dsa.key TAZLOGIN@taz:

Access from "inside" client

By an "inside" client we mean a computer which, like MACHINE, is inside the CSC firewall. In this case you can connect directly without tunneling through taz.

Log on to one of the "client" machines in the lab running Fedora. These are clients of taz.

nxclient initial configuration

Access NX Client by:

Applications Internet NX Client for Linux NX Client

NX Client uses the directory ~/.nx to store its information. For the first invocation this directory does not exist and so the software presents you with a configuration wizard which mostly creates what you need. Go forward to the first step.

Set the Session and the Host to MACHINE. Keep the Port set to 22.
For Select type of your internet connection, move the slider to the far right (LAN).
For Desktop, choose Unix, GNOME, Available Area.
Make sure that the Disable SSL encryption of all traffic checkbox is unchecked.
Uncheck Create shortcut on Desktop.

At this point, you are presented with the initial popup which you will see from now on when NX Client is invoked. At first, we must continue with the configuration:

Set the Login to LOGIN (on your Ubuntu computer)
Press the Configure button.
Double-check the settings. In the Advanced tab you should see the Disable SSL encryption of all traffic unchecked.
(optional) Click Remember my password
Click the Key button.
From the Key Management popup, click Import, navigate to the MACHINE.id_dsa.key file, then click Save.
Click Save, then OK to leave configuration
Back at the login prompt, type the password for LOGIN on MACHINE. Click the Login.

You're in! You can run both the local GNOME login as well as the remote NX sessions simultaneously, but there will be some application conflicts, the most notable being Firefox: you can't run Firefox in both places at the same time. Leave by the usual Log Out. Observe that the menu choices do not allow Shut Down nor Restart.

Tunnel via shell

The ssh command, used in the appropriate way, will permit you to tunnel through taz. For Windows systems this can be achieved using Cygwin with openssh installed.

Selecting tunnel ports

We are going to create a "tunnel through taz" to get to MACHINE. This is done by chosing a dedicated port on your local machine which will serve for the through connection. Port number 1024 and below are considered off limits, and you have to should other dedicated ports outside this range, like MySQL's port 3306, etc. Otherwise, there are few limitations. We make the somewhat arbitrary choice:

tunnel ssh port to MACHINE is 7020

Variations on this are:

other ssh tunnels (through other machines/to other machines): 7021, 7022, 7023, ...
tunnel other services like http (port 80), e.g.: 7080, 7081, 7082, ...

Open two shells: one will simply set up the tunnel through taz (with login TAZLOGIN); the other will access the remote machine directly. The tunnel is created by executing:

$ ssh -L 7020:MACHINE:22 TAZLOGIN@taz.cs.wcupa.edu

Unless you have set up cryptographic key access to taz, execution of this command should request a password:

TAZLOGIN@taz password: your-taz-password

When you want to stop the tunnel, simply log out of the taz shell.

ssh into MACHINE

From the other shell, execute this:

$ ssh -p 7020 LOGIN@localhost

Note that we're using localhost, since the port 7020 is the entry point into the tunnel to MACHINE. Unless you are have set up a cryptographic key login to MACHINE you should get a password prompt:

LOGIN@localhost password: MACHINE-password

After a successful login you should see the expected prompt:

LOGIN@MACHINE ~ $

scp through the tunnel

You can also use scp (or rsync) through the tunnel. For example, to download from MACHINE to the local computer, in the current directory, do this:

$ scp -P 7020 LOGIN@localhost:FILE_ON_REMOTE .

or to upload to MACHINE:

$ scp -P 7020 FILE_ON_LOCAL LOGIN@localhost:

Note that the scp command uses upper case P for the port option whereas ssh uses lower case p!

Tunnel from Windows Client

All Windows clients are presumed to be outside the CS firewall and tunnel through taz to connect to your machine. You will need these software packages:

PuTTy: see http://www.cs.wcupa.edu/~rkline/putty.html.
WinSCP: see http://www.cs.wcupa.edu/~rkline/winscp.html. My site recommends the "portable executable," buy I would recommend following the link to the home page and installing the full Installation Package in its latest version. The installation's default is the "Commander" interface, but I prefer the "Explorer" interface, but, it's up to you.

Set up the tunnel using PuTTy

PuTTy is "portable executable" which needs no installation. Double-click to run it and follow these steps:

Type taz.cs.wcupa.edu into the Host Name field
Type taz in the Saved Sessions field and click Save
Go to Connection SSH Tunnels
Enter 7020 in the Source port field
Enter MACHINE:22 (your Ubuntu computer name, unqualified) in the Destination field
Click the Add button. It should create a line:
```
L7020   MACHINE:22
```
Go back to the Session and click Save. The tunnel is set up.
Click Open.

After this is done, the only steps you need to do to "Start the Tunnel" are:

Fire up PuTTy
Open the "taz" line from the Saved sessions.
Log in to taz.

Test the tunnel via PuTTy

Start the tunnel. Invoke PuTTy a second time. This time you want to enter:

Host Name: localhost Port: 7020 (the tunnel port)

Click Open and you'll see:

login as:

This is for LOGIN on MACHINE, believe it or not! Go ahead:

login as: LOGIN 
LOGIN@localhost's password: the-password-for-LOGIN-on-MACHINE

NX client through tunnel

Install NX Client

For Windows client, a recent NX client package is:

nxclient-3.3.0-6.exe

The Windows installation does everything for you and starts running the configuration. Install this by double clicking. Take all the defaults. Don't run it yet.

The client installation for Linux is no different. Like Windows, only the relevant client package needs to be installed.

Download NX key file

The Install NX Server section above has you sending the key file MACHINE.id_dsa.key to taz.

You need to get the key file from taz to your client (Windows or Linux). In Windows WinSCP is relatively easy to use. Start WinSCP, create a login to taz.cs.wcupa.edu (must be fully qualified) and download the key file.

For Linux use tools like scp or gftp to obtain the key file.

NX through tunnel

Make sure the tunnel is started, fire up NX Client for Windows, and start the configurator.

Set the Session to MACHINE.
Set the Host to localhost. and set the Port set to 7020 (the tunnel port).
Probably keep the slider where it is.
For Desktop, choose Unix, GNOME, Available Area.
Make sure that the Disable SSL encryption of all traffic checkbox is unchecked.
Uncheck Create shortcut on Desktop.

At this point, you are presented with the initial popup which you will see from now on when NX Client is invoked. At first, we must continue with the configuration:

Set the Login to LOGIN (on your Ubuntu computer)
Press the Configure button.
Double-check the settings.
(optional) Click Remember my password
Click the Key button.
From the Key Management popup, click Import, navigate to the MACHINE.id_dsa.key file, then click Save.
Click Save, then OK to leave configuration
Back again, type the password for LOGIN on MACHINE and click the Login button.

Windows, because of its inherently lame system-level security, needs to have installed a plethora of overprotective firewalls, spyware detectors, virus dectectors, etc., which may try to block this access. This should be the only impediment to connecting.

NX client for multiple sites

Perhaps there is a more direct way to deal with multiple sites in the commercial NX client version, but the only way I could figure out was this hack:

Go to the .nx/config/ directory from your home directory.
Make a copy of the current MACHINE.nxs to some-other-server.nxs
When you run nxclient anew, you should see both servers in the Session drop-down list.
Select some-other-server entry, hit the Configure button and go through the appropriate configuration steps.

Discussion

The basis of secure transfer of information on the web is the Secure Socket Layer (SSL). This represents a conjunction of cryptographic algorithms and protocol standards. The version of SSL used by Linux is called OpenSSL. Information can be found about it at the website:

http://www.openssl.org

Secure shell is one form of encrypted transmission relying upon SSL. It has its own website:

http://www.openssh.com

Secure transmission relies on cryptographic algorithms both of the asymmetric and symmetric type. Symmetric algorithms are those in which the sender and receiver share the same secret cyptographic key used for encryption and decryption of message packets.

Symmetric algorithms are faster, but less flexible than the asymmetric algorithms which rely upon public-key cryptography in which the encryption keys are key pairs consisting of a private (secret) key, known only to one side and a public key which anyone can obtain. Either key of the pair can be used for encryption or decryption, and the other for the opposite function, depending upon the circumstance.

When a secure session is negotiated, both a host key pair and a session key pair are used. The host key pairs (for different cryptographic algorithms) are created by the server when the secure shell daemon, sshd, is first run. Host key pairs are commonly stored in the directory /etc/ssh/ as these files:

ssh_host_key         ssh_host_key.pub
ssh_host_dsa_key     ssh_host_dsa_key.pub
ssh_host_rsa_key     ssh_host_rsa_key.pub

These keys represent the "identity" of your machine and need to be maintained and reinstalled if the operating system is reinstalled. A secure shell client will install the RSA public key of the server on first contact. In Linux systems, it is stored in the file ~/.ssh/known_hosts.

If the servers keys are changed, clients will will receive a security alert indicating the possibility of a "man-in-the-middle" attack whereby some other machine is spoofing the targetted server. The only way to resolve this problem for the client is to remove the conflicting line in ~/.ssh/known_hosts.

Once the secure session has been established, the client generates a random key based on the public host and session keys, encrypts it and sends it to the server. The server decrypts the random key using its private keys. This random key then serves as a secret key known only to the client and server for this session and all other encryption is done via this random key using a symmetric algorithm.

The /etc/ssh directory also contains the configuration files:

ssh_config: configuration for client program, ssh
sshd_config: configuration for server program, sshd

If you make any modifications to sshd_config (some are suggested below), you need to restart the ssh service to pick up the changes, i.e.

/etc/init.d/ssh restart

Keeping sshd alive

Secure shell service may kick off clients often too quickly unless a modification is made to

/etc/ssh/sshd_config

Edit this file (as root) and look for the commented-out line

#ClientAliveInterval 0

This indicates the default value for this configuration setting. Uncomment it and change the value:

ClientAliveInterval 300

Then restart secure shell:

$ sudo /etc/init.d/sshd restart

X11 forwarding

Forwarding X11 allows you to display GUI clients running on the remote server on your local host's display. There are a number of security issues involved with using this feature, so both client and server must participate. To see the forwarding settings, run this:

# grep Forward /etc/ssh/*config | grep X11

obtaining these results:

/etc/ssh/ssh_config:#   ForwardX11 no
/etc/ssh/ssh_config:    ForwardX11Trusted yes
/etc/ssh/sshd_config:#X11Forwarding no
/etc/ssh/sshd_config:X11Forwarding yes

The client's config file defines "ForwardX11Trusted yes" while the server's config file defines "X11Forwarding yes" (the defaults on both are "no"). We take advantage of the forwarding using the -X option:

$ ssh -X TAZLOGIN@taz gedit

In addition to the -X option, the -Y option has similar functionality, but it allegedly less secure. In some circumstances, like using ssh on Cygwin/X, it appears necessary to use the -Y option instead of -X.

Root login options

The default setting specifying the accessibility by root is seen in this commented line in /etc/ssh/sshd_config. Edit this file (as root) and look for the commented-out line:

#PermitRootLogin yes

Saying "no" instead of "yes" will disallow any root login attempt in any way (do not do this, as the course administrator needs to have remote root access). A good alternative is:

PermitRootLogin without-password

This does not mean that you can get in to root remotely "for free", it means that ssh access to root can only be done via cryptographic key, not the normal login process (see below).