SSH

Handy SSH Tricks

SSH File System (SSHFS)

SSHFS (http://www.linuxjournal.com/article/8904) allows you to mount remote directories and see them/treat them as local directories. It comes built-in to pretty much any Unix or Linux distro, but unfortunately it doesn't come stock on a Mac.

If you want to use SSHFS on a Mac, you need to install MacFUSE: https://code.google.com/p/macfuse/

And if you want a nice GUI for MacFUSE, you can install MacFusion: http://www.macfusionapp.org/

SSH Tunnels

SSH can be used to create tunnels between ports on two computers. This comes in handy if, for example, you want to use a protocol that shares information between two computers, but the protocol is completely and hopelessly insecure. A perfect example is file sharing, or remote desktop sharing. Another situation where this comes in handy is if you're trying to run a service (like the above) through a computer that has a firewall blocking most ports. It is possible to route traffic to a port on your local machine, which won't have a firewall issue, through the SSH port (port 22).

An SSH tunnel works like this: normally, two computers would communicate to each other. Machine A, acting as the server, would open a port, perhaps port 4000, and Machine B would connect to port 4000 of Machine A to send and receive information. However, if the connection between Machine A and Machine B is not encrypted, someone could sit on the network and see everything that's passing between Machine A and Machine B.

Alternatively, MachineB can create an encrypted SSH tunnel between itself and MachineA. The power of SSH tunnels is, they can be made between any ports. So MachineB can create an SSH tunnel that forwards all information coming from port 4000 on MachineA through the encrypted tunnel to port 4000 on the local machine. Or, it could forward all information to port 4001 on the local machine, or port 5000 on the local machine - you get the idea.

To create a tunnel from port XXXX on MachineA to port YYYY on MachineB,

[MachineB] $ ssh -L XXXX:localhost:YYYY user@MachineA.com

The SSH tunnel will stay alive for as long as this SSH session remains open. If you don't want to have to keep this window open, you can create the SSH tunnel and run it in the background:

[MachineB] $ ssh -L XXXX:localhost:YYYY -f -N user@MachineA.com

The -f argument runs SSH in the background, and -N runs no commands.

Killing Background SSH Tunnels

You can kill all those background SSH tunnels and other SSH processes cluttering up your list of running programs by running the command:

$ ps -A | /bin/grep ssh

Then you can either run

$ kill -9 <PID>

or the slightly easier

$ killall <PROCESS NAME>

Tunneling AFP over SSH

AFP, or Apple File Protocol, is the built-in filesharing protocol on Mac. AFP uses port 548, but you can actually forward AFP to any port number you want. So, if you're already using AFP from another Mac (through an SSH tunnel, right?), and port 548 is already occupied, that's OK - you can tunnel the new AFP connection through port 549, or 550, or... whatever.

If you want to take an AFP-shared directory that is on MachineA port 548, and mount it/see it on MachineB (just for kicks) port 15548, you'll do the following:

[MachineB] $ ssh -L 548:localhost:15548 -f -N user@MachineA.com

Then you can mount the (now LOCAL) AFP directory:

$ mount afp://localhost:15548 /Volumes/AFP_DRIVE

Tunneling Remote Desktop Connections over SSH

Since remote desktop shares such valuable information (i.e. graphical interaction plus complete remote control over the computer, plus viewing any sensitive information), it is important to take necessary security measures. One such measure is tunneling the remote desktop connection through an [SSH]] tunnel, encrypting all remote desktop traffic. This can be done as described on the [SSH]] page, using the command (run from the client computer):

ssh -f -N -L 5900:localhost:5900 server_username@server.com

One of the problems with tunneling the remote desktop connection through an SSH tunnel is that it's very slow. The reason for this is, SSH is encrypting all outgoing traffic and decrypting all incoming traffic - a time-consuming and slow process, added to the fact that remote desktop is sending and receiving a large amount of information. This makes the response time and graphics quality of remote desktop windows very poor.

SSH can be tweaked, however, to use a faster (albeit less secure) cipher called Arcfour (see wikipedia:RC4 for details). This is done by using the -c flag for the SSH command:

ssh -c arcfour -f -N -L 5900:localhost:5900 server_username@server.com

If you run the command man ssh you can see all of the different options you have for the -c flag. Arcfour is almost assured to be the fastest.

Cypher Selection

As mentioned in the above section, sometimes you want to use a faster and less secure cypher; other times you want to trade speed for higher security. The -c flag allows you to select the cypher used by SSH. From the ssh man page:

     -c cipher_spec
             Selects the cipher specification for encrypting the session.

             Protocol version 1 allows specification of a single cipher.  The sup-
             ported values are ``3des'', ``blowfish'', and ``des''.  3des (triple-
             des) is an encrypt-decrypt-encrypt triple with three different keys.
             It is believed to be secure.  blowfish is a fast block cipher; it
             appears very secure and is much faster than 3des.  des is only sup-
             ported in the ssh client for interoperability with legacy protocol 1
             implementations that do not support the 3des cipher.  Its use is
             strongly discouraged due to cryptographic weaknesses.  The default is
             ``3des''.

             For protocol version 2, cipher_spec is a comma-separated list of
             ciphers listed in order of preference.  The supported ciphers are:
             3des-cbc, aes128-cbc, aes192-cbc, aes256-cbc, aes128-ctr, aes192-ctr,
             aes256-ctr, arcfour128, arcfour256, arcfour, blowfish-cbc, and
             cast128-cbc.  The default is:

                   aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,
                   arcfour256,arcfour,aes192-cbc,aes256-cbc,aes128-ctr,
                   aes192-ctr,aes256-ctr

Unless you're using an ancient version of SSH, you'll be using version 2 (if you're not, you need to be, because version 1 has security flaws! For example, see http://nmap.org/movies.html, The Matrix Reloaded section, and http://packetstormsecurity.org/advisories/bindview/adv_ssh1crc.txt for more information).

Passwordless Login

These instructions will enable you to log in to MachineB from MachineA without entering your password.

DO THIS STEP ONCE:

Generate a public and private key. Use the DSA encryption algorithm. To do this, execute the command:

[MachineA] $ ssh-keygen -t dsa

You'll be prompted for a passphrase that must be entered every time you use your public key. This operation will create two files, ~/.ssh/{id_dsa,id_dsa.pub}.

The file id_dsa is your private key - DO NOT SHARE YOUR PRIVATE KEY WITH ANYONE!

Now remote-login to MachineB and paste the public key for MachineA into MachineB's list of authorized keys:

[MachineB] $ vi ~/.ssh/authorized_keys

and paste the contents of MachineA's public key.

END OF DO THIS STEP ONCE.

To login to MachineB from MachineA without entering your password, perform the following steps:

[MachineA] $ ssh-agent   # <-- copy and paste the output of this command into a terminal;
                         #      this will set 2 environmental variables
[MachineA] $ ssh-add

You will be prompted for your public key passphrase once per session, and once you enter it, you will have passwordless access to MachineB from MachineA.

These steps are somewhat cumbersome, and can be shortened to a much more convenient bash function as follows. I want to create a bash function on MachineA so that when I type:

[MachineA] $ MachineB

I will instantaneously be logged in to MachineB. To do this, I will create a function in my ~/.bashrc (or somewhere similar, I use a ~/.aliases file). This will look as follows:

alias MachineB="MachineB"
function MachineB() {
  # put environmental variables in ssh.file
  ssh-agent > ~/ssh.file

  # execute this file, sending output to /dev/null
  chmod +x ~/ssh.file
  ~/ssh.file > /dev/null
#  echo $SSH_AGENT_PID
#  echo $SSH_AUTH_SOCK
  rm -f ~/ssh.file

  # ssh to MachineB
  ssh -Y user@MachineB.com
}

Voila!

References

Tunneling AFP through SSH - http://hea-www.harvard.edu/~fine/OSX/afp_tunneling.html

wikipedia:Apple Filing Protocol

How to create a self signed certificate - http://www.akadia.com/services/ssh_test_certificate.html