pwrusr.com

SUN ‘s Virtualbox virtualization solution is a respected open source virtualization product, wich today received a major update, reaching version 2.1, dated 2008-12-17 (see here for changelog).

This new version brings, other than the usual (and abundant) bug fixes, major upgrades for the MAC OS X port, like 64 bit guest OS support and Hardware Virtualization support (VT-x and AMD-V); other new features are Nehalem core i7 virtualization enhancements, native VMDK/VHD support (VMWARE hard disk images and MS Virtual PC disk images), including snapshots, Experimental 3D Acceleration via OpenGL and (for me this is by far the most desirable update),  a New Host Interface Networking implementations for Windows and Linux hosts with easier setup (replaces TUN/TAP on Linux and manual bridging on Windows).

Finally SUN figured a way to get rid of this ugly thing. Thanks engineers!

If you already use it, chances are you’ll be automatically notified when the update is ready, else, proceed to Sun’s VirtualBox official website, choose your version and manually start the download.

EDIT: image updated: it was overlapping.

There exists really paranoid SSH access methods! For my everyday use I’m going to accept and implement a less paranoid one: 4096 bit RSA keys + complex passhphrase (but none-the-less, almost secure).

Let’s assume you have two Ubuntu boxes with SSH installed and enabled: the client and the server ("sudo apt-get install ssh" on both, just in case…). Your objective is to gain access to the server from a terminal launched on the client.

From the client open a terminal and type:

ssh-keygen -b 4096

Now, when asked, insert your desired passhphrase (use letters, numbers, and commas – just don’t forget it!), then:

vi .ssh/id_rsa.pub

…select and copy the file’s content.

Now open _another_ terminal window, and gain access to your server (if it’s ubuntu, you should use your ordinary user, the one that will be enabled and authorized for the server access), let’s type:

ssh user@server_IP
vi ~/.ssh/authorized_keys

…let’s paste the content of the client’s id_rsa.pub inside the server’s authorized_keys file (TIP: if it doesn’t work, make sure what you’re pasting lies on a single line).

As of now you should be able to gain access to your server from your client, on a more secure way (test it to be sure – you’ll be asked for your passphrase).

To test it, from the client launch a ssh session to your server and check if you’re asked for the passphrase and that’s it!

THEORY: SSH essentially may authenticate users with differents methodology, the ones I know are:

1. user + password.
2. user + rsa private/public key exchange (no pwd asked).
3. user + rsa public key exchange + passphrase (passphrase is different from password).

The user’s password is the standard, default and unconfigured method that just works, the second, is a more sophisticated one, it is useful when you are almost sure your client is "enough" secure (when you 100% trust your client).

The third method is the the second method plus a passphrase appended to the key (or if you wish, an authorization to use such key); this is useful when you 99% trust your client and still wish to keep control on the remaining 1% (and so the subject of my post).

OPTIONAL – how to secure the ssh server.

I wanted to update my post with some tips I found interesting and useful to tweak my SSH server settings, just open the  /etc/ssh/sshd_config and apply something like this settings:

# Change to no to disable tunnelled clear text passwords -
# PAY ATTENTION TO THE FOLLOWING OPTION!!! IT MAY PREVENT ACCESS TO YOUR SERVER;
# BEFORE APPLYING, MAKE SURE YOU HAVE DIRECT ACCESS TO YOUR SERVER (aka "your server sits next to you")
PasswordAuthentication no

# Maximum Login Attempts
MaxAuthTries 3

# root can't login via SSH
PermitRootLogin no

# if you are logging, a warning is useful.
Banner /etc/issue.net

# keeps some brute force attacks off
MaxStartups 10:50:20

Take care and have fun!