SSH Tunnels How-to?
The_Spider asks: "I periodically browse the net and check web-mail at work, when I have the opportunity. I was wondering if anyone had a nice walkthrough on how to set-up an SSH tunnel. I'm not 100% newbish to Linux but I don't know where to start. (I have a Fedora Core box at home for NAT & DHCP) I'm hoping to combine this for use with portable Firefox. I'm not to worried about security, but I love the notion of taking a portable and encrypted browser with me from place to place. Can Slashdot help?" While this might be a bit FAQ, I figure Slashdot anecdotes on the use of SSH tunnels might be a bit more user-friendly than say, the several task-specific HOWTOs one can find via a Google search. ALso, I'm sure that there are a few of you out there who have discovered interesting ways of using SSH tunnels, not covered by said HOWTOs. So, how are you using SSH tunnels, and can you explain them to those who have not yet discovered the value of their use?
The PuTTY win32 client documentation can be found here. It has a good intro to SSH as well.
Religion for nerds. Stuff that really matters
This doesn't really address the author's original inquiry, but it is (what I would consider) an interesting use of SSH tunnels, in a readable tutorial. I set up something similar to "GoToMyPC" for my Dad, that allows web-based (over JavaVNC) secure remote access to his computers:
Java VNC over SSH
Got one of those on my website.
p hp
Enjoy http://www.linuxlogin.com/linux/admin/sshtunnels.
Spider is an employer that wants to block SSH tunnel access for his employees, but he has no idea how to pull it off, so he concocted this excuse about wanting to use our beloved Firefox.
:-)
I think we can all collectively say: Spider, go RFTM.
(Yes, the man page for ssh covers this in detail.)
-= End of thread =-
It's nice and short, but covers the basics.
Best regards, A.C.
I *really* hope my employer doesn't recognize my Slashdot ID. :)
I use an SSH tunnel to forward port 8080 on my desktop machine here at work to port 8080 on my Unix workstation at home that's running an HTTP proxy. I set my Firefox/Mozilla at work to use localhost as its proxy, and I now happily bypass any and all logging and/or site restrictions on my work browsing habits.
I also remote-forward a pseudo-random high port on that remote workstation at home to port 22 on my work desktop machine, giving me the ability to SSH *back in* to work from home, and not monkey with the company's VPN solution that has a client for my home machine that's so buggy it's unreal. That remote SSH call-back also forwards the home machine's IMAP port to the company's Exchange Server so I can read my email over the tunnel, and I port-forward to our network monitoring and backup systems' web interfaces so I can actually do my job.
I guess I can say that my productivity from home would be pretty much zippo if I didn't have SSH tunnels at my disposal.
"I feel that if a person can't communicate, the very least he can do is to shut up." -- Tom Lehrer
1. Set up usual SSH session settings in Putty
2. Go to Connection -> SSH -> Tunnels
3. Add new forwarded port. Source Port: 1080, Destination: [blank], DYNAMIC (this is important), Auto. Click on Add.
4. In Firefox or any other program that supports a SOCKS proxy, enter host 127.0.0.1 (localhost) with port 1080.
That's it. You'll then be using your SSH connection like a SOCKS proxy.
Here's how I do it.
:localhost:80 host.your.domain
ssh -CX user@host.your.domain
password:
user@host$ konqueror&
Or do you want to portforward your browsing?
After setting up a proxy server like squid on your home machine...
ssh -L 8080
This Ask Slashdot really should be answered with RTFM or Google!
the Internet Security Center at sans.org had an interesting article about getting ready for defcon.. (in order to protect your privacy) While it does not go into very detailed how-to's, it does give a hell of a parnoid BOFH type mindset for defcon. There are some basic guidlines for secure connections using tunneling over SSL in that discussion..
What are we going to do tonight Brain?
Some time ago I wrote a little guide on SSH tunnels with PuTTY.
This guide also describes how to setup an SSH tunnel in Linux.
thomasdamgaard.dk.
Check out SSL Explorer. It has a windows and linux installer, is easy to use, and is java based, so the client runs pretty much everywhere.
(stolen from DaBum) I am dyslexia of borg - your ass will be laminated.
We use this actual script (plus a few things I had to edit out for anonymity's sake).
.profile. Remember, this is a private link, so you'll probably want local and remote to be internal addresses, i.e. 192.168.x.x.
Assuming a Linux machine at each end, here's the script for the machine that initiates the connection:
while true; do
pppd nodetach lcp-echo-failure 4 lcp-echo-interval 120 \
pty 'ssh receiver -T -l user'
sleep 10
done
Where receiver is the public IP address of your receiving machine and user is the username on that machine. The while loop automatically reconnects if you get disconnected.
Here's the script for the machine that receives the connection:
pids=`ps -e -opid,command | grep "pppd local:remote" | \
grep -v grep | awk '{print $1}'`
if [ "$pids" != "" ]; then
echo "Found pre-existing connection. Killing pids: $pids" >> ppp.log
kill -15 $pids
sleep 5
fi
pppd local:remote netmask 255.255.255.252 passive \
notty nodetach
Where local is the local end of your PPP link and remote is the remote end of your PPP link. You'll want to call this script from user's
Sit, Ubuntu, sit. Good dog.
Setup squid on your linux box, listening e.g. on port 3128. Verify that this is working by setting your browser to use it.
To get the tunnel working, I forget the exact settings in putty but there's a section for tunnels, tell it to create tunnel from local port 8128 to remote machine's port 3128. Then set your browser to use "localhost:8128" as your proxy.
The way to setup a tunnel between two Unix boxes (for me) is ssh -L 8128:192.168.0.1:3128 remote-host.
rooooar
I'm just guessing, but wouldn't ssh tunnels be readily identifiable if a smart network admin wanted to look for them?
h oo.com/
I'd like to run to a web-proxy at home that I can just point my browser to ala:
https://mycablemodem.cable.net:4567/
that will then access any website and rewrite any internal links to go back through the proxy itself, so for example:
http://www.yahoo.com/ becomes https://mycablemodem.cable.net:4567/http://www.ya
Anyone got a good, robust re-writing proxy tool like that? Preferrably with at least some sort of minimal security to prevent joe-random from using it without a login/password.
Second time I've posted my guide this week.
clicky.
"Better to be vulgar than non-existent" -Bev Henson
We're almost all linux at work, but have a handful of Windows systems, including a server. At home, I'm all Linux. I don't want to run VNC at work, because I don't really need all my desktop stuff at home, I just need to monitor a handful of web pages that monitor the network or access web interfaces that control things. So I tunnel several ports locally at home to those web servers. That way at home I just use a URL like "http://localhost:6809/nagios/" to access the bagios server at work running on whatever port it's on.
I also tunnel a port to port 3389 on the Windows server. That way something like "rdesktop localhost:23389" gives me a remote desktop to the server at work so I can maintain that server frmo home as easily as I do the *nix servers via the command line.
http://souptonuts.sourceforge.net/sshtips.htm
Really good for the beginner - includes information on accessing Samba shares over ssh.
I work in a large telco who's security policy is to restrict everything unless explicitly allowed, and the process to get anything allowed is a 3 month long waste of time.
h tml) but as nothing else but ssh is allowed out of the firewall at work, I don't have a lot of choice.
I also have an ssh tunnel established from my work PC to my home connection, and I run pppd over that to create a VPN between my home network and the network at work. I realise that this is probably completely against company policy, but the "official" VPN solution only lets me hit the Exchange server, and doesn't let me actually do any work. Most of the company's "work" involves forwarding emails, so it's probably fine for them.
Unfortunately tcp over tcp is really quite nasty (http://sites.inka.de/sites/bigred/devel/tcp-tcp.
A howto that I found quite helpful is at http://www.tldp.org/HOWTO/ppp-ssh/
Anyway.. on to my anecdote (not required reading):
Part of my job involves working on a distributed monitoring system which is deployed in a star topography around the country. All the remote sites send & receive data from one central site (with one redundant central site) using a variety of protocols, like ssh, xmlrpc, dns, telnet, snmp, syslog, etc.
The network was designed by people who were given a set of instructions like "You will use these 2 vendor's systems" and "You must follow these corporate security policies which were written 10 years ago for phone networks", so it's terrible by today's standards (and for an ISP in general).
There are firewalls between all of my boxes, even though all my boxes are on the management lan, and they only allow a very small set of protocols through - not enough to let my software work. That wasn't the worst part. The worst was that the firewalls are also protecting the billing network so have very low tolerances for intrusion detection and flood protection and such. Basically I can only establish 5 connections per second *across the entire network*. This is clearly not enough for a busy monitoring system. So we decided to build a VPN between all of my boxes using ppp on ssh tunnels.
I now have a separate ppp interface from the central server to each of the remote datacenter servers, all on the 10.0.0.0/16 network. ip forwarding is enabled on the central site, so now remote datacenters can talk to each other (also blocked by the firewalls) and I can use all the connections I need to. I'm running quagga ( http://www.quagga.net/ ) on every remote datacenter and the central servers (along with the redundant one) so I can distribute routes to remote datacenter devices and cope with the death of one of the central servers without major service interruption.
However it really is quite slow. I can only get around 200kb/s over each ppp interface even though the physical links are 100+mbit each. But I really don't need huge bandwidth, just some that isn't firewalled.
This "solution" has been in production for 6 months now, and I'm sure as soon as the corporate security people find out they will shut it down and I'll go back to not being able to do my job.
Anything is possible, except skiing through revolving doors.
There are some cute tricks in O'reilly's "Linux Server Hacks" which, taken together, can leave you with a pretty sweet setup. #52,#53,#66-#71 are all worth checking out.
--MarkusQ
I'm assuming you're on a Windows box. PuTTY's dynamic tunneling mode is the absolute easiest way to tunnel your traffic: it doesn't require setting up a proxy server on the remote system! All you need is an sshd on a server somewhere that allows tunnels. When using dynamic tunneling, PuTTY acts as a local SOCKS proxy. So, just set your browser and other net apps to use a SOCKS proxy on localhost on the port you specify in PuTTY, and you're good to go.
Here's how to do it, using the latest PuTTY and Firefox versions:
1. Configure PuTTY. Start PuTTY and put in the address of your host server to connect to on the first screen. In the menu on the left, pick 'Tunnels' from the tree. Under 'Add new forwarded port:' put in 1080 (this is pretty arbitrary, but 1080 is the "official" SOCKS port). Leave 'Destination' blank and choose the 'Dynamic' radio button. Feel free to go back to the 'Session' entry on the menu tree on the left if you wish to save a session so you don't have to do this every time.
2. Configure Firefox. Under Preferences, click the 'Connection Settings' button from the main 'General' options. Click 'Manual Proxy configuration:' and under 'SOCKS Host' put in localhost with port 1080. Click OK and try to surf. You should now be being routed through your Linux host. You can go to whatismyip.com to verify you're being routed through your host's IP address.
(I'm pasting this howto from one I wrote on another site)
Another trick to get through corporate firewalls is to place your SSH server at home on port 443 - the HTTPS port.
Since both SSH and HTTPS use SSL, it is very hard for a corporate firewall to tell the difference, so often you can punch through in this way if your employer does not allow you to SSH out on the normal port.
Of course, by doing so you may be violating your company policies and opening yourself up to being fired - so don't blame me if you are.
Also, if you want to keep the script kiddies from trying to brute force your SSH server, run it on a non-standard port (to protect it from scripts) and turn OFF password authentication - force the use of a keypair to log in.
That last bit is important, so I will repeat it:
Turn OFF password authentication - force the use of a keypair to log in.
I'd've made that ALL CAPS if the lame filter (err, lameNESS filter) had let me.
Using a non-standard port is no subsitute for actually SECURING the server, but it does play a role in keeping the RiffRaff out - and after what Riff did to Frankie I don't want him in here.
(Posted anon since several people at work read Slashdot.)
I second that. That's how I figured them out, and I do in fact find them very useful nearly every day.
I most often use them to tunnel ports from behind a firewall, such as tunneling 5900 for VNC to use VNC from school. Or, even X11 tunneling is very useful.
Really people, rtfm. It's not that hard.
I need a sig.
Install cygwin with the X server. log in to your box at home with ssh -X user@host and use the firefox version you have on the box there. you could pretty much work off any box with that setup.
Supplies!
You might also look into stunnel. It acts more like a traditional daemon with conf file, and also has the neat feature of being able to turn any service into its standard ssl equivilent, if that exists, which is useful for things like imap/pop/http.
And if you have occasional problems with ssh sessions being interrupted, use autossh (which requires keys to work properly - and that's a good thing).
One question that has always been in the back of my mind, but I have never bothered to actually hook up a packet sniffer and watch, what about DNS queries?
Most corporations have internal DNS servers, that they could certainly log your suspicious requests (or even hijack and re-route) to various nefarious sites. Does Firefox (Mozilla) route the DNS requests through the tunnel as well somehow? I thought SSH could only do TCP forwarding, so I seem to be missing something. Unless somehow the SOCKS proxy is doing the requests on the other end of the tunnel and brining them back.
Anyone actually sniffed the traffic to see if DNS is still vulnerable to corporate annoyances?
To do the same with the command line OpenSSH client:
ssh -N -f -D 1080
-D 1080 does the dynamic socks forwarding.
-N says don't run any command on the remote machine
-f says go into the background after asking for password
Works great for Yahoo IM; haven't tested others.
I too have followed the putty-as-socks-proxy route described by others.
For enabling stuff like iTunes, which doesn't know from SOCKS, try SocksCap.
Finally, I used to have a filter on my work machine's Outlook that would run a program when a message with a particular subject came in from me--the program would ssh-tunnel back to my home machine thus enabling me to log in to work from home, but also establishing the connection only when I wanted it.
Below a small script that makes a dynamic (SOCKS) tunnel that automagically reconnects when your connection goes down for whatever reason... when you re-invoke the script while the tunnel is already up, then it gets killed and re-created.
Using this script my tunnel stays up for days in a row and I don't have to do anything when I move my machine from our coporate wired network to my personal wireless home network.
I use this script in combination with privoxy to ensure that dns requests are also done over the tunnel (as most browsers would otherwise leak dns requests).
Finally, the speed of the solution is about 50% of what I have with the proxy off... in my case my server is not the bottle neck, but it seems that connections are less parallelized when using this solution.
Cheers,
Chris.
My homepage.
---
#!/bin/sh
if ps aux | grep -q autossh;
then sudo -u me killall autossh
fi
if !(sudo -u me ssh-add -l | grep 82:54:1b:9e:47:b6:96:5f:52:e7:a9:fd:18:0a:c2:3b); # fingerprint
then sudo -u me ssh-add
fi
sudo -u me autossh -f -D 10000 -CN me@myserver.org
For the ultimate SSH tunnel (not limited by TCP ports and the like), it's actually possible to run a full PPP session over an SSH tunnel. As ssh can act as a pseudo-tty to the other end, ppp will happily communicate over it.
/usr/sbin/pppd passive"
All you need are compatible pppd configs on each endpoint box (by this I mean they're setup that when they talk they authenticate and give IP addresses, etc), and tell pppd to use ssh as the serial link.
The magic line in your pppd configuration (/etc/ppp/peers/) is:
pty "/usr/bin/ssh -e none -c blowfish -t -X -l
You might want to run this from a terminal or use key based ssh authentication as you may have to deal with entering passwords, but overall it's quite impressive.
No need to screw around with IPSec and other crap - as it runs over ssh, it's encrypted anyway.
I've now got a full IP tunnel back to my home network (suitably protected with iptables), and can run stuff that's normally impossible behind a 'tcp only' work firewall. My SIP clients even connect and I'm able to take and make calls with my home Asterisk box.
Drop me a mail if you want more details. I should probably write a proper howto on this because it's so useful.
Sparks:Gadget:Beer Maker
How do you set up a secure tunnel from workstation through proxy to remote host and then onward to the outside world?
pi = 2*|arg(God)|
I've posted such a story to Slashdot twice with no success, so I'll take this oppertunity to beg.
What length ssh keys should I use? 256? 512? 1024? 2048?
At what point is the line between secure, and paranoid crossed? How will key length impact performance?
May the Maths Be with you!
I'm using SSH in a fairly mundane way, but one I haven't seen anyone else mention here. I telecommute, and my ISP (DirecWay, unfortunately the only thing besides dial-up available to me where I live) blocks PPTP VPN. So instead to do remote administration, I run RDP over a PuTTY/SSH tunnel.
Absurdity: A statement or belief manifestly inconsistent with one's own opinion. -- Ambrose Bierce
http://www.rs4u.com/SSHTunnel/ - great ssh tunnel program for a windows client, alternative to having to setup and manually run putty. Sets up a tunnel, socks5 proxy, lives in your systray, totally clean.
Tunnelier is about the best tunneling program out there:
...Michael...
http://www.bitvise.com/tunnelier.html
Also be sure to check out the SwitchProxy extension for Firefox:
http://mozmonkey.com/
Obviously, his PHB needs a good sh scripting howto!
NO SIG
Use Hamachi. [www.hamachi.cc] It uses AES 256-Bit encryption, over the tunnel. The passwords for everythin are hashed and not stored locally. It is a zero-point configuration solution. It passes thru [most] any NAT/Firewall/VPN. It uses the UDP protocol to do so. I use it at work to remote into my computer. Works great. Cheers
Since no one else bothered to give you, y'know, an answer, just endless links to tools that might or might not help you...
Specifically for SSH tunnels (without dealing with SSL), you basically have two choices: Manually authenticated, or pre-shared RSA keys (which you should use even for manually authenticated connections, but I'll leave that to your discretion)...
In the simplest case (manual authentication with no preshared key, and between any platforms for which a build of the standard OpenSSH tools exists), you just run:
ssh username@remotehost.foo.com -L localport:destination.bar.com:destinationport
And it works like magic... So for example, "ssh myname@mymailserver.org -L 110:mymailserver.org:110" will let "myname" check his email via a plain vanilla POP connection to localhost, which actually connects to "mymailserver.org" over a nice-n'-secure SSH tunnel. I use exactly that method to securely check my email on a BSD machine on which I have SSH access to but no shell account (it has a menu-driven UI).
For pre-shared keys, you just need to run "ssh-keygen" to create two files, "identity" and "identity.pub". It will ask you for a password... If you hit return without typing a password, you'll have a passwordless key pair (suitable for automatic tunnelling - note that as long as you have absolute control the "identity" file, this still gives you as much or arguably more (since it acts like a password no human would ever guess) security than using a password via an interactive session). You then add the identity.pub file to the authorized_keys file (usually in ".ssh" off your home directory) on any machine you want to connect to, and put the "identity" file on your USB keychain drive or what-have-you. Then, you can tell almost any SSH client to just use your "identity" file to authenticate the connection. Piece of cake.
The biggest difficulty arises if you don't have a standard suite of SSH tools available. For Windows, you have basically two (free) choices (for SSH2) - PuTTY (which doesn't have a sshd, so limits you to client-only) or the CygWin build of the OpenSSH tools. Those both have their shortcomings (I personally consider PuTTY about as friendly as a colonoscopy, and will still take it over anything CygWin).
That leaves just one part of your question unanswered - tunneled web browsing. All of the above works great to establish connections to fixed destinations, but not so well if you want to dynamically specify an endpoint (which unless you just want to keep reloading Slashdot over and over, web browsing will require varying destinations).
Short answer - Make your fixed endpoint go to a proxy server, and tell FireFox to use localhost (and whatever port you pick) as its proxy.
Key length doesn't affect performance, since one of the first things the programs do is share a secret key so that they can use symmetrical encryption, which is much faster. As for safety, 512 bits is crackable with a lot of effort. 1024 bits should be safe today, but will be vulnerable in a few years if past hardware performance trends continue.
If you're using SOCKS, DNS lookups are done by the proxy, not the client.