Linux:networking:remoteaccess
From Linux How-To Repository
Contents |
Remote Access with VNC
Partly From: https://help.ubuntu.com/community/VNCOverSSH
Installing
The vncviewer should be installed by default in Ubuntu now, but you probably need to install the vncserver so you can install TightVNC with the following:
sudo apt-get install vnc-common tightvncserver
Enter your user password and everything should install without error.
FontPaths may need changing in your /etc/vnc.conf file. Add these lines to the bottom of the /etc/vnc.conf file:
$fontPath "unix/:7100" # local font server # if the local font server has problems, we can fall back on these $fontPath .= "/usr/share/X11/fonts/misc,"; $fontPath .= "/usr/share/X11/fonts/cyrillic,"; $fontPath .= "/usr/share/X11/fonts/100dpi/:unscaled,"; $fontPath .= "/usr/share/X11/fonts/75dpi/:unscaled,"; $fontPath .= "/usr/share/X11/fonts/Type1,"; $fontPath .= "/usr/share/X11/fonts/CID,"; $fontPath .= "/usr/share/X11/fonts/100dpi,"; $fontPath .= "/usr/share/X11/fonts/75dpi,"; # paths to defoma fonts $fontPath .= "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType,"; $fontPath .= "/var/lib/defoma/x-ttcidfont-conf.d/dirs/CID";
Save the file, and exit.
Note: For Feisty (7.04) and Gutsy (7.10) the default font paths are /usr/share/fonts/X11/
$fontPath .= "/usr/share/fonts/X11/misc,"; $fontPath .= "/usr/share/fonts/X11/100dpi/:unscaled,"; $fontPath .= "/usr/share/fonts/X11/75dpi/:unscaled,"; $fontPath .= "/usr/share/fonts/X11/Type1,"; $fontPath .= "/usr/share/fonts/X11/100dpi,"; $fontPath .= "/usr/share/fonts/X11/75dpi,";
You can probably run a simple vnc connection right away. On your server select System > Remote Desktop and configure the settings to allow for a remote connection. The program you are running here is called Vino. Then on another machine just open a terminal and run this command:
vncviewer remote.host.name.com:0
Or use your server's local network address, if your test machine is on the same network:
vncviewer 192.168.0.100:0
Or you could do this as a quick test on the server machine to see if things will work:
vncviewer localhost:0
This is telling vnc on your client machine to connect to the vnc server at remote.host.name.com using port 5900. If the screen size is a problem, you can do this:
vncviewer -geometry 800x600 remote.host.name.com:0
With either of these commands, you should see you server's desktop appear on the client machine.
Tip
The other way to do it is with this, if you don't want to use the command line:
Applications > Internet > Terminal Server Client
VNC Over SSH
The next thing to do is make sure OpenSSH is installed.
sudo apt-get install openssh-client openssh-server
Enter your user password when prompted and it should install. Once installed on the client and sever computers, you can make a secure, tunneled VNC connection using SSH.
Creating the VNC connection over a SSH tunnel is quite simple, but involves issuing commands at both the client and server computers. To do this, you must have physical access to both machines, or use the ssh application itself to login at the remote computer from the local computer, using a syntax similar to the following examples:
ssh remote.host.name.com
or
ssh 82.211.81.166
Provide the password of your account on the remote machine to complete the ssh login.
Now, the commands required at both ends to start a session. For the purpose of example below, the user's name is just "user" and the remote server's hostname is "server".
Setting Up the Server and Client
Setup On the Host Computer (Server)
To enable a listening VNC server on the server computer, enter this command into a terminal prompt:
vncserver :1
This may not work if you have Vino running, i.e. if you have already activated Preferences > System > Remote Desktop. In that case, you could run vncserver :2, or else you could connect through Vino with the same remote access commands shown in these notes.
If Vino is not running, the first time you run vncserver :1, you may be prompted for a password to use for incoming connections. Enter and verify the password you wish to use to access the server's desktop from the client computer. If you need to enter a password separately, or you want to change it, use this:
vncpassword
The default is for it to write to a /home/user/.vnc/passwd file.
A startup message output from the VNC server will look like this:
New 'X' desktop is server:1
Creating default startup script /home/user/.vnc/xstartup Starting applications specified in /home/user/.vnc/xstartup Log file is /home/user/.vnc/server:1.log
The xstartup here is configured to take sensible defaults from the currently configured X Desktop Interface, or Window Manager, so it should not need additional editing. However, xstartup can be modifed to suit.
Setup On the Local Computer (Client)
It is usually recommended to enable XDMCP:
System -> Administration -> Login Window
Tab Remote -> Configure XDMCP -> Disable "Honor Indirect Requests"
To connect to the server's VNC desktop, from the client you'll simply use the -via parameter of the vncviewer command. The syntax of the command then resembles the following, when using our example host from above:
vncviewer -via 82.211.81.166 server:1
This tells VNC to forward the connection to the server computer via its external or public IP address, in this case 82.211.81.166 (a valid hostname would work here too).
Or use your server's local network address, which can be useful for troubleshooting when the external IP doesn't work:
vncviewer -via 192.168.0.100 localhost:1
Upon entering this command at a terminal prompt, you'll notice some VNC-specific information on screen, and then you'll be prompted for the SSH password. Enter the SSH password, and upon correctly doing so, the SSH tunnel will be established. Next, you'll receive a prompt for your VNC password. Enter the VNC password, and the remote server's desktop should appear!
NOTE: this only works for me if I have Vino running on the server, otherwise I simply get a terminal window.
Router, Port and Firewall Issues
I found that for some things to work, you may need port forwarding setup in your router. Also, you'll need to allow for ssh in your firewall configuration, and also for any extra VNC instances you run because their ports will be different each time. For example, Vino will use the default port of 5900.
So you should be able to make a normal VNC connection through Vino with this:
vncviewer remote.host.name.com:0
Of course, you can change numbers and ports. If you ran vncserver :1 then you would connect via port 5901 with the following:
vncviewer remote.host.name.com:1
Everything seems to work with the default port of 5900. But in my experience you need the router's port forwarding set up to use other ports.
As for connecting with ssh, if you change ports for ssh to make it more secure, or for whatever reason, you need to ensure port forwarding from 222 to 22 (unless your server has also been configured to run ssh on port 222) and firewall access for port 222.
However, it can sometimes be tricky to get things to work when you don't use the default port 22 everywhere.
Lastly, I've had problems with using different vnc servers. I'm using XGL and I believe this conflicts with VNC, so I was just getting errors when I tried to run Xvnc or X11vnc. Also, some would only give me the terminal rather than the whole desktop. So, the path of least hassle for me was to run the simple setup described above.
Tips & Extra Commands
Other Command Formats
Many other commands and options exist for vnc connections. This following command is useful because once you are logged into your server, you can launch server applications from the command line and they will appear as if they are running on your client machine. It's the "Y" parameter that does it.
ssh -Y user@host.com
Here are some other standard command formats:
vncviewer -via user@host.com localhost:0
Here is another one, where you are host C:
ssh -v -L 5905:hostA:5905 hostA
This says that the client on host C listens on port 5905 (the first one in the -L option) and that any connections it receives should be forward to "hostA:5905". With this ssh session active, host C now has a service listening on 5905, as though it were running a vncserver locally. Any connections to that are passed through to the real VNC server on host A, through the ssh session.
Another more elaborate one uses differing port numbers:
ssh -f user@personal-server.com -L 2000:personal-server.com:25 -N
The -f tells ssh to go into the background just before it executes the command. This is followed by the username and server you are logging into. The -L 2000:personal-server.com:25 is in the form of -L local-port:host:remote-port. Finally the -N instructs OpenSSH to not execute a command on the remote system.
To speed up screen repaints as much as possible, the -o Compression and CompressionLevel options can be used, too:
ssh host.com -o Compression=yes -o CompressionLevel=1 -L 5900:localhost:5900
Run Remote Applications From the Command Line
If remote desktop is not disallowed, you can fire it up remotely, run it to get your desktop, then set it to disallowed when finished. First, run vncviewer:
vncviewer remote.host.name.com:1
Then you can also just run vino preferences to enable remote desktop:
vino-preferences
Once it is configured to allow remote desktop viewing, exit vncviewer then rerun it using the port you have set as the default for Vino:
vncviewer remote.host.name.com:2
You can do the same thing after connecting to a server via SSH. First of all connect with this command:
ssh -Y user@host.com
Now you can run any application, often by simply typing its name. For example, let's say you want to run Webmin and change some server settings. You'd first type in "firefox" to get a browser on your server. Then login to Webmin as you normally would with the browser. Note that if Firefox is already open on your server, you will get an error.
As before, to enable remote desktop, run Vino:
vino-preferences
Then you can configure it to accept a remote desktop connection. I've had issues with this if Vino is not using the default port, but there is a way around that. Here is the command I prefer to get Vino up and running after connecting via SSH.
gconftool-2 -s -t bool /desktop/gnome/remote_access/enabled true
Once you have done what you need to do on the desktop, you can then prevent access to it by shutting down Vino with this:
gconftool-2 -s -t bool /desktop/gnome/remote_access/enabled false
If you know what you are doing, you can also edit this file to change the vino server options:
/home/username/.gconf/desktop/gnome/remote_access/%gconf.xml
You could have a copy of this file, with all the details of remote desktop as you like them, on your remote machine. Then when you login in via SSH, you could backup the %gconf.xml on your server and create a new one with the contents of your remote %gconf.xml. Of course, if they don't change there's no point.
So, starting from a simple SSH tunnel connection, you can basically gain control over everything on your remote machine.
Copying Files Back and Forth
To send a local file to a remote location:
scp /path/to/local/file username@remote.host:/path/to/save/file/
To get a remote file from a remote location:
scp username@remote.host:/path/to/file/ /path/to/save/file/to
If you want to use a different port, you would use the same commands above except after scp use the -P parameter and the port number, like this:
scp -P 435 /path/to/local/file username@remote.host:/path/to/save/file/
Note that you don't need to use username@remote.host. You could just use remote.host: and that would give you the server user's home directory automatically. To copy a file to the remote home directory you would use this:
scp myfile.txt remote.host:
If you need to copy data from one computer to other one, especially big volume data, it's much faster to use tar to compress it before sending it over a SSH connection. Here's an example how it could be done:
tar czf - /path/files-to-copy | ssh user@remotehost "cat > /path/data.tgz"
Alternative Port for Vino
If you want to use a different port in Vino, simply change it through this:
Applications > System Tools > Configuration Editor > Desktop > gnome > remote-access > use_alternative_port
Alternative SSH Port & Alias
If you want to change your ssh port do so in ~/.shh/config on your client machine. You can do other helpful things in this file, too.
Host myServer Hostname remote.host.name.com Port 222 HostKeyAlias myServer
Now you only need to do this to get your remote's command line to connect to remote.host.name.com via port 222:
ssh myServer
Or this to get your remote's desktop:
vncviewer -via myServer server:1
This works fine, but if you then use you regular hostname, it defaults back to port 22. So, if your server is set up for port 222, nothing will work. You could of course just use the default port 22 and either hostname or your alias should work.
FreeNX
I've heard good reports about Freenx. However, it's not available for PPC or 64 bit, so I've never tired it. For the moment, I think I'll just stick to vncserver and Vino. These two sites concern FreeNX: http://www.nomachine.com/download.php and http://openfacts.berlios.de
Troubleshooting
If you want to stop the process, which is a good idea if you're not using it because it consumes CPU and memory resources, just do this:
vncserver -kill :1
Port Forwarding
Note that there will be a /etc/ssh/ssh_config file on the server that may need some entries to avoid errors:
X11Forwarding yes GatewayPorts yes AllowTcpForwarding yes
Actually, these settings should already be in the server's /etc/ssh/sshd_config file. In your client machine's ssh_config unhash this entry:
ForwardX11 yes
See "man ssh_config" for more info.
Error Messages
Error Message about Server Already Running
Sometimes when trying to start vncserver at :1, or some other number, you get this message:
A VNC server is already running as :1
But you know you don't have a VNC server running. The problem may be a file in your /tmp. In this example, you would check for a .X1-lock file. If you know nothing is running, delete the file. Also, there may be an X1 file in /.X11-unix. You could delete that too.
Actually, I still get this all of the time, even though I have deleted the tmp files. I can't explain it; however, if I run Vino, it uses the server :1 position. Perhaps it is somehow reserved at boot up.
Error Message about "Unable to connect to VNC server"
This could be a number of things. Perhaps a VNC server session isn't running.
There was a time when I was getting this error because of the number of VNC servers I had running, which were apparently creating conflicts. I was playing around with Vino, Xvnc and vncserver all at once, although wasn't initially aware of it. I'd forgotten, after experimenting a while earlier, that Xvnc was still running as a service at boot-up.
It's wise to kill all processes and start from scratch. Check what's running with something like this:
ps auxw | grep Xvnc
Check what xinetd is listening for with this:
sudo netstat -tap | grep xinetd
Also, I believe you have to wait 5 minutes between sessions. If you don't keep this in mind you could end up changing things because you think they are wrong, when all that was needed was for the system to reset itself.
Error Message about "channel 3: open failed: administratively prohibited"
This could be the result of a DNS problem. However, in my case, I got this when I had not correctly specified the server name, i.e. the underlined part in the following command was wrong: vncviewer -via remote.host.name.com server:1 This effectively meant that a proper VNC server session wasn't being run.
Error Message about "an error starting the GNOME Settings Daemon"
There was an error starting the GNOME Settings Daemon. Some things, such as themes, sounds, or background settings may not work correctly. The last error message was: Process /usr/lib/control-center/gnome-settings-daemon exited with status 1 GNOME will still try to restart the Settings Daemon next time you log in.
This appeared in a pop-up box, telling me that Gnome couldn't draw a desktop. I don't know how to fix this and I bypassed it by avoiding a login scenario by taking Xvnc and x11vnc out of the equation, as mentioned above.
This might be of use for extra info: http://www.styma.org/SunAtHome/RollYourOwnVPN.html This covers many of the Xvnc problems: http://www.movingtofreedom.org/2007/02/16/howto-remote-desktop-with-vnc-in-ubuntu-edgy-gnu-linux/
Summary
Normal VNC
With Vino running on the server, it creates default port 5900 access. So on the client machine it's just a matter of typing this to get a remote desktop:
vncviewer remote.host.name.com:0
That will also work when accessing a windows machine that is running a vncserver, such as VNC Server from RealVNC. You could also use
Applications > Internet > Terminal Server Client.
Otherwise run an instance of vncserver :1 or perhaps :3 then connect with, respectively:
vncviewer remote.host.name.com:1
or
vncviewer remote.host.name.com:3
You can also use these to connect and use a Windows desktop.
VNC Over SSH
If you've run vncserver :1 on your server machine, then this should work:
ssh remote.host.name.com
Or this, depending on your setup
ssh -p 222 remote.host.name.com
Or this,
vncviewer -via remote.host.name.com server:1
The first two will give the remote prompt in a local terminal window. The last one will give you a remote terminal window, as long as your ports are set up correctly. If you have enabled Vino (Remote Desktop) instead of vncserver, this last command will give you a remote desktop, as with the "normal" VNC options above. If you have a different default "entry" port setup for SSH, this last command won't work.
Misc. Notes
More Notes on Setting Up VNC and SSH
From: http://www.cskk.ezoshosting.com/cs/answers/vnc-thru-firewall-via-ssh.txt
VNC consists of two programs - a server and a viewer. This separation lets you have a session of some kind running on the server, and to start up and shutdown the viewer whenever and wherever you like. So you can view at work, set up something long running and GUIfied, then go home and work from there too.
VNC does this by having the server speak two protocols: the VNC protocol, which it speaks between the vncviewer and the vncserver (so that you can view any VNC server's session) and the native windowing protocol of whatever system the server's running the session on (for UNIX, this is X11).
So, on UNIX the vncserver acts as a X server, just like XFree86 and suchlike, but it doesn't talk to a video card. So, you fire up vncserver like so:
vncserver 5 # <== pick some number - 0 will be in use by # your "real" X display, so something else
This results in the server (Xvnc) firing up and listening on two ports: 6005 (for normal X clients like xterm, using the DISPLAY name "host:5", where "host" is the machine your running on), and 5905 (for vncviewers to connect to to see what's going on). So, for the VNC session numbered "n" it lists on port 6000+n as the X server :n and on port 5900+n as the VNC server ":n".
Digging through my old mail I find a diagram I drew for a friend, which I will adapt here. Here's a normal X session, such as you normally run:
monitor | You <-> X server <---------X11 protocol--> client (eg xterm) | | desktop client machine machine (host B) (host A)
Of course, hosts A and B needn't be separate machines. The client (xterm) is connected to port 6000 on host A, and speaks the X11 graphics protocol to draw text and whatnot. The X server speaks to the video card of host A.
Here's a similar setup, using VNC as an intermediary:
monitor | You <-> X server <---------X11 protocol--> vncviewer (a normal monitor X client from host C's | point of view) desktop | machine | (host C) | | +---------------VNC protocol----------+ | V X server <---------X11 protocol--> client (eg xterm) (Xvnc in this case) | | | desktop client machine machine (host B) (host A)
Here we have you seated in front of host C, with the viewer open before you, showing the desktop on host A. Using the earlier example (VNC display #5) the vncviewer is:
- connected to port 6000 on host C, to display the desktop on your local X display - connected to port 5905 (== 5900+5, because "n" is 5) on host A, to get the desktop contents from the vncserver
The X clients on the desktop are:
- connected to port 6005 (== 6000+5) on host A, to write to the X session called "hostA:5"
The Xvnc on host A is not controlling a video card. Instead, it depicts the X session it's supporting to any vncviewer which connects. (There's a login challenge when you connect to a VNC viewer, so don't imagine this leaves you wide open to Joe Cracker). Your vncviewer transcribes that to the X server on host C, and _that_ X server scribbles on your monitor.
So...
The original problem was that host C and host A were on different sides of a firewall. To the outer world (yea, even to the inner world) a firewall looks much like an ordinary router - a transparent box for passing packets back and forth between two networks, save the the firewall only passes some packets, not all. And thus the crackers are kept out.
The proposal was to open a hole in the firewall to pass VNC - in short, to instruct the firewall to pass packets to and from port 5905 (or whichever) on host A, and the outside world. While this would work, it's a bad idea for two reasons:
- you want to minimise the holes in your firewall anyway, and opening a hole means that service is now available to the attack attempts of anyone in the outside world - most protocols carry their traffic in the clear (which is fine, since there are separate tools to tunnel cleartext through encrypted channels, like ssh); this means that if you _don't_ tunnel the traffic through ssh or suchlike then your session passes in the clear across the open net, available to anyone who wants to snoop. It is to be presumed that this is bad because your activity is confidential, otherwise you'd not want a firewall at all.
So, rather than pass the VNC session in the clear, we will use ssh to get in through the firewall, and tunnel the VNC traffic (and everything else: email, news, telnet, whatever you like provided it's TCP/IP) across the ssh connection, safe from prying eyes.
This has two main advantages: as stated, it conceals the traffic with strong encryption (ssh is a fine Finnish product, unencumbered by the reactionary oppression of the Wassenaur agreements as enforced by the "free" governments in the US and Oz and elsewhere). Secondly, the permission to make the ssh connection is governed by strong cryptographic authentication, so you have good confidence that the people you've let in aren't Joe Cracker but in fact particular individuals to whom you've granted this right, like yourself. (That confidence is, of course, subject to these people all practicing good security: good pass phrases, careful control of keys, etc).
So, there are thus three tasks ahead:
1 set up ssh service on host A, and a client on host C with the right key 2 arrange the tunneling of the VNC traffic over ssh 3 permit ssh (port 22) traffic through your firewall, probably only aimed at select hosts like host A, which have ssh set up
Part 1: Install ssh
Visit the ssh faq: http://www.uni-karlsruhe.de/~ig25/ssh-faq/ Well worth the read, and it also lists download sites.
Fetch ssh (current up to 1.2.27 for ssh1) from ftp://ftp.cs.hut.fi/pub/ssh/ Build and install on host A and host C.
You should lock down whatever machine will be reached from the outside with ssh (host A). I've appended an (edited) copy of the /etc/sshd_config for our ssh terminus (the box people can ssh to from outside) at the bottom of this message. Note in particular the following settings (described in the manual entry for sshd):
AllowUsers cameron RSAAuthentication yes KerberosAuthentication no PasswordAuthentication no RhostsAuthentication no RhostsRSAAuthentication no TISAuthentication no PermitEmptyPasswords no KerberosOrLocalPasswd no KerberosTgtPassing no AllowTcpForwarding yes FascistLogging yes IgnoreRhosts yes IgnoreRootRhosts yes PermitRootLogin no
In short: an explicit list of permitted users, RSA auth only, no root logins. Host A is exposed to the whole planet for the ssh service - make it well defended.
Client setup:
For the initial testing, we will use a host C which is _inside_ the firewall. Only after this is properly set up will we be opening holes in the firewall for this scheme. (If you've only got host A inside the firewall, pretend it's host C; nothing prevents you sshing to a host from itself).
Ssh must be installed on host C. On host C, as yourself (not root!), run the command ssh-keygen This will generate a keypair and prompt you for a passphrase to protect the keys. Make you passphrase good - an entire sentence, at least somewhat obscure. The passphrase is the weakest point in the scheme in some ways, and deserves attention.
Ssh-keygen will have made two files: ~/.ssh/identity ~/.ssh/identity.pub These are your private and public keys, respectively. The public key is the one you give to the people running the hosts you want to connect to; it is used by them to verify that you possess the private key, and thus that you are who you say you are. From that, you can deduce immediately that YOU MUST NEVER GIVE THE PRIVATE KEY TO ANYONE!
Ok, you have the keys. The public key must be installed in your account on host A so that host A knows to let you log in. Copy the identity.pub file from host C to the file ~/.ssh/authorized_keys on host A. If there's already an authorized_keys file there (such as when you repeat this for a new remote host "D"), append the identity.pub file to the authorized_keys file. "authorized_keys" is simply a list of the public keys identifying the people whom we will permit to log in.
Ok, on host C say: ssh -v hostA This should connect to the running sshd on host A, prompt you for your passphrase, then give you a login shell on host A. If your login on host A has a different name than on host C, you'll need to supply that: ssh -v -l hostAlogin hostA
Things like the login name can later be automated in your .ssh/config file, and you can use the ssh-agent command to save typing your passphrase for every login. However, those are activities for later, and outside the scope of this message. Some RTFMing ahead!
Once you can ssh from host C to host A, it's time to configure the port forwarding.
Part 2: Tunneling VNC over the connection.
I'll presume you've got VNC running happily on host A already. For the sake of concrete examples I'll presume you're using display :5.
One of ssh's facilities is port forwarding. This comes in two flavours: local and remote. A local forward causes your client ssh (on host C) to listen on a particular port; when something connects to that port, the server end (on host A) makes a corresponding connection to some specified host and port, and copies the traffic to and fro, via the ssh connection. A remote forward is just the reverse: the server on host A listens, and your client on host C makes connections.
We will be using a local forward to do the VNC traffic, because we will be connecting the vncserver on host C to your client (on host C), and the sshd on host A will be connecting to the vncserver and copying the traffic.
To do this, run this command on host C:
ssh -v -L 5905:hostA:5905 hostA
This says that the client on host C listens on port 5905 (the first one in the -L option) and that an connections it receives should be forward to "hostA:5905". With this ssh session active, host C now has a service listening on 5905, as though it were running a vncserver locally. Any connections to that are passed through to the real VNC server on host A, through the ssh session.
So... With that up and running, you can run a vncviewer on host C, telling it to connect to "localhost:5". This will connect to the port serviced by your ssh command, and thus transparently through to the real service on host A.
Obscure? Let me draw the new picture:
monitor | You <-> X server <---------X11 protocol--> vncviewer (a normal monitor X client from host C's | point of view) desktop | machine ssh on host C <--VNC proto-+ (host C) | | ssh protocol | V +-VNC proto-- ssh on host A | | V X server <---------X11 protocol--> client (eg xterm) (Xvnc in this case) | | | desktop client machine machine (host B) (host A)
The ssh-on-host-C is listening on port 5905. The ssh-on-host-A has made a connection to port 5905 on hostA in response to your vncviewer (on host C) connectioning to hostC:5905.
Part 3: allow ssh through the firewall.
You can this arrange yourself, since you control your firewall. Once done, we will consider the firewall to be just another router, since it's no longer obstructing our ssh traffic. The upshort of this is that I don't need to draw it in the diagram! And you can then repeat your host C stuff on a machine outside the firewall and it should behave the same as it did inside the firewall.
Is that any clearer?
With schemes like this in place you can do all sorts of groovey variations, like also passing email and news and web traffic from host C to private services inside your firewall. We arrange this for our travelling staff.
Sample /etc/sshd_config appended below. Read, understand (with the help of the FM), and adapt.
Cheers, -- Cameron Simpson, DoD#743 cs@zip.com.au http://www.zip.com.au/~cs/
Careful and correct use of language is a powerful aid to straight thinking, for putting into words precisely what we mean necessitates getting our own minds quite clear on what we mean. - W.I.B. Beveridge
# This is ssh server systemwide configuration file. # Access control # AllowGroups # AllowHosts # AllowSHosts # AllowUsers AllowUsers cameron # DenyGroups # DenyHosts # DenySHosts # DenyUsers # Authentication RSAAuthentication yes KerberosAuthentication no PasswordAuthentication no RhostsAuthentication no RhostsRSAAuthentication no TISAuthentication no # CAKeysSource /var/ssh/userkeys # GlobalKnownHostsFile /path/to/textfile # X11 X11DisplayOffset 10 X11Forwarding yes # Passwords PasswordExpireWarningDays 14 PermitEmptyPasswords no # Kerberos KerberosOrLocalPasswd no KerberosTgtPassing no # Misc non-defaults AccountExpireWarningDays 14 AllowTcpForwarding yes CheckMail no FascistLogging yes IdleTimeout 1d IgnoreRhosts yes IgnoreRootRhosts yes ListenAddress 0.0.0.0 PermitRootLogin no Port 22 PrintMotd no SilentDeny no Umask 0022 # Compiled-in defaults # ForcedEmptyPasswdChange # ForcedPasswdChange # HostKey # KeepAlive # KeyRegenerationInterval # LoginGraceTime # PidFile # QuietMode # RandomSeed # ServerKeyBits # StrictModes # SyslogFacility # XAuthLocation
Notes on Port Forwarding with SSH
From a Linux Magazine article by Jeremy Garcia
Whenever you SSH from one machine to another, you are establishing a secure encrypted session. You can take this one step further with SSH port forwarding, which allows you to tunnel arbitrary TCP connections though your secured session. Port forwarding can be useful in a variety of situations, from securing remote POP3 connections to tunneling through firewalls. If you are doing the latter, make sure to be mindful of any policies your IT department may have in place. There are two kinds of SSH port forwards, LocalForward and RemoteForward. I'll give one example of each, and will cover the two scenarios given. If you're having problems with SSH port forwarding, the debug option (-vv) should provide you with some useful clues.
The -L flag is used to enable LocalForward functionality and will forward the given port on the local SSH client to the specified remote host and port. The syntax is -L localport:host:hostport. Let's say you have a remote mail server that does not support encrypted POP3. You don't have a local shell account on that mail server, but you do have an account on a development server that is on the same network as the mail server. You can use port forwarding to secure traffic from your local machine to the remote development server. Note that the traffic will travel from the development machine to the mail server unencrypted. While this is not ideal, it's a large improvement as all traffic over the Internet will be secured.
The following command will forward port 9110 on your local machine to port 110 on the mail server, via the development server. We're using port 9110 on the local machine instead of 110 since privileged ports (those below 1024) can only be forwarded by root. The -Nf flags will run SSH in the background, without requiring the execution of a command on the remote machine.
$ ssh-Nf-L 9110:mail.server.com:110 development.server.com
The -R flag is used to enable RemoteForward functionality and will forward the given port on the remote server to the specified local host and port. This can be used to allow access to your local workstation at work, even if a firewall and NAT are in the way. The syntax is -R remoteport:host:hostport. For this scenario, you will need sshd running on a machine that you have access to from home. From your machine at work, run the following command:
$ ssh-nF-R 2222:localhost:22 machine.you.have.access.to.from.home
Now, from home you can connect to that machine and run:
$ ssh-p2222 localhost
You are now connected to your work machine. Some firewalls may disconnect inactive sessions. In this case you can exec a ping via SSH to generate activity or set the ClientAliveInterval parameter in sshd_config to request a message from a client that has not sent data.
In addition to specifying -L and -R on the command line, you can also use a Host specification in your local SSH config file. To replace the -R example used above, put the following into your ~/.ssh/config file:
Host work-tunnel Hostname x.x.x.x RemoteForward 2222:localhost:22 User jeremy
You should replace jeremy with your username and x.x.x.x with the IP address of the machine you have access to from home. If you get tired of typing passwords when forwarding traffic, you can set up SSH keys, which I covered in the June 2004 column. (http://www.linux-mag.com/id/1711)
SSH port forwarding can prove useful in a variety of situations-- I've only covered the basics. Be sure to follow any company policies and be aware of the security implications that using port forwarding may introduce into your setup. If you do that, you will find the flexibility offered by port forwarding to be extremely useful.
