Useful things you can make SSH do | Hacker News Reader

Useful things you can make SSH do

derwiki.tumblr.com

214 pointsderwiki71 comments

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 .

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

Another config trick for multiplexing ssh connections into just one session:

  ControlMaster auto
  ControlPath ~/.ssh/master-%r@%h:%p

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.

If your intent is to hide what you're doing from your LAN/ISP, there is a snag with Firefox. It will leak DNS requests locally unless you go to about:config and set "network.proxy.socks_remote_dns" to "true"

Yes, its a useful trick I often use. However, does anyone know if Chromium or Opera can do the same DNS request tunnelling? (Firefox+Linux is sluggish for me.)

I'm pretty sure Chrome, at least, doesn't support SOCKS yet at all.

I was trying to make a shell script just the other day that would set up a SSH SOCKS proxy to a remote box and launch a browser using it, but couldn't do it from the command line in either Firefox or Chrome (didn't try a custom profile). Furthermore, I couldn't get it working in Chrome at all (shame; Firefox is more sluggish, and Opera won't even start on my box).

Chrome (under both Windows & Linux - not sure about OS X) can use SOCKS - I use it regularly.

I'm unsure how to make it do remote DNS look-ups though.

Opera cannot do SOCKS.

One problem with Chrome is that its proxy config interface really is just interfacing with the GNOME desktop-wide proxy settings. So it's impossible to have Chrome use multiple proxies or to only have one instance of Chrome use a proxy, but another instance not -- even if both instances have completely separate user data directories -- and all proxy changes are instantaneous across all Chrome instances. (At least for Chromium 5.0.391.0 on Linux)

Try the proxy switchy extension - it should at least make it very fast to switch proxies.

Yeah, I got it to work now, thanks to google. Hadn't realized that it needs a) a new session and b) an environment variable set.

  function remotebrowse() {
    export SOCKS_SERVER=localhost:5432
    ssh -fNTD 5432 remote
    google-chrome --user-data-dir=/tmp/chrome $1 &
  }

I get some error messages, but it seems to work.

Really? I just the the GUI to set it (Ubuntu 9.10, 10.04, Windows XP, Vista & 7)

I don't have a GUI (Xubuntu 9.10), and I don't want to set it permanently. Just so I can get at some ip-restricted content from home.

Chrome on OS X can use SOCKS, but not explicitly for Chrome, since the operating system manages the connections under System Preferences > Network > Advanced > Proxies.

Using this method, will OS/X use the remote machine for DNS lookups or my ISP?

Even better, run the SSH server on port 443. Then you'll be able to tunnel though most corporate firewalls.

Even better: Use SSLH[1], so you can still have an HTTPS server, but also connect to ssh on port 443. Set it up myself and my boss still doesn't know.. :)

[1]: http://www.rutschle.net/tech/sslh.shtml

i do it every day, works out easier for the IT dept then configing the network for ppl like me... but if you are not on good terms with the IT dept its a good way to lose your job, tread carefully.

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.

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.

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.

Thanks. so it's for a private proxy.

Basically, you are sending and receiving all of your web traffic through an encrypted connection to a remote computer.

A typical use for this is when you are connected to a foreign network like a hotel. If you don't route your http traffic over ssh, there is a risk of having your traffic sniffed and/or recorded.

You could also (theoretically, haven't tested it all):

- watch Hulu, when you're not in the US

- use Spotify when you are in the US (and you use a UK box for example)

- bypass your university firewall

- in general secure your connection in case you are using an open network

Actually I'm pretty sure the Adobe Flash plugin will ignore your proxy settings, so it will only work with actual web sites.

This isn't true - I use a proxy tunnel frequently, and Flash works fine.

Flash works but it uses the default system connection and not your browsers proxy connection. So in cases of site that have IP based restriction, flash based sites will still see your original IP

and how do you know about this ? I use the very same trick with youtube and many other flash based sites. And flash ALWAYS use the browser's settings (at least in opera and firefox) both in Windows and Ubuntu

Launch your browser using tsocks.

ssh tunnels work great for hulu and netflix when travelling abroad. Or so I've heard :)

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.

That gives you tab completion, too!

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

    diff <(ssh user@host cat remote-filename) local-filename

is a bit more intuitive too. You can put anything that writes to stdout in the <(), too. (Useful for decrypting or decompressing on the fly.)

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

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

This is especially useful when dealing with directories with too many files in them - say around a million files. Regular globbing won't work, and most regular tools won't work - but tar works great.

Also - another trick is to give it -c blowfish to use a lighter/faster cipher for the transfer to save on CPU time.

Ssh already compresses, so you can drop the z. And generally cpio does a better job preserving the file system structure (hard links, time stamps). And it tends to be a bit more cross-platform, if you don't have GNU tar on both ends.

ssh(1) only compresses if configured too, see the -C option.

You can also just transfer it with:

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

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.

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

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.

scp is a lot slower than the tar-pipe with many small files.

hah! the dsp trick actually works surprisingly well IF you combine it with lame (iirc).

yeah the quality is going to be terrible and your going to hear a lot hissing but it will work!

Back in college we did something similar, but much less technologically advanced, to a roommate's linux box that he hooked up to speakers.

We found a lot of fun sounds to blast at him while he slept. :)

might want to try esd instead. When I was looking to try networking sound for a thin client thats the closest I got.

Pulseaudio is perfect for this nowadays. A bit more modern than esd, I'd say.

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.

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.)

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.

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

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.

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

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.

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.

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

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).

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

Have you tried

    ssh -T foo bash -i

  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)

Making a VPN over ssh using a 10.0.0.0 address:

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

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.

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.

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.

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.

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).

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

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.

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.

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).

Reply on news.ycombinator.com