Unintrusive but secure passwordless ssh authentication

On a daily basis I need to log in to many remote servers inside or outside of Sun via SSH, often dozens of times per day. This can get pretty tiresome if you need to type in your password with every log in.

Some suggest setting up so-called "passwordless" authentication by generating ssh keys and specifying empty passphrase for the private key. This will result in passwordless authentication, but will also decreased security. Should anyone get hold of your private key, (s)he'll get access to all of your remote systems.

ssh-agent can help a lot in keeping the security level high and minimizing the number of times you need to type in the password. However, if you use a terminal with tabs or use both local and remote terminals on your workstation, you'll end up running many ssh-agent processes and having to authenticate every time you start such a process, which diminishes most of the conveniences of using ssh-agent.

Frustrated with this situation and with a bit of help from Martin, I created a shell script, which I added to my .bash_profile startup script. All I have to do now is to authenticate when my first terminal session starts and I'm good until the next time I restart my OS. sweeeet...

Here is how you could set it up on a workstation and a remote-server:

First, if you haven't generated your private/public ssh key pair, do that now:

workstation $ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/user/.ssh/id_rsa): **********************
Enter same passphrase again: **********************
Your identification has been saved in id_rsa.
Your public key has been saved in id_rsa.pub.
The key fingerprint is:
01:a6:95:23:1c:74:53:c7:f4:87:07:a2:50:ef:99:16 [email protected]

Now make sure that the file system permissions are set up correctly:

workstation $ cd ~/.ssh/
workstation $ ls -l
total 56
-rw-------  1 user  staff  1743 Aug 31 00:13 id_rsa
-rw-r--r--  1 user  staff   398 Aug 31 00:13 id_rsa.pub

The id_rsa file must be readable only by owner, if this is not true, the key will be ignored.

On the remote server you need to authorize your newly generated key pair by appending it's public key to the ~/.ssh/authorized_keys file under your remote home directory:

workstation $ cat ~/.ssh/id_rsa.pub |ssh user@remote-server 'sh -c "cat - >>~/.ssh/authorized_keys"'

Now you can try to log in:

workstation $ ssh user@remote-server
Enter passphrase for /Users/user/.ssh/id_rsa: **********************
Identity added: /Users/user/.ssh/id_rsa (/Users/user/.ssh/id_rsa)
Last login: Thu Sep 11 20:19:19 2008
remote-server $

If you open a new tab in your terminal and try to log in again, you'll be asked to enter the passphrase yet again. This is where my script becomes useful. First download the script from Mediacast: ssh-agent-init.sh and store it somewhere in your home directory

workstation $ mkdir ~/bin
workstation $ cd ~/bin
workstation $ wget http://mediacast.sun.com/users/IgorMinar/media/ssh-agent-init.sh
workstation $ chmod o+x ~/bin/ssh-agent-init.sh

The next (last) step is optional if you want to start the script manually you can skip it.

I wanted to have this script automatically invoked when I start my terminal for the first time in the interactive mode. All I needed to modify were my .bash_profile (used for interactive sessions) and .bashrc (used for non-interactive sessions) startup scripts for my bash shell (modifications are in italics):

workstation $ cat ~/.bash_profile
...
...

. ~/bin/ssh-agent-init.sh

workstation $ cat ~/.bashrc
export NONINTERACTIVE=1
. ~/.bash_profile

(Note: I source the ~/.bash_profile script from the ~/.bashrc script to enable code reuse between the two scripts.)

That's it! If you now try to open a terminal tab for the first time, you'll be asked for passphrase. Once that is done, any new tab or any other shell session created under the same account will reuse the same ssh-agent process.

I've been using this script on my MacOS X laptop as well as OpenSolaris workstation for a few weeks now and it's been working like charm.

TinyURLs are Evil!

Thanks to Linda and J, I got introduced to Twitter and after a couple months of hesitation I created my own account.

Shortly after I started tweeting, I noticed that Twitter uses the TinyURL.com service to cut down the length of their tweets (twitter messages) to minimum.

Seeing all these tinyurls all day long provoked me to post a list of problems that TinyURL and other similar centralized url hiding services bring:

1. TinyURL doesn't have any semantics: Rails, wikis, REST and other new technologies are striving for human readable URL. When these urls are seen posted somewhere, one gets an idea of what to expect and can easily determine if he's interested in viewing the page behind the url based on the domain name, keywords in the url or file type (in case of downloadable files). Compare: http://en.wikipedia.org/wiki/TinyURL to http://tinyurl.com/dmsfm. Both point to the same page, but while the original url sets the expectation (almost everyone knows what can be found on wikipedia, and the keywords "TinyURL" offers even more specifics), the TinyURL (short url) has no meaning for anyone until it is opened in the browser.
2. TinyURLs can be misused for XSS and XSRF attacks: Would you click on a link in an email from a friend that looks like http://mybank.com/sendmoney?amount=50000&to=badguy and how about http://tinyurl.com/2nwz9q ? This example is a bit exaggerated, but who knows, it might not be far from reality. :-/ The fact is that TinyURLs are being misused for obfuscating urls with exploits.
3. TinyURL and user privacy concerns: Since every TinyURL request is handled via TinyURL infrastructure, all the information about who, when, from which site, and from which computer clicked on a TinyURL link.
4. TinyURL messes up search engine logic: Many, if not all, top search engines rely on analyzing which site links to which and use this information to determine which site is popular. What happens when many urls point to other sites via TinyURLs? You can guess which site (hint) gets all the extra points and is considered to be popular.
5. TinyURL messes up web site statistics: If you track activity on your website via services like Google Analytics or Omniture SiteCatalyst, you often want to know where your traffic is coming from. Well, if someone points to your site via a TinyURL, all you'll see is that the traffic is coming from a TinyURL.com site. The reason for this is that when coming to a site via a TinyURL, the referer is always set to TinyURL.com

Enough ramblings. What can you do to protect yourself from the threat of the dark side? Stop using TinyURL.com and other similar services. :)

Other than that, there is not much you can do about most of the problems mentioned above, except for the XSS & XSRF problem: If you get a TinyURL, you can preview it by modifying the url from http://tinyurl.com/dmsfm to http://preview.tinyurl.com/dmsfm. This will show you the destination URL before you are redirected there. If you want this to happen automatically every time you click on a TinyURL, you can save this preference as cookie that will trigger the preview behavior automatically.

Developers that want to cut down on the amount of rendered text should consider rendering urls as en.wikipedia.org/... or just as [url] instead of using the evil TinyURL service. This approach however doesn't work for e.g. printed media, sms.

Don't get me wrong, I'm not saying that the TinyURL service was created with evil intentions, I just think that it was an attempt to solve a common problem, that took a wrong route. Interestingly the Wikipedia page dedicated to TinyURL contains more content about issues related to TinyURL than anything else, I guess it proves my points. :)

Just to confuse everyone even more, there is a few cases when using TinyURL-like services is recommended, I'll come back to these in one of my future posts.

Mail.app Unread Message Mystery Resolved

Last night I finally resolved an issue that was bothering me ever since I got my MacBook Pro and by posting this entry I hope to help others with the same issue.

I use Mail.app for reading my emails via pop3s and imaps and I noticed that some messages were randomly getting flagged as unread. Sometimes the message would stay read forever, other times I had to mark it 10 times as read and a couple of hours or days later it would become unread again.

This was really frustrating and even though I tried googling around, I couldn't find the cause or resolution for this problem. When asking others, nobody knew or suffered from the same issue and that gave me hope that there must be a fix or a way to avoid it.

Last night enough was enough and I googled again. I don't know if I used the right combination of keywords, or if Google's index got better, but I found a forum thread discussing the very same issue I was having!

Apparently GPGMail (an extension that integrates GPG with Mail.app) is responsible for this. Sure enough, the author even acknowledges the issue on his site.

Q: Since I installed GPGMail, some read messages have their 'read' status come back to 'unread'. What's happening? A: It's is a bug in GPGMail that I've been unable to fix yet. The only workaround that works for most people (but not all) is to disable automatic decryption/verification of emails.

The workaround didn't work for me, uninstalling the extension did!

I'm not thrilled by not having GPG support in my mail client, but for now I'd rather be without GPG than having to bear with ~500 unread emails in my mailbox.

Since in my case the issue is repeatable (even after reinstalling MacOSX), I can provide any necessary information to the author if he's interested in fixing it.

In my opinion the issue has something to do with imap or imaps mailboxes and I wouldn't be surprised if many people at Sun would be suffering from the same issue, since imaps is the default mail retrieval protocol at Sun.