Reuse a ssh connection for less delay in its use.

Standard

The good news is that if you can configure SSH to reuse an existing connection. This means that for example if you have an SSH shell session running then a new connection for SCP can skip the connection setup phase. Two steps are required:

First, you must create a directory (or ‘folder’) which SSH will use to keep track of established connections:

mkdir ~/.ssh/tmp
Next, add these two lines at the start of your ~/.ssh/config (make sure to use your username in place of ‘YOUR-NAME’):

ControlMaster auto
ControlPath   /home/YOUR-NAME/.ssh/tmp/%h_%p_%r
As you can see, a small investment in time setting up your SSH configuration can pay back dividends in convenience.

463 total views, 1 views today

More Trickiness With SSH

Standard

http://nick.zoic.org/art/etc/ssh_tricks/

 

More Trickiness With SSH

I saw an article on reddit about SSH trickery. SSH is a very subversive protocol, able to work around many kinds of unwise security policies. Here’s a couple more useful things to know.

1. Better Lurking Through .ssh/config-ery.

Where you’ve got machines lurking behind other machines, inaccesible from the Internet, you can add a clause like this to your .ssh/config file:

Host: lurker
ProxyCommand: ssh gateway.work /bin/nc %h %p
This causes ‘ssh lurker’ to open an ssh connection to gateway.work, then use nc (may be called netcat on your system, or you may have to install it yourself) to connect on to lurker (the %h %p interpolates the target hostname and port into the proxy command)

2. Reverse Tunnelling

So you’ve noticed the -L option, right, and you understand that by running:

ssh -L 3128:localhost:3128 gateway.home
you are establishing a tunnel home to your proxy server, and you can now configure your web browser to use localhost:3128 as its proxy server to keep your web traffic private.

But did you know this one? Let’s say you’ve got a machine stuck out in DMZ land and you want to apt-get upgrade the poor thing, pronto. You can’t access the web from this box: security policy. You can’t access your internal proxy: ditto. All you can do is ssh into it. Try this:

ssh -R 3128:proxy.work:3128 dmzbox.work
From your shell on dmzbox, you can now configure the http proxy as localhost:3128 and start sucking down packages via the reverse tunnel.

3. Tunnel Tunnelling

Every now and then, you need to get control of a box which is sadly hidden away behind a broken hotel NAT network or some kind of Get Smart style VPN setup. You can’t even get an ssh in. It’s either read Unix commands over an international phone line at 3am your time, or train a pigeon to tap out the following:

ssh -L 2222:localhost:22 gateway.work
which, when run on the remote box, opens an ssh tunnel back home, through which you can ssh back into the remote box with ssh -p 2222 localhost

4. ssh tunnels with tap and -w

There’s also a (newish) “-w” option, which turns ssh into a full-on VPN solution rather than just a port-at-a-time port forwarder.

The useful piece of information which I haven’t seen elsewhere is this: you don’t need to allow root ssh logins to use it. Instead, you can use ‘tunctl’ to preconfigure tun or tap devices on each end with the -u option to set their permissions to a non-root user. The easiest place to do this, on Debian/Ubuntu systems, is in /etc/network/interfaces, for example, in host1:/etc/network/interfaces:

auto tap9
iface tap9 inet static
pre-up tunctl -u nick -t $IFACE
post-down tunctl -d $IFACE
address 10.1.9.1
netmask 255.255.255.0
and in host2:/etc/network/interfaces:

auto tap9
iface tap9 inet static
pre-up tunctl -u nick -t $IFACE
post-down tunctl -d $IFACE
address 10.1.9.2
netmask 255.255.255.0
Now you can ‘ifup’ those interfaces, and then start the VPN by running:

user@host2$  ssh -o Tunnel=Ethernet -w9:9 host1
And the tunnel will be up and running, without needing to create the tunnel as root. You could easily take this one further for an automatic tunnel, setting

 

© 2009-2011 Nick Moore. Published at: http://nick.zoic.org/art/etc/ssh_tricks/

490 total views, no views today

Proxy Firefox through a SSH tunnel

Standard

From: https://calomel.org/firefox_ssh_proxy.html


Proxy Firefox through a SSH tunnel

Calomel.org Home Page RSS Feed

Have you ever wanted to visit sites during the day from a location that denied access to those sites? Perhaps the company has denied access due to bandwidth considerations or you might have decided that the site you want to go to might not always be work safe depending on the story or pictures? What you need is the ability to create a secure and encrypted ssh connection to tunnel your browser traffic through.

Using a ssh tunnel to retrieve the data from websites is significantly faster than trying to use X forwarding to open a remote copy of Firefox on the remote machine. If a remote browser is used the connection will be saturated by the graphical front end of the remote browser window. Use the tunnel for the web site’s data and leave the rendering of the browser to the local machine. This is the most efficient solution.

If you have access to a remote machine by way of ssh you can set up Firefox, or any other SOCKS v5 enabled application, to tunnel its connection through ssh. This way, if you were at work and wanted to browse your favorite sites like MySpace, Facebook or Maxim that are blocked at the company firewall you could.

Getting Started

First you must have ssh access to the remote machine you want to proxy to. Let it be a home machine or a free shell you signed up for on-line. You must also make sure you can ssh from where your browser is to where you want to tunnel to. No need to set this up if port 22 is not open to you from your location to your destination.

ATTENTION: We are proud to announce our Firefox add-on called, “Calomel SSL Validation”. It will grade the security of your SSL connection. The link has screen shots too!

IMPORTANT NOTE: The Firefox tunnel using SOCKS5 (option 1) is the easiest and quickest proxy to setup. If you just want to get the proxy working then follow the SOCKS5 options.

Configure Firefox for the proxy

You need to configure Firefox to use the proxy. Find the section to add a proxy to the browser. On *nix systems of Firefox you will find the settings in File, Preferences, Advanced, Network, Settings. The setting by default is “Direct Connection to the Internet”. We need to setup the “Manual proxy configuration”.

You have two(2) options to pick from. You can proxy directly to the remote machine and then connect directly to web sites. This is the SOCKS5 method and is the easiest to setup. Or, you could use a Squid web proxy (if available) on the remote machine to accept the traffic from the ssh tunnel. Squid would then request the traffic from web sites. Pick one of the options below.

NOTE: For our example, ssh is going to listen on localhost (127.0.0.1) and port 8080 of the local machine.

Option 1: ssh and direct connect (SOCKS5) : If you are going to use the ssh tunnel with the option “-D 8080” then you need to setup the browser to use a SOCKS5 proxy. Setup the proxy config page with the following entries and leave the rest of the entries blank.

Manual proxy configuration:
SOCKS Proxy 127.0.0.1 Port 8080
check the box for “SOCKS v5”
Option 2: ssh tunnel to squid proxy (HTTP/SSL Proxy) : If you are going to use the ssh tunnel with the option “-L 8080:localhost:2020” to connect to the remote machine’s Squid proxy then configure the browser to use a HTTP/SSL proxy. Setup the proxy config page with the following entries and leave the rest of the entries blank.

Manual proxy configuration:
HTTP Proxy: 127.0.0.1 Port 8080
SSL Proxy : 127.0.0.1 Port 8080

Optional Step: DNS proxying through SOCKS5 is highly recommended

This step is optional, but since we are going to be proxying the data over the ssh tunnel then we should also proxy the DNS requests as well. The purpose of this exercise is to get to a site we might not otherwise be able to retrieve or just to anonymize our browsing from your location. If we tunneled our data through ssh and then asked the local DNS server for the ips it would defeat the purpose. So, add a boolean option into the URL “about:config” page in Firefox. Name the entry “network.proxy.socks_remote_dns” and set it to true.

This method will only take affect if you use the SOCKS5 proxy method. If you are proxying using the squid method (HTTP/SSL Proxy) you could always check if you can query another, independent DNS server like OpenDNS.

##Preference Name Status Type Value
network.proxy.socks_remote_dns user set boolean true

Making the ssh tunnel

Lastly, we need to start the ssh tunnel. You have two choices depending if you want the packets to be forwarded to squid on the remote machine or not.

Option 1: ssh and direct connect (SOCKS5) : The following line will start the ssh client and connect to username@remote_machine.com. Port 8080 on localhost (127.0.0.1) will listen for requests and send them to the remote machine. The remote machine will then send the packets out as if they originated from itself. The ssh options are in the man page of ssh, but to summarize them in order: Compression, SSH2 only, Quite, Force pseudo-tty allocation, Redirect stdin from /dev/null, and Place the ssh client into “master” mode for connection sharing.

ssh -C2qTnN -D 8080 username@remote_machine.com
Option 2: ssh to squid proxy (HTTP/SSL Proxy) : The following line will also start the ssh client and connect to username@remote_machine.com. Port 8080 on localhost (127.0.0.1) on the current machine will listen for requests and ssh tunnel them to the remote machine. On the remote machine ssh will forward the packets to localhost port 2020. If squid is listening on localhost port 2020 on the remote machine then all requests sent though the ssh tunnel will then be forwarded to squid. You can use squid to block ads and speed up web access. If you need assistance with squid, check out the Calomel.org Squid “how to” page.

ssh -C2qTnN -L 8080:localhost:2020 username@remote_machine.com

Testing the ssh tunnel

Once you execute the ssh line the encrypted and compressed ssh tunnel will be active in the xterm. We used the “quite” options in ssh so there will not be any logging or output to the terminal.

Make sure Firefox is working by checking the proxy is active and then try to go to a web page. You can also try a site like WhatIsMyIp.com to verify the ip you have with the proxy is different than without.

If everything is working then you can be assured that all of your browsing traffic is being encrypted through the tunnel and no one at your current location will be able to see your traffic over the network.

Once you are done with the proxy just exit the ssh xterm or kill this instance of ssh with Ctrl-c. Remember to set Firefox back to “Direct Connection” if you want to directly browse from your location otherwise you will not be going anywhere.

Interested in setting up Squid or Samba? Check out our guides covering the Squid Proxy and Samba file share servers. We offer clear explanations and fully working example configurations.

Questions?

Do you have any recommended modifications for Firefox in “about:config” ?

More open proxy connections: When you use a proxy, Firefox limits the amount of concurrent open connections to 8. This is too small for most users as many people open multiple tabs to many sites. When more then 8 connections are made the browser seems to be “stuck” because Firefox will wait till an open connection is closed before making a new one. To avoid this problem it is highly suggested to increase the persistent connections value from 8 to 25.

network.http.max-persistent-connections-per-proxy 25
Turn off pop-up tips: If you are annoyed by pop up text when your mouse hovers over a web element you can turn that function off.

browser.chrome.toolbar_tips false
No animations: Stop all animated gifs and pictures like ads and annoying dancing cartoons characters.

image.animation_mode none
No blinking text: Blinking text is annoying. Webmasters should not use it. In case they do, we will disallow the function in the browser.

browser.blink_allowed false
Parallel connections: An easy way to speed up Firefox is to increase the amount of parallel connections the browser makes to the server. Open up Firefox and type in “about:config” in the URL. Then search for the string “conn” You should see the following entries listed. Modify them as follows:

network.http.max-connections 25
network.http.max-connections-per-server 25
network.http.max-persistent-connections-per-proxy 25
network.http.max-persistent-connections-per-server 25
It is _not_ recommended to use more then 25 parallel connections due to abuse of the remote server and concurrency bottlenecks on the local system. Understand that if you have a slow system then more parallel connections can actually slow the browser down considerably. Also, if you try to open too many connections to a server then that server many consider you hostile and block or blacklist you.

Pipelining Enabled: The fastest and most efficient way to implement a browser is to use pipelining. This is where a single persistent connection is used, but instead of waiting for each response before sending the next request, several requests are sent out at a time. This reduces the amount of time the client and server are waiting for requests or responses to cross the network. Pipelined requests with a single connection are faster than multiple HTTP/1.0 requests in parallel, and considerably reduce the number of packets transmitted across the network. Apache supports both HTTP/1.0 keep-alive and HTTP/1.1 persistent connections. Pipelining is implement entirely at the browser end if supported by the remote web server, using persistent connections.

To enable pipelining in Firefox browser goto the url about:config . Then search for “pipe” and set the following:

network.http.pipelining true
network.http.pipelining.maxrequests 8
network.http.pipelining.ssl true
network.http.proxy.pipelining true
TLSv1 with AES256, AES128 and 3DES 168 Only: When connecting to SSL based servers (https) you only want to use the strongest ciphers available. Most web server admins can setup their servers to prefer weak ciphers over strong ciphers for any reason; sometimes they want a less CPU intensive encryption or perhaps they just configured the server wrong. Even Google’s encrypted pages prefer RC4 instead of AES and this is not our idea of good security. We want to make sure that our version of Firefox only uses AES 256 bit, AES 128 bit or 3DES 168 bit ciphers.

Open up a window and type “about:config”. Then in the “Filter” bar at the top search for the following. Double clicking on each line will change the value.

tls and set the lines to true.
ssl2 and set every line entry to false.
ssl3 and set every line to false _except_ lines containing the strings “aes_256” and “aes_128”.
security.ssl3.rsa_des_ede3_sha and set it to true. This is the weakest cipher and may be needed for some older SSL sites.
Now your browser will _only_ accept the TLSv1 protocol in AES256 bit cipher encryption no matter what previous weaker ciphers a web server prefers. This configuration also makes your browser FIPS 120-2 compliant (year 2030 specs).

Is there any way I can switch proxies faster?

There are add-ons, also called extensions, for Firefox called FoxyProxy or SwitchProxyTool you can use. They offer the ability to setup multiple proxy settings and choose the one you want, or turn them off, using a drop down menu.
I noticed you use compression in the ssh tunnel proxy. Why?

The majority of the data you are retrieving using the browser is text or HTML data. This type of data compresses very well at up to 80%. Using compression in the tunnel will speed up the delivery of the data considerably.

Questions, comments, or suggestions? Contact Calomel.org or Google+

1,331 total views, no views today

How to mount a block device over network via nbd (Re: Alternatives to sshfs?)

Standard

From:


How to mount a block device over network via nbd (Re: Alternatives to sshfs?)
Originally Posted by alaios
Could you please help me offload a bit my cpu by pushing more my network?
The following procedure mounts the filesystem in the block device “/dev/sdz” on the machine “server” onto the directory “/mnt” on the machine “client”. This is done via nbd (network block device). As a result the filesystem logic is done on the machine “client”. I doubt that there will be a considerable speed advantage, but if your “server” is very slow and your client and network are quite fast, it’s possible. You will have to replace strings like “/dev/sda”, “/mnt” and “server” with the actual names.

Your ssh daemon should already be running on the server, otherwise you couldn’t have used sshfs. Install package “nbd” on both machines. Login at “server” as root, then:
Code:
$ nbd-server 127.0.0.1:60000 /dev/sdz
Add “-r” to the command line to enforce read-only access (you can only mount read-only later with this). Caution: This command allows any local user to access this block device on “server”.

On the client, connect to the server with ssh (as ordinary user, if you want):
Code:
$ ssh -c blowfish-cbc -L 127.0.0.1:60000:127.0.0.1:60000 server
The blowfish cipher is said to be quite fast, hence not eating too much CPU power on the server and client. Caution: This command allows any local user on “client” to access the block device on “server”. Don’t close this ssh-connection while the file system is mounted!

Now login as root on “client”, and mount the device with:
Code:
$ modprobe nbd
$ nbd-client localhost 60000 /dev/nbd0
$ mount /dev/nbd0 /mnt
Your filesystem should now appear in /mnt, subject to access restrictions and privileges based on the user accounts on the machine “client”. In a multi-user environment, this might lead to unexpected results and even security risks! On the other hand, if you’re the only user of “client” and “server”, there shouldn’t be any serious problems. And if your machines are connected via a secure link, you can skip the ssh tunnel entirely (thus saving more CPU power) and connect the nbd-server and nbd-client directly.

To unmount everything:
Code:
$ umount /mnt
$ nbd-client -d /dev/nbd0
Now you can close the ssh connection.

Yarny

1,952 total views, no views today

Poor man’s VPN with SSH | Setting up an SSH tunnel with PuTTY

Standard

Article #1 From: http://fnord.no/sysadmin/security/vpn-with-ssh
Article #2 From: http://realprogrammers.com/how_to/set_up_an_ssh_tunnel_with_putty.html


Poor man’s VPN with SSH

SSH has port forwarding, dynamic forwarding, and now also IP forwarding. This allows you to create connections out through a firewall, and allow other connections in and out through your SSH-connection, originating at your SSH server. Read on for a few examples of use, and make sure you have the blessing of your security team.

Local forwarding

With local forwarding, you open a local port, and forward it to another host and port from the remote server.

Often used with forwarding to single webservers, proxies, Citrix ICA servers, VNC servers, and Windows Remote Desktop (RDP).

Example with local forwarding

Connect to a server at work, forwarding a connection from port 10080 on my laptop to important.server.example.org.

I can then open my browser to http://localhost:10080, and do my stuff. Some web applications, though, can be tricky enough to expect a hostname, and for that you need to edit /etc/hosts or equivalent, or you can read on for dynamic forwarding.

Remote forwarding

With remote forwarding, you open a listening port on the remote side, and forward it to another host and port from the local server.

Example with remote forwarding

One useful scenario is to help family members who have PC trouble. For instance: Mom has a problem, calls me, and wonders if I can help, and then clicks an icon on her desktop that does the following thing:

  • Starts Remote Desktop or VNC
  • Connects to my SSH server, with remote forwarding from <vncport1> on the SSH server, to localhost:<vncport1> on her PC.

What I do, is:

  • Connect to my SSH server, with local forwarding from <vncport1> on my laptop, to <vncport1> on the SSH server, which again connects through the remote forwarding to localhost:<vncport1> on mom’s PC.
  • Start a VNC client, and connect to my localhost:5801 on my laptop. This port is now connected through my ssh session, to mom’s ssh session, to her PC.

Dynamic forwarding with SOCKS

OpenSSH’s client has the ability to do dynamic forwarding to act as a local SOCKS server, both for SOCS4 and SOCS5.

Many programs have built-in SOCKS support, so if you enable this, and configure it to use localhost:<socksport> as a SOCKS proxy.

For programs with no built-in SOCKS support, you can use “tsocks”, to intercept networking calls, and work through the SOCKS server.

Example with dynamic forwarding

Then I configure Firefox, for instance, to use the SOCKS server at localhost port 1080, and all my web connections will go through the SSH connection, and appear to be initiated from myserver.example.com. Much easier than with local forwarding, and works great for remote administration of things from home where you use different hostnames and ports, and perhaps also unroutable IP addresses.

IP forwarding with TUN

Now we’re talking. This is the real thing, we get IP forwarding through a point-to-point interface. This exists only in newer versions of OpenSSH, and is not very well documented yet. Unfortunately, this also includes this document until I have more time to research further.

Example with IP forwarding

Where ‘0’ is the local device tun0, and ‘1’ refers to the remote device tun1. On each side, one needs to set an IP address for host-to-host contact, and add routing and perhaps also NAT for network access.

Beware, as careless use of IP forwarding between sites may have a serious impact on network security, and may make others very angry if used without permission.


realprogrammers.com

Setting up an SSH tunnel with PuTTY

What follow is how to set up as SSH tunnel using PuTTY with the MySQL port (3306) forwarded as an example. After completing this how-to you’ll have port 3306 on your local machine listening and forwarding to your remote server’s localhost on port 3306. Thus effectively you can connect to the remote server’s MySQL database as though it were running on your local box.

Prerequisites

This how-to assumes your MySQL installation has enabled listening to a TCP/IP connection. Only listening on 127.0.0.1 is required (and the default as of MySQL 4.1). Although beyond the scope of this how-to, you can verify the server’s listening by using

on the server. Look for

and

in your

. Also, a trouble-shooting guide.

To achieve the same with PostgreSQL simply use PostgreSQL’s default port, 5432.

to test;

and the manual as pointers for configuration.

Set up the tunnel

Create a session in PuTTY and then select the Tunnels tab in the SSH section. In the Source port text box enter 3306. This is the port PuTTY will listen on on your local machine. It can be any standard Windows-permitted port. In the Destination field immediately below Source port enter 127.0.0.1:3306. This means, from the server, forward the connection to IP 127.0.0.1 port 3306. MySQL by default listens on port 3306 and we’re connecting directly back to the server itself, i.e. 127.0.0.1. Another common scenario is to connect with PuTTY to an outward-facing firewall and then your Destination might be the private IP address of the database server.

Putty Tunnel

Add the tunnel

Click the Add button and the screen should look like this,

Putty Tunnel Added

Save the session

Unfortunately PuTTY does not provide a handy ubiquitous Save button on all tabs so you have to return to the Session tab and click Save,

Putty Session

Open the session

Click Open (or press Enter), login, and enjoy!

Here for reference is an example connection using MySQL Adminstrator going to localhost: note the Server Host address of 127.0.0.1 which will be transparently forwarded.

Mysql Administrator Login

1,722 total views, no views today