Chuck's Blog

For anyone who doesn’t already know: a ssh client for BlackBerrys (BlackBerries?) is available for free. It’s called BBSSH, and is currently under pretty active development. Being the administrator I am I downloaded and installed it on my Storm2, but noticed one funky thing: it refused to go into portrait mode, or even hide the keyboard. Also it had a weird border around it.

I’m new to these phones, so I very confused until I did my research. Turns out all you have to do to fix this behavior is to go into Options->Applications, select BBSSH, open the menu, and click “Disable compatibility mode.” Once this is done things behave as expected.

One time passwords are a very effective way to connect to an SSH server from an untrusted computer. Consider the following scenario I deal with almost daily.

The computers where I take classes are owned by a governmental organization. Sounds secure, right? Not really. Quite often other students will mess with the computers as they see fit. Plus, installing a keylogger is trivial, since the computers are Mac Minis running Windows Vista laid out on top of a desk, right next to their respective monitor.

Usually I would simply steal the network cable from a Mac Mini for my session on my secured laptop and plug it back in after, but unfortunately this behavior is forbidden by the administration. The biggest problem is not this, but that I need to get access to my remote server to copy a file off. And it cannot wait.

So, I simply fixed the problem by following this how-to and installing putty onto a removable medium, and using my laptop to generate the one time passwords. The linked guide isn’t to hard to follow, so I won’t bother creating my own version of it. However, I did notice some interesting things that could be done with the opie-client and opie-server packages that I plan to blog about later.

If you have any problems with following the how-to I linked to just post a comment here with your problem. I’ll do my best to help.

Today I poured over some of my auth.log files as usual, and yet again to my disappointment there were several hosts that had spent around three to four hours hounding my server with login attempts every five seconds. Having a few hours of time to kill I decided to investigate one of the machines.

I managed to determine large quantities of information. Below is a snippet of the text file I logged my findings in:

Fedora Core (unknown version)
Default Apache 2 installation
- /var/www/html is directory for www files
- /cgi-bin/ does exist, but directory indexing is off

Port 21 (ftp), 22 (ssh), 80 (http), 443 (http) are open.

All this points to that the owner set up a machine, connected it to the Internet, and forgot about it. One would assume the owner would have at least have tried to secure this server with some simple things, but nope. FTP still had its default banner, the apache test CGI scripts were available, and the machine was not patched. (Apache and ssh were about 6 months behind the latest, most secure versions)

I assume the reason this machine was attacking servers was because of a rogue individual compromising its security. I of course did not check, but it is perfectly possible that the owner left a default user account with a common password, opening the avenue for a simple bruteforce attack. How ironic, considering this is what it is doing itself to other machines.

In conclusion, admins, PLEASE SECURE YOUR MACHINES! If you do not then you will likely have your box compromised, just like this one. And trust me, you do not want to be on as many blacklists as this unfortunate victim.

So maybe you’ve gotten tired of entering your password every time you log in to your home server. Maybe you desire better security. Or maybe you want to run automated scripts from a remote box and have their results piped to a local file. (Yay nerdiness!) Regardless this article is for you.

I’m not sure how to do this if your using putty, (feel free to contact me if you know) but I do when it comes to any Linux/BSD based operating system with the standard ssh package. First off you need to generate a RSA key pair (or DSA, your choice) on your client machine. Do this by running

ssh-keygen -t rsa

And just use the default location for the keys to be saved when asked. Heres the big thing to remember: when it asks for a password, DO NOT give it one. If you do than you will have to enter it every time you use the keypair.

The next step is to copy the public key into the ~/.ssh/authorized_keys file on your server. If this file does not exist already simply run the following to copy it over

scp .ssh/id_rsa.pub user@remoteserver:~/.ssh/authorized_keys

Then try connecting to the server. It should instantly login. Now, if your authorized_keys file already exists then what you need to do is append your public key to it. A simple copy+paste usually works, just be careful not to break any lines.

And that’s how you setup public key authentication with ssh. You can also change your server’s ssh daemon confiuration file to disable password authentication if you wish, but be sure you have a backup method of obtaining access to your server if you lose your private key.

SSH has a nifty feature included with it that allows it to act as a SOCKS server. To use it simply try

ssh -D port account@server

And setup your local configuration files to use the server localhost:port as a SOCKS server. Every connection will then be relayed through server, which allows you to bypass filters the local network. It also encrypts all the data from your local computer to server, which works out great for those of us who quite often want to check our email on insecure networks.

Just remember though: The encryption doesn’t mean your data is safe from sniffing. It’s only safe from data sniffing inside the local network, so you still need to use HTTPS connections and such.