This post isn't about super-secret ssh sorcery, but a collection of frequently used and easily forgotten *ssh tricks. Mostly a reminder for myself.
SSH Public/Private Key Authentication
One of the neat features of
ssh is support for key-based authentication, which not only comes handy for automatically trigging remote scripts and such.
The basic idea is that you have a key identifying yourself (your private key) and a set of matching locks distributed to the machines you want to connect to (public key). No passwords or other user interaction is necessary to log into a remote box. And it's no problem if somebody gets control over your public key -- you can even put it on your website, if you like. But be sure to protect your private key, as it can easily open all the locks you distributed around the net.
Using public key authentication is pretty simple, as it is the preferred login method in default
sshd installations. You only need to create a pair of keys (public and private) and copy them to your remote machines.
The basic configuration on the client side just requires you to generate your public/private key pair. Only one public key is required, even if you're accessing multiple boxes.
ssh-keygen -t dsa
Make sure that your private key has the right permissions, especially if you copied it from a different machine.
chmod 600 .ssh/identity
Finished! You may also add a passphrase (an extra secure password) to that key. Otherwise anybody who has access to this key (stolen laptop, hacked machine, Debian) can easily gain access to all your remote boxes.
Append the freshly generated public key to the
.ssh/authorized_keys file on the remote box. Here's the long version:
ssh email@example.com # Login to the remote box Password: ******** # funny, I have the same password :) mkdir -m 0700 .ssh/ # create .ssh config directory exit # copy public key to remote machine scp ~/.ssh/id_dsa.pub firstname.lastname@example.org:.ssh/id_dsa.pub.localbox ssh email@example.com # relogin on remote site Password: ******** # last login with password # add to authorized_keys file cat .ssh/id_dsa.pub.localbox >> .ssh/authorized_keys
In many cases the short version also works:
scp ~/.ssh/id_dsa.pub firstname.lastname@example.org:.ssh/authorized_keys
Just make sure that the
.ssh/ directory exists on the remote box and that you append to the
authorized_keys file in case you have multiple private keys.
should now log you into the remote box without a password.
ssh can easily tunnel remote services through your secure connection (or local services to the remote site).
So in case you need to access a remote
mysql-database, just add an entry like this to your
.ssh/config (you can also add this as a parameter, but this soon gets messy):
Host database # "database" is the name for this entry Hostname database.example.com Compression yes # Trade bandwidth for latency User dbuser LocalForward 3306 localhost:3306
After logging into the remote machine with
ssh database connections to your local port 3306 are forwarded to port 3306 on the remote machine, thus connecting to
localhost:3306 on your local box will magically beam you to your remote site.
Funny things can be accomplished with this:
Need to access that intranet web-server? Try
LocalForward 80 intrawww.example.com:80 and connections to
localhost:80 on your local machine are tunneled over your ssh gateway machine to your intranet web-server.
You can also bind the local end of this tunnel to something different than
localhost, thus allowing everyone on your network to share the tunnel. A security hole can't get much bigger, but there may be cases were this might come handy.
You might also consider using
ssh as a local SOCKS server. Calling
ssh with the
-D 1234 parameter establishes a SOCKS server on port 1234 on your local machine that can be used with every SOCKS-aware application.
A simple backup solution
Of course you can combine
ssh and the powerful
rsync command to build a small online backup solution.
#!/bin/bash SOURCE=/Users/mylogin DESTINATION=example.com:/home/mylogin/ rsync -e 'ssh' -avz --progress --delete-after $SOURCE $DESTINATION
If public key authentication doesn't work for you (
ssh is asking for a password, although the keys are in place) make sure that the permissions to your home directory (
~/) and your
.ssh/ are correct:
chmod -R 700 ~/.ssh/ chmod 700 ~ # you may prefer 755 or 711