The Complete Geek

As a corollary to my last post I wanted to describe how to disable TCP forwarding.
You will want to add or uncomment the following line and make sure it is set to no in /etc/ssh/sshd_config

AllowTcpForwarding no

The default is “yes"

Note you will want to make sure that users do not have permissions to set their own forwarders, but this is the global disabling.

This can also be done on a per user basis with the enforce key-based authentication and use per-key directives in each user's authorized_keys file. This is further explained in "AUTHORIZED_KEYS FILE FORMAT" section of sshd http://man.he.net/man5/authorized_keys

I have not done this myself but maybe something you want to evaluate if you are hosting a shared resource.

Labels: Linux, Remote Administraton, SSH, Tunneling

This is another one of those old school tools that can make your administration life much easier.

What is it:
It is easiest to think of an SSH tunnel as software VPN from your computer (Client) To the server serving SSH. You can then forward any traffic to or from your PC through this tunnel. While not like a full VPN in operations it allows you to forward traffic securely through the tunnel like you are on the network.

Why this instead of a true VPN you ask?

Because it is free, does not require specific network equipment, often pre configured to be ON already on most linux distro's, and setup is easy.

How I have used it:
I have used this tool in many scenarios from my home network, where I want to be secure or access resources that are either impractical to share out individually or were of a type you do not normally publish to the internet (Like Windows File sharing, or NFS)

Also have used it when I need access to resources in networks where there are either overly concerned network guys or where it was impractical because of design to publish out needed resources to the public internet.

Example:
Here is an example of the data flow when it is configured, this example encompasses tunneling a VNC session of the SSH server back through the tunnel and tunneling data (Windows file share port 139 from server 2 back to the ssh server then through the tunnel

Figure 1


Configuration:

Linux:
Using standard open SSH simply use the following line

ssh -L localport:remotemachine:remoteport Targetaddress

So for our example of VNC in Figure 1

ssh -L 5900:localhost:5900 SSHserversaddress

In plain English this tunnels local port 5900 through the tunnel and loops it back to the local host of the SSH server also on port 5900

Following Figure 1 if we wanted to then configure port 139 (windows file share)

ssh -L 139:Server2Address:139 SSHserversaddress

What this says is listen on local port 139, forward it through the tunnel to server2's address also on port 139 at the far side of that tunnel

Windows:


Advanced Usages:


There are a couple of advanced cases that you can use this for, once you have the concept down it is easy

1) Forwarding different local ports to the same port different destinations on the remote side

Linux:
ssh -L 5900:localhost:5900 -L 5901:Server2Address:5900 SSHserversaddress


What this does is forwards port 5900 to the localhost address of the ssh server also port 5900, it also forwards local port 5901 to server 2 port 5900

In this way you can have a whole bunch of the same traffic to different machines on the far side of the wire without having to change VNC configuration on the far side to listen to a non standard port.


In addition the -N flag can be useful it launches the tunnel without starting a remote session so you can use a 2nd session to communicate through the tunnel
Windows:


Figure 3




What this does is forwards port 5900 to the localhost address of the ssh server also port 5900, it also forwards local port 5901 to server2 port 5900


2) Setting the tunnel to accept connections from other computers on your network to forward through the tunnel.

This one I am going to do in putty only, But putty is available for linux as well. I am unsure if it can be done with openssh

Figure 4

Just one more checkbox here, what this allows you to do is forward on requests from other machines through the tunnel to the far side, making this even more VPN like (Kind of like VPN + NAT through the tunnel)

*Note in all above screenshots replace server2 with the IP address of Server 2 or the host name if the ssh server knows it

Rather cool video I ran across on youtube

An interview with Dan Anderson, The designer behind vmworld 2009's data center.

Also get to see a bit of the hardware close up for those of us who could not attend this year.

Also an impressive amount of money for only 2 weeks (As stated in the video a rough estimate of 35 million dollars!)

I ran across this a week ago or so, it was more than helpful

http://www.vmware.com/files/pdf/perf-vsphere-memory_management.pdf

A good clearly defined explanation of memory resource management in ESX. It was clear and concise and covered all the major topics like page sharing, ballooning and memory reclamation. As well as a good case study and basic covering of best practices

Worth the read

Labels: Balooning, ESX, Memory Management, Page Sharing

What is remote-X you ask?

Its a tool I have been using for years that can make multi system administration, testing, access a easy task.

The basics of how it works is this, Remote X11 forwarding is as it sounds, you can redirect the visual portion of linux apps over the network via your favorite SSH client. This works from both another linux client OR from a WINDOWS machine!

Why would you use this?
If you are like me and need to use tools from both the windows and linux world to do your job it can make things easy for gaining access to thoes tools.

Using me as an example I run Windows server 2008 as my base desktop OS and run several debian virtuals at home and the office (or on the laptop itself using vmware server) and just run the graphical apps remotely

I will note that this access method is not really designed for WAN access or in high latency environments, if that is what you are looking for there are other tools to accomplish this. The advantage of this tool is really that it is integrated and that it does the equivalent of seamless windows (so it is only the application that pops up)

How to:
Configure the server:
Step one is to configure the server to send its X11 information over tssh, with debian has this on automatically some other distro's necessitate modifying /etc/ssh/sshd_config


The line you need to make sure is in there and uncommented is

X11Forwarding yes
At that point your machine should be setup to forward X11

One caviat that I  have found also is ssh as the user that you want to execute the application as, X11 gets confused by su and switching to another user, it does not know how to forward the display through the other session.


Client side:
Linux
This is the easy one simply add a -X flag to your ssh session

ssh -X yourserver

Windows
You will need only 2 things to acomplish this
1) SSH client that does remote X11 forwarding, I use putty
2) An X server, I prefer Xming (Cygwin can do this)

With Xming you will only need Xming and Xming fonts

At that point simply run Xming (it will work in the background quietly no prompts or other information) and make sure your putty session is configured as follows.


The enable x11 forwarding checkbox must be checked, at that point save your session or connect as is without saving it.






At this point you are good to go, any application you launch from the SSH session will launch locally


In my example here I launched iceweasel from my debian virtual, it is a simple example but possibly a useful one (IE trying to download a file or directory directly to your server but is on a site that uses JAVA to initiate a download instead of actually getting a URL for wget or links)

I also use it for tools like when I am network simulating with NS2 or want to use XChat or any number of a dozen tools that sometimes have windows ports sometimes not.


Conclusion:
Remote X11 forwarding is a useful tool in seamless administration between multiple linux and windows/linux environments and can get you access to your tools in a seamless way that can look act and feel like a local application on operating systems that may not have access to the tool directly (or with more difficulty)

I have seen quite a few partial or old processes for installing vmware tools for some of the vmware products but not for Debian and ESX. I would like to note that I am doing this step by step, there are of course shortcuts to the way I am doing this but I wish to explain it in simple steps so you can take away why I am doing these steps not just blindly following them.

1) Install the necessary tools



aptitude install autoconf automake binutils cpp gcc linux-headers-$(uname -r) make psmisc


2) From the console select the vmware tools install\upgrade




3) Make a directory to mount the cdrom device to

mkdir /mnt/cdrom

4) Mount the cdrom device to the directory you created for it

mount /dev/cdrom /mnt/cdrom

5) Navigate to the cd-rom directory


cd /mnt/cdrom


6) Copy the Vmware tools installer file to somewhere you can work with it, I choose my home directory (Note the name of the file WILL change as new versions come out, as it is the only file in the directory it will be easy for you to find the new name)


cp VMwareTools-4.0.0-164009.tar.gz ~


7) Untarball the file then change to the extracted directory

tar -xvzf VMwareTools-4.0.0-164009.tar.gz

cd vmware-tools-distrib/

8) Run the installer perl script

./vmware-install.pl


8)Follow the steps on screen, I have left all the defaults on mine
In the past you may have needed to specify things like your kernel header location or compiler or make locations, I did not need to assuming I followed step 1 to install the tools neede

I would also note I am NOT using a custom kernel I am using an almost fresh out of the box one, it may be that the steps vary if you do so (Though vmware installer is pretty good at just building the required modules all on its own)

Labels: Debian, Lenny, Vmware Tools, vsphere4