There is nothing worse than having to administer a server through a bad connection. When you are disconnected, having to reconnect, login, and navigate to where you last were, can knock you out of the flow of what you were doing, severely affecting your productivity.

screen to the rescue

Back in the time of the dinosaurs and dial-up, some GNU hackers, tired of the inconvenience just described, invented the screen application. screen creates a virtual console running on the server, which keeps the user logged in to the server, even when the network connection is lost. With screen, you will never lose your place while logged in remotely again, baring a reboot, shutdown, or power-loss to the server itself (alas, screen is not magic.)

screen can do much more than this simple description so far hints at. You can learn more from the online manual (type man screen at the command-line.) But for this hack, the following is all you need to remember:

Type in screen -DR when you first connect to your server, and your login session will be preserved through network disconnections. If you get disconnected, login again, and type screen -DR to return to your session, just as you left it.

The screen trick is all well and good. But we like to do things thoroughly at pjtrix, and try to find a full solution to the problem. So on to autossh we go.

autossh: aim for the kill

Keeping with the dinosaurs and dial-up theme, autossh is like an auto-redialer. It faithfully tries to reconnect you to your server again as soon as it detects the connection is gone. It does this by creating an SSH tunnel loop between your workstation and the remote server, and monitors it repeatedly for lost messages.

Using autossh is almost like using ssh: except for the connection monitoring specifics, autossh simply passes all command-line parameters to ssh, and after entering the command-line, all user interaction is done through the running ssh instance. To use autossh effectively with screen, type the following command to first connect to your remote server (use this command instead of ssh):

autossh -M monitoring-port -t username@server.domain.tld “screen -DR”

For example:

autossh -M 20000 -t webmaster@pjtrix.com “screen -DR”

With the above command, autossh creates an SSH tunnel loop with ports 20,000 and 20,001 for monitoring the connection; the -t parameter makes ssh create a pseudo-terminal when it connects to the server; ssh connects to the server pjtrix.com as user webmaster; and finally, ssh runs the command screen -DR remotely on the server immediately upon a successful connection and user authentication.

If for any reason the connection to the server drops, autossh detects this, and starts another ssh session, with the same commands. This effectively reconnects you to the server, logs you back in, and returns you to your screen session, right where you left off.

Used together, autossh and screen are real peace of mind savers for Unix system administrators. Couple this hack with an SSH authentication agent and SSH keys, and you don’t even have to remember your server password between reconnects.

Truly, there can never be greater Unix administration bliss than this.

Technorati Tags:
hacks, ssh, open.source

I am more likely to cover Ruby on Rails and Ruby as a language and cross-platform development technology versus other open source technologies, as this is what I now prefer. But you may also see posts on C and C++, Java Enterprise Edition technologies, Python, Mozilla technologies such as XUL and XULRunner, and software development ideas in general. I may cover C# and .Net, but only because you can develop cross-platform applications with them using Mono.

My article proposals for “the secret online geekly articles site” are most likely to be accepted if they are about Java technologies. As I research my articles, I am bound to write about Java subjects here. But I’ll try to make the weblog posts more general than the articles. If the article proposals get turned down after a few rewritings and retries, I will publish the subject here or try to get them published somewhere else, like InfoQ and The Server Side.com. (BTW, that should be a hint that those two sites aren’t “the secret online geekly articles site.”)

I will also cover some Unix administration topics. For example, I feel I ought to cover the details of pjtrix’s Subversion configuration, as I found the online manual a bit wanting in specifics. Other like-minded geeks, the very people I’d like to bring to my weblog, might welcome a more direct approach. There are also more ssh tricks I haven’t begun to cover.

All of this writing will hopefully be bringing new readers to my humble weblog and other parts of the website. Armed with this hope, I continue to get pjtrix.com ready for 2007.

Tuesday night, I signed up to Google Analytics and Tools for Webmasters, and added to the WordPress and Trac templates the bits of JavaScript that report to Google where you all come from. The reports Google provides are nice and pretty, but I find Google’s solution wanting, specially in their support of blogging and citizen media. The tools are more geared towards “website” traffic analysis. That’s just lame.

Not everyone that will come here will do so with a JavaScript-powered browser. Feed readers and podcast clients, for instance, only speak HTTP and RSS or Atom. They will leave no trace in Google Analytics’ logs.

To complement Google Analytics, I’ve installed the Webalizer Apache log analysis tool, which will help me study my web server logs in more detail without my being swamped in hundreds of megabytes of raw text.

I also installed the Popularity Contest WordPress plugin. This should help direct search-passers-by to what’s hot on this site, or just make it more clear sooner that they got to the wrong place.

Hopefully, the combination of Google Analytics, Webalizer, and Popularity Contest, will together help me learn who my audience is, learn what is “my voice,” and learn how to make this weblog more valuable to my readers.

Technorati Tags:
rails, ruby, hacks, ssh, software.development, open.source, web.architecture, wordpress, weblogs, web.technologies, web.services, cross.platform

#making an in-server backup in folder blawg.bak

cp -r blawg blawg.bak

#backup the database

mysqldump -u user -ppassword database-name > blawg-backup.sql

# upgrade the wordpress files

wget http://wordpress.org/latest.tar.gz

tar xzvpf latest.tar.gz

cp -r wordpress/* blawg/

Then I visited http/blawgupdate.php (which I’ve renamed, suckas.) And that was it, really! Many thanks to the WordPress developers for such an easy upgrade.

——-

A visitor sent me an email a few days ago, correcting my hack post for SSH tunneling of HTTP. Jim was his name, and he said that he wasn’t 100 % sure, but that he believed SSH only used the keys for authentication purposes, and that smaller session keys were created on the fly after authentication was successful. Therefore he believed the strength of the encryption wouldn’t be an order of magnitude better than SSL, as I claimed at the end of my post.

I am afraid Jim is correct. The session key size varies from one implementation of SSH to another, but they all support 168-bit triple-DES. This is the default for most OpenSSH installs on Linux and BSD these days. So while 168-bit triple-DES is believed to be better than SSL’s 128-bit RSA, it’s not an order of magnitude improvement.
Thanks Jim, for the correction.

Technorati Tags:
hacks, ssh, tunneling, upgrades, wordpress

Over the past few months, some friends and cow-orkers have come to my site, and invariably I get the “Where are the hacks?!? When you gave me the link, I was excited and assumed the site had all your hacks and tricks?!? What happened?!?” You see, my fellow cow-orkers specially, know me as a man of many technical talents. I can turn any normal workday into a techfest show-and-tell, just by emptying my pockets or laptop bag, or discussing my latest interests.

So without much further ado …

Hack #1 – SSH tunneling for ultra-secure web app administration

I’m a fairly paranoid person. OK, I take that back: I’m a really paranoid person when it comes to my online life, but only fairly paranoid in my real life. And just to set the record straight, simply because I am paranoid and admit it freely, doesn’t mean someone out there isn’t really out to get me! They just haven’t gotten me yet.

I’ve been around the tech block a few decades, and have had Commodore C64 and Amiga demo scene BBSs defaced, and later, a Sega Dreamcast demo scene website and a Yahoo! webmail account taken over, by a prankster who proceeded to send crap to various Dreamcast scene mailing lists I frequented, pretending to be me. With these experiences came lessons that I apply as much as I can. Because of them, I’ve been without security related problems for the last six years.

That’s six years with no virus attacks, no remote IRC bots, no trojans or backdoors installed, no rootkits on my personal computers or servers. Being paranoid pays dividends in serenity. I can sleep at night knowing I’m not sending out spam or aiding in DDOS attacks. Can you say the same, with certainty?

The problem

One of the things I don’t like about the stock WordPress install, is that the administration pages are not secured with SSL. There are various write-ups on how to modify the code to accomplish this, but applying them makes it more complicated to upgrade WordPress. And I want my WordPress upgrade to be as painless as possible, or I’ll just put it off.

One of the reasons I put off upgrading from WordPress 2.0 to 2.0.1, 2.0.2, and finally 2.0.3, is that I had modified my WordPress install with one of these SSL hacks. I could feel the paranoia mount up as I thought “My username and password may be SSL secured, but there are known security holes in WordPress 2.0. I’ll better upgrade ASAP!” So after RailsDay, since I didn’t have any work, I upgraded to WP 2.0.3 and didn’t apply the SSL hack.

You see, I have a secure way of logging in to the admin pages, and still keep the WordPress upgrade as simple as possible. (By the way, this trick works for proxying all web access to a server, it’s not just for WordPress administration.)

Introducing SSH tunneling

SSH is called Secure SHell, and many people just think of it that way. But it does more than that, with secure remote file copying and secure FTP tranfering of files as built-in features. Under the hood of the secure terminal access and file transfers, lies a packet tunneling framework with great flexibility.

With SSH tunneling, it is possible to connect to one computer at one port, and forward the TCP request to any other computer at the same or any other port. This only works for TCP connections, though. UDP-heavy protocols such as BitTorrent peering and seeding can’t travel through “regular” SSH tunnels.

(There’s one kind of SSH tunnel, the SSH SOCKS proxy, that does allow UDP packets through, but only in one direction. So it’s not as effective for P2P tunneling anyhow. We’ll discuss SSH SOCKS proxying and its uses some other time.)

So how do you tunnel to a web host with SSH?

First, using a plain text editor (not Wordpad, Windows people; use Notepad) open your hosts file on your local host (not on the web server.) In Unix the file lives in:

/etc/hosts

In Windows, it lives in: ** usually **

C:/Windows/system32/drivers/etc/hosts

In Windows, the operating system isn’t always installed on drive C and not always in a folder called Windows. But ninety-nine thousand times out of a hundred thousand, it will probably be like this. So don’t sweat it, specially if you bought your Windows PC already set up. And if it wasn’t already set up, you probably already know where you installed your Windows.

The hosts file wil contain a line like this:

127.0.0.1		localhost

While preserving the rest of the contents of the file, change that line to read like this (substitute serverName as appropriate for the web host you want to tunnel to):

127.0.0.1		localhost serverName

Second, install SSH on your local host. If you’re on Windows, this can be Putty or the SSH client for Cygwin. (There are plenty of writeups about both open source Windows products, so use Google search for further help with that.) Most Linux distributions come with at least the SSH client installed. Mac OS X and Solaris come with both SSH client and server software installed.

Third, you need an SSH login account on your web server. Not all shared hosting accounts give shell access, so it may be that you can’t use my little trick. Virtual private hosts and dedicated servers definitely have SSH if they’re Unix-based. If you host your weblog on Windows, you have other problems besides no remote secure shell access. It’s called gullibility. Again, look it up on Google.

Now comes the good part. Once you have installed an SSH client, and have SSH access to your remote server and a shell account, you have to forward port 80 from your local host to the web server, with this command (substitute serverIP and accountName as appropriate; namely, you need the IP address of your web host, or a different domain name that resolves to the same IP as your web host):

ssh -L 80:serverIP:80 -N accountName@serverIP

If you’re using Putty, the command is:

plink -L 80:serverIP:80 -N accountName@serverIP

Make sure your Putty installation is on the command-line PATH. If you don’t know what that is, what are you doing reading this far?!?

Now, when you browse to http://serverName (not serverIP), SSH will tunnel from your local host to the web server, and your connection will be encrypted just a tad better than industrial-strength SSL. Most SSH implementations let you choose from a variety of protocols and session key sizes, such as Blowfish and 256-bit session keys. That’s double the encryption power of the 128-bit RSA encryption in SSL. Ultra-secure, baby! (Thanks to Jim for the clarification.)

And there you have it, PJTrix.com’s Hack #1.

(Soon, I’m putting up a Wiki to collect these. So consider this text as my second draft of this hack. Any comments, improvements, criticisms, are welcome in the comments. Thanks for reading this far!)

Technorati Tags:
open source, hacks, ssh, tunneling