network copy with ssh and tar

You can use ssh in conjunction with tar to pull an entire directory tree from a remote machine into your current directory:

ssh tar cf - -C . | tar xvf - 

For example, let's say you have a "bsmith" account on a host called "apple". You want to copy those files into your "bobsmith" account on a host called "pear". You'd log into your "bobsmith@pear" account and type the following:

ssh bsmith@apple tar cf - -C /home/bsmith . | tar xvf - 

This technique is useful when you have insufficient disk space on the source machine to make an intermediate tarball

Import ssh host keys without verification

Automatically import host keys for cluster of machines named 'all'

Using the 'dsh' command from the clusterit tools - http://sourceforge.net/projects/clusterit

RCMD_CMD_ARGS='-o VerifyHostKeyDNS=yes -o StrictHostKeyChecking=no' dsh -g all -e true

Remote Window Managers

Lots of times it’s extremely frustrating or time consuming to run an xterm on a remote host just to fork your programs from that remote machine. Why not just run your window manager there even though you’re not on its console? The window manager is just another X application, after all, isn’t it?

Fire off your local X server

xinit /usr/bin/xterm — :1 &

yields a vanilla X session with merely an xterm running - no window manager. Now you need to add permissions to this window session for the remote host. You can tunnel the connection through SSH if your network is insecure but there’s a distinct performance hit. If your network is secure, you can just “xhost +remotehost” and spray directly to your X server:

Tunneled SSH:

ssh -fY remotehost /usr/bin/wmaker

or spray directly:

xhost +remotehost
ssh -f remotehost /usr/bin/wmaker -display localmachine:1

The first option, if your remote SSH server supports it, will use a locally defined DISPLAY that then gets tunneled to your local side over SSH. The second option allows remotehost to send X data directly to your local display, then runs WindowMaker there but displaying it locally. Now all your desktop actions are done on the remote machine, not locally.

Bypass firewalls using ssh

Ever wanted to access a service behind a firewall that has port 22 open for ssh connections? This is a common setup known as using a jump-box for security access and to be successful at this we your firewall must allow port 22 traffic to your ssh jump-box. We can test our if port 22 is open by typing the following line.

telnet ssh-jump-box 22

If all is good then we should see something like

Trying 192.168.1.200...
Connected to ssh-jump-box.
Escape character is '^]'.
SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1.2


In this example we’re going to create a tunnel for port 3389 windows rdekstop and we’ll begin by creating a local loopback port 3390 that ssh will tunnel from myMachine to myFireWalledMachine on port 3389

ssh -L 3390:server-behindFirewall:3389 user@ssh-jumpbox -N

Now we can access the service on port 3389 that was previously inaccessible through the firewall by pointing our connection to the local loopback port we just created through ssh. In this case we\’ll use rdesktop to hit that port as we are trying to remote desktop to a firewalled machine.

rdesktop localhost:3390