
Useful things you can make SSH do - derwiki
http://derwiki.tumblr.com/post/841579929/how-i-learned-to-stop-worrying-and-love-ssh
======
novas0x2a
My favorite trick (in .ssh/config):

    
    
      Host *.internal.workdomain.com
      ProxyCommand ssh gateway.workdomain.com nc %h 22
      ForwardAgent yes
      User <username>
    

Then you can type

    
    
      ssh bender.internal.workdomain.com
    

and ssh will automatically connect through the gateway to the (normally
inaccessible) internal node. ForwardAgent will pass the credentials through.
(If you copy this blindly, note that this requires netcat). This configuration
lets you pretend (to tools like scp, rsync-over-ssh, etc) that you have direct
access to the machine in question, even when it goes through a gateway
machine:

    
    
      scp config bender.internal.workdomain.com:
      scp bender.internal.workdomain.com:logfile .

~~~
nuclear_eclipse
Similarly, Corkscrew allows you to do the same thing, but with an HTTP proxy
like Squid:

    
    
        Host foo
          ProxyCommand corkscrew proxy.domain 3128 %h %p

------
herrherr
My personal favourite:

\- Get a cheap development box (Linode, Slicehost, etc.)

\- Set Firefox to use Socks Host 127.0.0.1:8080

\- Open up your terminal and enter this: ssh -C2qTnN -D 8080 your-
user@example.com

Et voilà, you're tunneling all your browser traffic through the development
box.

~~~
igravious
I'm not sure what you're aiming at here. Could someone explain in plain
English what's happening here and why this might be useful? Thanks.

~~~
nl
As others have mentioned, it allows you to use a remote box as a SOCKS proxy,
so your browsing traffic originates from there and is encrypted on the local
network.

This is useful when the local network is untrusted, or to bypass things like
url blocklists or IP filtering.

The arguments are as follows:

ssh -C2qTnN -D 8080 your-user@example.com

C2: request compression, at level 2 (1 is least)

q: quite mode

T: Disable pseudo-tty allocation. I don't know why you would want this. I
suspect since you are only using it for a proxy you don't really need a tty,
but seems a little unnecessary to me.

n: redirect stdin from /dev/null. Again, not sure why this is needed, but I
suspect it is related to the "T" option.

N: Do not execute a remote command. You are only using port forwarding so no
commands are needed.

-D 8080: the local port to forward

your-user@example.com: Username/host of remote machine.

This is a pretty optimized example. The simplest working version is just _ssh
-D 8080 your-user@example.com_. Personally, I'd use the _-C2_ argument as
well, but leave the rest out.

~~~
sesqu
According to my manpage, C is for compression and 2 is for SSH2. You'd need to
use -o to set the compression level, and then you'd probably also want to make
sure compression actually helps (manpage warns against it).

Similarly, -n is described as necessary for backgrounding the process, if you
want to. I can't find a reason to use -T, unless you intend to send binary
data over the pipe.

------
mjschultz
One of the biggest 'ah-ha' moments I had with SSH was that I could create my
own hosts with certain properties. For example, if I wanted a backup server
with a special user and key I could add it to my ~/.ssh/config file

    
    
      Host backup-server
          HostName backup.example.com
          User backup
          IdentityFile ~/.ssh/backup_dsa
    

Then just have a shell script run

    
    
      $ ssh backup-server
    

It ended up working really well.

Also, control sockets.

~~~
mcantor
That gives you tab completion, too!

------
p3ll0n
Two more that come to my mind ...

1\. Comparing local and remote files

$ ssh user@123.4.5.6 "cat /tmp/remotefile" | diff - /tmp/localfile

2\. Outputting your microphone to a remote computer's speaker

dd if=/dev/dsp | ssh -c arcfour -C username@host dd of=/dev/dsp

~~~
mjschultz
Along the same lines as number 1. You can transfer a directory with

    
    
      $ ssh user@host "tar cvzf - /path" | tar xvzf - /path

~~~
daten
You can also just transfer it with:

$ scp -r user@host:/path /path

~~~
mjschultz
I usually do use scp, but it becomes problematic when there are symlinks
hanging around. scp just follows them and ends up copying the same file many
times.

This is especially bad if you have a directory structure that references a
higher-level directory.

~~~
pornel
Use rsync then. It can copy symlinks and even recreate hardlinks.

~~~
jerf
In my experience, using rsync to do just a raw copy is not faster than the
ssh+tar approach. rsync wants to poke around and optimize, and that's
incredibly awesome, except when there is absolutely no chance of optimizing at
all, in which case it's just dead weight. I don't know of anything that can
beat ssh+tar (possibly with the encryption tuned cheaper, as mentioned above);
it especially blows raw scp out of the water for lots of small files.

------
jerf
Check 'man ssh' for escape characters, including for how to terminate an SSH
session when the remote is not responding. Check 'man sshd' for the
AUTHORIZED_KEYS FILE FORMAT section. I call particular attention to the
"command='command'" option, which allows you to set up an SSH key in such a
way that it can only be used to run a particular command. Of course the key is
only as secure as the command, but that's a great start. I use it for when I
want to cron a job where one server has to talk to another to do something as
some privileged user, and of course can't enter a password then, but I don't
want the key to grant full login privs as that user.

------
cypherdog
This one is simple, but I like it. Use -X command to launch a local x11
session for a given remote application. Works for Linux and OSX machines with
x11 installed.

>ssh -X user@remoteserver.com will connect you. >gedit file.txt

will launch a remote instance (viewable locally) of gedit with the remote
file.txt loaded and ready for editing. Especially good for those who don't
like command line editors (note: gedit must be installed on the remote machine
for the example to work.)

~~~
derwiki
This is a neat trick, and I've used it a lot -- but worth pointing out that
this should really only be done over a local network. X11 apps tend to be VERY
chatty, and very slow when forwarded over the internet. I'd recommend VNC or
FreeNX to do remote X11 apps over the internet.

~~~
cypherdog
I absolutely agree. I work primarily on an local network at my work, so I
don't often think about it.

------
ww520
My favorite trick with SSH is running Tramp mode in Emacs to do editing on
remote servers, invaluable when accessing isolated servers in data center via
a jump-box server from my local machine. The fun part is the multi-host jump
to editing files on a server that is couple hops away, like jumping through
multiple data centers.

I usually bookmarks the Tramp sessions of the frequently visited servers to
avoid retyping the host url and logon setting.

~~~
kaens
The only gripe I have with tramp is that it seems to have an awful lot of
network overhead.

------
dododo
want to log in without appearing in lastlog(8)/w(1)/who(1)?

ssh -T host

(of course syslog still sees you).

if available, ssh-copy-id(1) is an easier way of setting up passwordless
ssh(1).

note also that openssh supports on-demand proxying via SOCKS4/5: check out ssh
-D. this makes it easy to pipe all web traffic (for example) over ssh.

~~~
sabat
Er, yeah, -T will work, but of course you don't get an interactive shell.
Works for one-off cmds or for running a shell script or something.

~~~
dododo
you should try. all -T does is not allocate a tty: most shells will still
work. bash/zsh/rc do for sure.

~~~
sabat
Actually, I did try it, thinking that I may have misunderstood it for all this
time. But no shell for me (Centos 5.5, bash).

~~~
dododo
it won't give you a prompt: try typing something, and you'll see it works fine
(unless centos have done something funny).

~~~
ralph
Have you tried

    
    
        ssh -T foo bash -i

------
surki

      Got a computer behind a firewall whose configuration 
      you don’t have access to? It’s pretty easy to get the 
      computer behind the firewall to poke out to another 
      server.
    
      (step 1, from the computer you wish to access)
      derwiki@firewalledcomputer:~$ ssh -R   localhost:2002:localhost:22 mypublicserver.com
    
      (step 2, from any computer than can access  
       mypublicserver.com)
      derwiki@mylaptopontheinternet:~$ ssh mypublicserver.com -p 2002
      (authenticate)
      derwiki@firewalledcomputer:~$
    

If you want to keep it running always, you may want to consider "autossh"
(restarts ssh connections if they ever exit/disconnect)

------
afhof
Making a VPN over ssh using a 10.0.0.0 address:

<http://bodhizazen.net/Tutorials/VPN-Over-SSH/>

------
bacarter
It's important to encrypt your private key with a passphrase. Use ssh-agent to
store the un-encrypted key in memory on login. On OSX 10.5 or greater, this is
really easy: <http://bit.ly/alDMhp>. Make sure to add 'ForwardAgent Yes' to
your ssh config, and then never have to type your ssh password again.

~~~
LiveTheDream
It is almost as bad to have your passphrase-protected key permanently stored
in ssh-agent, because anyone with access to your machine can use the key
without the passphrase. A better solution is to use ssh-agent with the -t
option to establish a lifetime (after which you will need to re-enter the
passphrase).

My setup is to keep ssh-agent running with a 2-hour lifespan, and connect to
that automatically when I log in. Basically this:

    
    
        $ ssh-agent -t 7200 > ~/.ssh-agent
        $ echo "source ~/.ssh-agent" >> ~/.bash_profile
        $ [... log in ...]
        $ ssh-add
    

I am not annoyed by re-entering my passphrase every two hours.

~~~
evaryont
This. The parent's idea is similar to storing the user's password forever in
memory for sudo. As any ol' neckbeard could tell you, that's a Bad Thing.

------
_pi
I'm just gonna say this, NEVER have SSH keys without a password and say it's a
secure way for a passwordless logon. It's unsecure and your keys can get used
against you. Giving your key a strong password and using ssh-agent and ssh-add
will give you passwordless logons and the benefit of security.

------
Groxx
This could _really_ use an explanation of what the arguments are doing. It's
just a list of ingredients, not a _recipe_ ; very little can be learned from
this list (though it may _inspire_ learning).

~~~
enneff
Is "man ssh" really that hard? Is it necessary to reproduce the excellent
documentation that already exists?

~~~
Groxx
Not hard, no. And expectable, yes.

But by the same token though, why document any code? It executes the same no
matter what comments are around it, and all the underlying operations are well
documented.

~~~
spekode_
These aren't lists of ingredients, they are recipes. A typical problem with
man pages is that they list the ingredients but don't give you any useful
recipes. Some have an 'Examples' section but most don't. These are recipes:
ingredients and parameters for them, and a short explanation of what you're
going to get. Makes sense to me.

------
sabat
He left off the use of proxytunnel, which lets you tunnel SSH through an
HTTP/S proxy, even if it requires authentication:

<http://proxytunnel.sourceforge.net/usage.php>

Also, as others have mentioned, -D is pretty useful (SOCKS proxy).

