Many NAT firewalls time out idle sessions after a certain period of time to keep their trunks clean. Sometimes the interval between session drops is 24 hours, but on many commodity firewalls, connections are killed after as little as 300 seconds. To avoid having your SSH sessions become unresponsive after e.g. 5 minutes, do the following:

On Windows (PuTTY)

In your session properties, go to Connection and under Sending of null packets to keep session active, set Seconds between keepalives (0 to turn off) to e.g. 300 (5 minutes).

On Linux (ssh)

To enable the keep alive system-wide (root access required), edit /etc/ssh/ssh_config; to set the settings for just your user, edit ~/.ssh/config (create the file if it doesn’t exist). Insert the following:

Host *
    ServerAliveInterval 300
    ServerAliveCountMax 2

You can also make your OpenSSH server keep alive all connections with clients by adding the following to /etc/ssh/sshd_config:

ServerAliveInterval 300
ServerAliveCountMax 2

These settings will make the SSH client or server send a null packet to the other side every 300 seconds (5 minutes), and give up if it doesn’t receive any response after 2 tries, at which point the connection is likely to have been discarded anyway.

From the ssh_config man page:

ServerAliveCountMax
Sets the number of server alive messages (see below) which may be sent without ssh(1) receiving any messages back from the server. If this threshold is reached while server alive messages are being sent, ssh will disconnect from the server, terminating the session. It is important to note that the use of server alive messages is very different from TCPKeepAlive (below). The server alive messages are sent through the encrypted channel and therefore will not be spoofable. The TCP keepalive option enabled by TCPKeepAlive is spoofable. The server alive mechanism is valuable when the client or server depend on knowing when a connection has become inactive.

The default value is 3. If, for example, ServerAliveInterval (see below) is set to 15 and ServerAliveCountMax is left at the default, if the server becomes unresponsive, ssh will disconnect after approximately 45 seconds. This option applies to protocol version 2 only; in protocol version 1 there is no mechanism to request a response from the server to the server alive messages, so disconnection is the responsibility of the TCP stack.

ServerAliveInterval
Sets a timeout interval in seconds after which if no data has been received from the server, ssh(1) will send a message through the encrypted channel to request a response from the server. The default is 0, indicating that these messages will not be sent to the server, or 300 if the BatchMode option is set. This option applies to protocol version 2 only. ProtocolKeepAlives and SetupTimeOut are Debian-specific compatibility aliases for this option.

I have a Razer Deathadder. It’s a nice mouse. In Ubuntu, though, its polling rates are through the roof and the mouse is pretty much unusable, even with GNOME’s mouse sensitivity and acceleration settings at their lowest. Previously, this could be fixed by tweaking the mouse section of your X.Org configuration file, /etc/X11/xorg.conf, but in recent versions, a different measure is needed, as most devices are managed via HAL. Here’s how I regained my sanity and mouse slowness. The fix should work for any high-end mouse.

1. Open a terminal
2. Run the command: hal-device
3. In the output, locate the mouse’s hex format vendor and product ID’s as highlighted below:

   82: udi = '/org/freedesktop/Hal/devices/usb_device_1532_7_noserial_if0'
     linux.hotplug_type = 2  (0x2)  (int)
     linux.subsystem = 'usb'  (string)
     info.linux.driver = 'usbhid'  (string)
     info.subsystem = 'usb'  (string)
     info.product = 'USB HID Interface'  (string)
     info.udi = '/org/freedesktop/Hal/devices/usb_device_1532_7_noserial_if0'  (string)
     usb.linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.0'  (string)
     usb.configuration_value = 1  (0x1)  (int)
     usb.num_configurations = 1  (0x1)  (int)
     usb.num_interfaces = 1  (0x1)  (int)
     usb.device_class = 0  (0x0)  (int)
     usb.device_subclass = 0  (0x0)  (int)
     usb.device_protocol = 0  (0x0)  (int)
     usb.product_id = 7  (0x7)  (int)
     usb.vendor_id = 5426  (0x1532)  (int)
     usb.product = 'USB HID Interface'  (string)
     usb.vendor = 'Razer USA, Ltd'  (string)
     usb.num_ports = 0  (0x0)  (int)
     usb.max_power = 100  (0x64)  (int)
     usb.device_revision_bcd = 256  (0x100)  (int)
     usb.is_self_powered = false  (bool)
     usb.can_wake_up = true  (bool)
     usb.bus_number = 8  (0x8)  (int)
     usb.speed = 12  (double)
     usb.version = 2  (double)
     linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.0'  (string)
     info.parent = '/org/freedesktop/Hal/devices/usb_device_1532_7_noserial'  (string)
     usb.interface.number = 0  (0x0)  (int)
     usb.linux.device_number = 3  (0x3)  (int)
     usb.interface.subclass = 1  (0x1)  (int)
     usb.interface.class = 3  (0x3)  (int)
     usb.interface.protocol = 2  (0x2)  (int)

   In this case, my Product ID is 0×7 and my Vendor ID is 0×1532. Note that there can be more than one section containing the name of your mouse or its manufacturer — if you can’t find the product and vendor ID, look further down.

4. Edit the HAL policy file for input devices: sudo nano -w /etc/hal/fdi/policy/10-x11-input.fdi
5. Insert the following text:

<?xml version="1.0" encoding="UTF-8"?>
<deviceinfo version="0.2">
  <device>
    <match key="@input.originating_device:usb.vendor_id" int="0x1532">
      <match key="@input.originating_device:usb.product_id" int="0x7">
        <merge key="input.x11_options.ConstantDeceleration" type="string">5</merge>
      </match>
    </match>
  </device>
</deviceinfo>

Adjust your vendor_id and product_id to match what you noted down before. If the file is empty or doesn’t exist, don’t worry. If it already exists, omit the first line about xml.

6. Hit Ctrl + X, then Y to save the file and exit nano
7. Restart hald: sudo service hald restart
8. Restart X.Org (log out or reboot your computer)

That’s it! The “ConstantDeceleration” setting in /etc/hal/fdi/policy/10-x11-input.fdi is what does the trick. When set to a value of 5, the sensitivity will essentially be divided by 5. Oh, sweet sanity.

Made by Alex Roman — original available in MP4 format here (torrent).

via reddit

By far the easiest way to set up a simple connection proxy is to use the SSH tunneling feature of either PuTTY on Windows or SSH on Linux. This lets you establish connections to servers and ports that you might not be able to access (e.g. from work), as long as you can connect to your server’s SSH service (e.g. myserver.com port 22). This might be for privacy reasons, to connect to MSN from work, to browse a blocked website, et cetera.

On Windows Machines

1. Download and open PuTTY
2. In the fields ‘Address’ and ‘Port’, enter the address and port for your SSH server
3. Go to ‘Connection’ -> ‘SSH’ -> ‘Tunnels’ on the left-hand side
4. In ‘Source port’, enter 31337, then click the button ‘Dynamic’ and then ‘Add’
5. Go back to the main ‘Session’ screen
6. In the ‘Saved Sessions’ text box, enter e.g. “My Shell” and click ‘Save’
7. Double-click “My Shell” to establish a connection, then log in to your shell
8. In any application that supports connecting through a proxy, set the following settings:
   • Proxy Type: SOCKS 5
   • Proxy Server: 127.0.0.1
   • Proxy Port: 31337

You can also set these as your global proxy settings in Windows (via ‘Control Panel’ -> ‘Internet Properties’ -> ‘Connections’ -> ‘LAN settings’ -> “Use a proxy server for your LAN” -> ‘Advanced’ -> ‘Socks’: 127.0.0.1:31337. This will cause most applications to connect through the SSH tunnel to your server.

In the future, just open PuTTY and double-click “My Shell” to open your shell and activate the SSH tunneling.

On Linux Machines

1. Open a terminal
2. Enter e.g.: ssh -D31337 myuser@myserver.com -N
3. Log in to your shell
4. In any application that supports connecting through a proxy, set the following settings:
   • Proxy Type: SOCKS 5
   • Proxy Server: 127.0.0.1
   • Proxy Port: 31337

Alternatively, enter e.g.: ssh -L 31337:patrickmylund.com:80 myuser@myserver.com -N. Here, you specify the target host and port before-hand; the result is that all connections to 127.0.0.1 port 31337 will be tunneled through your server, myserver.com, using your username, myuser, to the target machine, patrickmylund.com, port 80.

The SSH tunnel will stay active until you close the terminal window or hit CTRL+C (Linux), or close PuTTY (Windows).

by Robert Harvey Oshatz, photographed by Cameron Neilson.

I’m not quite sure what I’d do without knowing that ((the loneliest number + the number of horns on a unicorn) / the answer to life the universe and everything) * once in a blue moon = 5.557096 × 10-10 hertz.

Space is beautiful.

Source and more images: HubbleSite Gallery

While experimenting with the Google Similar Pages addon for Google Chrome, I tried it on this site:

I blame the addon’s “beta” label.

Speaking of, Google Chrome Extensions are out, and they are great — except for ‘Similar Pages’, of course.

Google has just launched a DNS service similar to OpenDNS, which I’ve written about previously. The service, dubbed “Google Public DNS“, aims to make domain name lookups (i.e. “What does www.google.com mean?”) faster, and is one of the steps in their plan to make the internet faster — or taking control of it, depending on how dramatic you want to sound.

You can test it by setting your computer or router’s DNS settings to the following DNS server IP addresses:

• 8.8.8.8
• 8.8.4.4

For instructions, see the Google Public DNS configuration instructions.

Unlike OpenDNS, which supports itself by providing advertisement-powered search pages for unresolved queries, Google promises that it will never do any form of redirection. A little strange, considering Google runs the largest advertisement service on the planet, but perhaps they genuinely just do want to make the internet faster.

In my tests, Google Public DNS had a significantly faster response time than OpenDNS from my location in Stockholm, Sweden (Europe). If you’d like to find out which DNS servers are right for you, Google also recently released a DNS server benchmark tool called namebench, which tells you just that, factoring in all of the major public DNS services as well as regional ISP DNS servers.

Note that you should never use DNS servers that you don’t trust. DNS providers have full control over what ‘google.com’, ‘gmail.com’, etc. mean to your machine, and can redirect connections to these websites to malicious websites without your knowledge.