Passwordless SSH with encrypted homedir in Ubuntu

Quite recently I came across a very interesting issue: while configuring passwordless SSH (it’s public key based, so depending on you have it configured it may not be completely passwordless) access to some of my VPS servers, I found that the same keypair just wouldn’t work on one of the servers.

Not only that, but the behaviour was quite bizzare: upon my first attempt to connect the public key would get rejected and a regular password would be requested by the ssh session. But once I successfully logged in with my password, any subsequent ssh connections would happily authenticate by my public key and would let me in without a problem.

Those of you using home dir encrypiton in Ubuntu are probably smiling right now! 🙂 But becase I have never consciously configured or used this feature, it took me a good few hours to troubleshoot the issue and come up with the fix.

Why public-key based SSH doesn’t work with encrypted home directories

The answer is quite simple: before your server can decide whether you are providing a valid and trusted SSH key, it must read your public key stored in your homedir. But if your homedir is encrypted, this becomes a classical chicken-and-egg scenario – until you log in and therefore decrypt your homedir the server won’t gain access to your public key. Only you wouldn’t be needing the public key by then, would you?

Store your authorized SSH keys outside your encrypted home directory

If you happen to like your homedir encryption AND would like to use public/private key SSH authentication,  there is a way out: you need to store your authorized keys outside of your encrypted homedir.

The usual access restrictions and directory/file permissions still apply, so the only thing you’re changing is moving your authorized keys outside of the encrypted homedir on your server. This way things will work exactly as you expect: you authenticate with your private key and this results in your automatically mounted and decrypted homedir.

Here are the steps to make this happen. You’re going to need superuser privileges for my scenario because it caters for all the users on your Ubuntu server, not just one account that belongs to you (use sudo to become root).

Step 1: create a directory structure for your authorized keys.

First, the main directory, I created it under /var – seems quite a safe choice since this directory is unlikely to grow and is equally unlikely to get removed by accident.

# mkdir /var/openssh

Perfect! Now we need to create user-specific directories, just to keep this dir really tidy. My username is “greys“, so here is the directory:

# mkdir /var/openssh/greys
# chown greys /var/openssh/greys

Step 2: copy existing authorized keys file into new location

(you must log in as your username for this, otherwise the homedir will stay encrypted)

$ cp /home/greys/.ssh/authorized_keys /var/openssh/greys

Step 3: update SSHd config with new location for authorized_keys file

You’re going to do this as root once again:

# vi /etc/ssh/sshd_config

update the value of the AuthorizedKeysFile so that it looks like this:

AuthorizedKeysFile        /var/openssh/%u/authorized_keys

Step 4: Restart SSH service

# service ssh restart
ssh start/running, process 3708

That’s it! Give it a try and let me know how it worked out.

Recommended books:

[AMAZONPRODUCTS asin=”1590594762″]

See also




Upgrading Ubuntu with do-release-upgrade

There comes a time (a couple of times a year, actually) when you may want to upgrade your Ubuntu distro (read here for instructions on confirming your version of Linux: Find Out Linux Version)

Once that’s done, you can use do-release-upgrade for a hassle free upgrade.

IMPORTANT: are you can see, I’ve used a really old Ubuntu server with 8.10, hence your procedure for upgrading more recent Ubuntu versions may be slightly different. For example, later upgrades will warn you if you’re doing a release upgrade over ssh.

What do-release-upgrade is and when you should use it

do-release-script is a Python script which automates the process of updating multiple packages. It relies upon Ubuntu’s core package management functionality.

Apart from downloading and installing updated versions of packages found on your system, this command attempts to take care of all the necessary Ubuntu-release related file changes.

Step 1: Run do-release-upgrade

Once you type the do-release-upgrade command name and press Enter, you should see how vital information about packages currently installed is being collected:

# do-release-upgrade
Checking for a new ubuntu release Done
Upgrade tool signature Done
Upgrade tool Done
downloading
extracting ‘jaunty.tar.gz’
authenticate ‘jaunty.tar.gz’ against ‘jaunty.tar.gz.gpg’
Reading cache
Checking package manager
Reading package lists: Done
Reading state information: Done
Updating repository information
Done http://archive.ubuntu.com jaunty Release.gpg
Done http://archive.ubuntu.com jaunty-updates Release.gpg
Done http://security.ubuntu.com jaunty-security Release.gpg
Done http://us.archive.ubuntu.com jaunty-backports Release.gpg
Done http://security.ubuntu.com jaunty-security Release

Checking package manager
Reading package lists: Done
jaunty-security/multiverse
Packages: 98  2
Reading state information: Done
Reading state information: Done
Reading state information: Done
Calculating the changes

 

2. Confirming what upgrading will do

This is your last change to change your mind. All the necessary information about your current Ubuntu release is collected, and now you’re presented with the exact upgrade details: how many packages will be removed, how many new ones will be installed, how many will be upgraded. You also are given details about the required amount of data to be downloaded should you decide to proceed with the upgrade;

Do you want to start the upgrade?

1 package is going to be removed. 23 new packages are going to be installed. 420 packages are going to be upgraded.

You have to download a total of 248M. This download will take about 7 minutes with your connection.

Fetching and installing the upgrade can take several hours. Once the download has finished, the process cannot be cancelled.

Continue [yN]  Details [d]

Ready? Press y for yes!

3. Downloading all the packages

Just like with apt-get, you will now see the progress of downloading all the updated packages for your Ubuntu OS. At the bottom of the screen you will see the overall completeness of the download (22% in my example), the current download speed (598kB/s in my case) and the ETA:

Done http://archive.ubuntu.com jaunty-updates/main libbz2-1.0 1.0.5-1ubuntu1.1
Done http://archive.ubuntu.com jaunty/main libdb4.7 4.7.25-6ubuntu1
Done http://archive.ubuntu.com jaunty/main libncursesw5 5.7+20090207-1ubuntu1
Done http://archive.ubuntu.com jaunty-updates/main libssl-dev 0.9.8g-15ubuntu3.6
Done http://archive.ubuntu.com jaunty-updates/main libssl0.9.8 0.9.8g-15ubuntu3.6
Done http://archive.ubuntu.com jaunty/main python2.6 2.6.2-0ubuntu1
[23%] 598kB/s 5min17s

4. Upgrade

Once package are downloaded, they will get installed once by one, with package-specific questions asked for software like postfix or apache.

5. Reboot

To finalize the distro upgrade, you will need to do a reboot. Once completed, you should have a shine next release available.

Recommended books:




Mounting NFS shares on Mac OS X

I’ve recently decided to give Mac OS X a try. For the past week or so I’ve been spending a good few hours a day working in Snow Leopard installed on a MacBook Pro borrowed from a friend.

While Mac OS is unlike any Unix-like operating system I’ve managed so far, there are certainly some of similarities. I can honestly say that I’m enjoying the Mac Book Pro so far, and hope to discover most of the differences compared to my previous Unix-like desktop which is Ubuntu 9.10.

Mounting NFS on MAC OS X

One thing which I noticed immediately was that out of the box it was impossible to mount any NFS shares from my Ubuntu NAS server. Any attempt to mount a remote filesystem would give me an error like this:

mbp:~ root# mount nasbox:/try /mnt
mount_nfs: /mnt: Operation not permitted

This error was happening for a relatively simple NFS share on the Ubuntu box:

nasbox# cat /etc/exports
/try            (rw)

… so I started looking around and realised that the reason for this strange problem is quite simple.

Mac OS X uses non-standard port for outgoing NFS connections

That’s right! Apparently, Mac OS X uses a non-privileged port (2049) for TCP and UDP connections serving the NFS transport. What this means is that most likely attempts to mount remote filesystems will fail, because most NFS servers don’t really like connections from insecure ports.

There are two ways to approach this problem:

  1. Fix it on the client side (probably makes more sense)
  2. Fix it on the NFS server side (if you manage both systems)

Using reserved NFS port number on Mac OS X

There’s a mount option supported by the mount_nfs command, which allows you to force the NFS client connections to originate from a privileged port. This will magically make your attempts to mount remote filesystems successful. The option is called resvport.

First we double-check that default mounts still don’t work:

mbp:~ root# mount nasbox:/try /mnt
mount_nfs: /mnt: Operation not permitted

… and now let’s use the resvport option:

mbp:~ root# mount -o resvport nasbox:/try /mnt

… and make sure we’re actually looking at a mounted filesystem:

mbp:~ root# df -h /mnt
Filesystem   Size   Used  Avail Capacity  Mounted on
nasbox:/try    61Gi   56Gi  2.6Gi    96%    /mnt

Allowing connections from non-privileged ports on NFS server

Like I said, if you manage both the Mac OS based client and the NFS server, perhaps it makes more sense to relax the default NFS server security and allow the connections from non-privileged ports.

Just to remind you about the validity of such a decision, the option to allow non-privileged connections is called insecure.

Here’s how you use it:

nasbox# cat /etc/exports
/try            (rw,insecure)

After making this change to the /etc/exports file, you’ll have to restart your NFS server. On my Ubuntu NAS box, it’s done like this:

nasbox# /etc/init.d/nfs-kernel-server restart
* Stopping NFS kernel daemon
...done.
* Unexporting directories for NFS kernel daemon...
...done.
* Exporting directories for NFS kernel daemon...
...done.
* Starting NFS kernel daemon
...done.

We know are ready to attempt the default mount of the same filesystem on the Mac OS X client:

mbp:~ root# mount nasbox:/try /mnt

That’s it! I won’t promise any Mac OS posts just yet, but if there is enough interest – I’d love to do the research and to post all the discoveries on the Unix Tutorial pages.

See Also




Ubuntu SSH: How To Enable Secure Shell in Ubuntu

SSH (Secure SHell) is possibly the best way to remotely access a Unix system – it’s very secure thanks to automatic encryption of all the traffic, and it’s also quite universal because you can do all sorts of things: access remote command line shell, forward graphics session output, establish network tunnels, set up port redirections and even transfer files over the encrypted session.

Today I’m going to show you how to get started with SSH in Ubuntu.

Installing SSH server in Ubuntu

By default, your (desktop) system will have no SSH service enabled, which means you won’t be able to connect to it remotely using SSH protocol (TCP port 22). This makes installing SSH server one of the first post-install steps on your brand new Ubuntu.

The most common SSH implementation is OpenSSH. Although there are alternative implementations (closed source solutions and binary distributions maintained by various Unix and Unix-like OS vendors), OpenSSH is a de-facto standard in the secure transfers and connections industry. That’s exactly what you want to install.

Log in with your standard username and password, and run the following command to install openssh-server.

You should be using the same username that you specified when installing Ubuntu, as it will be the only account with sudo privileges to run commands as root:

ubuntu$ sudo apt-get install openssh-server
[sudo] password for greys:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  rssh molly-guard openssh-blacklist openssh-blacklist-extra
The following NEW packages will be installed:
  openssh-server0 upgraded, 1 newly installed, 0 to remove and 75 not upgraded.
Need to get 285kB of archives.
After this operation, 782kB of additional disk space will be used.
Get:1 http://ie.archive.ubuntu.com jaunty/main openssh-server 1:5.1p1-5ubuntu1 [285kB]
Fetched 285kB in 0s (345kB/s)
Preconfiguring packages ...
Selecting previously deselected package openssh-server.
(Reading database ... 101998 files and directories currently installed.)
Unpacking openssh-server (from .../openssh-server_1%3a5.1p1-5ubuntu1_i386.deb) ...
Processing triggers for ufw ...
Processing triggers for man-db ...
Setting up openssh-server (1:5.1p1-5ubuntu1) ...
Creating SSH2 RSA key; this may take some time ...
Creating SSH2 DSA key; this may take some time ... 
* Restarting OpenBSD Secure Shell server sshd                           [ OK ]

Public and Private keys in SSH

As you can see in the sample output above, the installation procedure created 2 sets of keys – SSH2 RSA keypair and SSH2 DSA keypair. The reason for this is that OpenSSH relies heavily on the public and private key (PPK) infrastructure.

The concept behind PPK is pretty cool: SSH allows you to create keypairs. They are generated to the maximum randomness achievable on your system. Keypairs can be created for your server or for your individual uses.

The idea is that public keys are shared with other servers, and they later can be used as a unique identificator to confirm your true identity. When you’re connecting to another server, it uses your public key to encrypt a short message and the secure session will only be established if on your side you have a private key that allows decrypting the message. No other system or user can decrypt the message because only you would have the private key. That’s why it’s called private – don’t ever share it with anyone.

As an additional security measure, when you’re generating personal keypairs you’ll be asked to supply a passphrase so that even if someone steals your private password they won’t be able to use it without knowing your passphrase.

Verifying your SSH server works

While you’re still on your local desktop session, you can use the ps command to confirm that SSH daemon (sshd) is running:

ubuntu$ ps -aef | grep sshd
root     24114     1  0 15:18 ?        00:00:00 /usr/sbin/sshd

Now that you see it’s there, it’s time to try connecting:

ubuntu$ ssh localhost

Since this is the first time you’re trying to connect using SSH, you’ll have to answer yes to the following question:

The authenticity of host 'localhost (::1)' can't be established.RSA key fingerprint is 18:4d:96:b3:0d:25:00:c8:a1:a3:84:5c:9f:1c:0d:a5.Are you sure you want to continue connecting (yes/no)? yes

… you’ll then be prompted for your own password (remember, the system treats such connection request as if you were connecting remotely, so it can’t trust you without confirming your password):

Warning: Permanently added 'localhost' (RSA) to the list of known hosts.greys@localhost's password:

.. and finally you’ll see the usual Ubuntu (Jaunty in this example) banner and prompt:

Linux ubuntu 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686

The programs included with the Ubuntu system are free software;the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law.

To access official Ubuntu documentation, please visit:http://help.ubuntu.com

Last login: Fri May 15 15:18:34 2009 from ubuntu

ubuntu$

That’s it, providing you have your networking configured and you know your IP address or hostname, you can start connecting to your Ubuntu box from remote systems, using the same command. Enjoy!

Recommended books:

See also:




Ubuntu 9.04 Jaunty Jackalope screenshots

I’m finally getting ready to start publishing some tips with screenshots, so today it’s just a humble screenshot tour of my fresh Ubuntu 9.04 install.

Let me know if you struggle with any graphics desktop functionality, and I’ll try my best to help and show it with screenshots.

By the way: I really like one of the new community themes which come with Ubuntu 9.04, it’s called the Dust theme.

[nggallery id=1]




Unix Tutorial Digest: Interesting Links #1

Every week there’s a few announcements or articles which I find particularly interesting, and so I’ve decided to share them with you. I’m not a Unix guru (yet), but if any of the listed materials require further explanation – do feel free to ask and I’ll be glad to help.

Ubuntu 8.04.1 release

About a week ago, the first update to Ubuntu 8.04 was announced – Ubuntu 8.04.1 TLS. I have completed my experiment of using Ubuntu Hardy as my desktop OS a few weeks ago, and so haven’t upgraded yet – but I think this release is not so useful for anyone who’s been automatically updating their system – it’s just another milestone and a way to download a complete Ubuntu 8.04.1 as one image.

The highlights for me would be Firefox upgraded to the final 3.0 release and Gnome upgrade (it’s 2.22.2 in this release).

Gentoo Linux 2008.0 release

For some of you, it’s probably been a long-awaited release. Move to 2.6.24 kernel provided support for much more hardware, and this is bound to look good with the updated and much improved Gentoo installer.

Read more in the official Gentoo Linux 2008.0 announcement.

Cache poisoning vulnerability in DNS

Dan Kaminsky has found quite a nasty weakness in DNS implementations: deficiencies in the DNS protocol and common DNS implementations
facilitate DNS cache poisoning attacks.

Thanks to the seriousness of the problem and a great coordination, most of the vendors were given the time to publish a fix, so the Vulnerability Note VU#800113 contains a comprehensive list of vulnerable implementations of DNS (both server and client sides are affected, by the way!) and links to fixes provided by various vendors.

Whether you’re managing a server farm or just a Linux desktop – be sure to update!

Wine 1.1.1 release

Things are going much faster with Wine development after the 1.0 release – it didn’t take long for the 1.1 to appear, and now almost every other week brings another great update with tons of bugs fixed.

Wine 1.1.1 release includes more than 50 bugfixes and hundreds of changes since Wine 1.1.0, notably the fixes for Adobe Photoshop CS3 and Microsoft Office 2007 installers, as well as improved video playback and many other improvements.




What UUIDs Are and How To Use Them in Ubuntu

If you tried installing or upgrading Ubuntu recently, you probably noticed that all the storage devices are now using UUID – Universally Unique IDentifiers. I’m not claiming to know everything there is to know about UUIDs, but have become quite comfortable managing them lately, so hopefully this post will help you achieve the same.

What is a UUID exactly?

UUID is a Universally Unique IDentifier. It’s a identification code given to each storage device you have on your system, aimed to help you uniquely identify each device no matter what.

UUIDs can be used to identify DVD drives, removable media (USB flashsticks) and each partition on any of your hard drives.

This is how a typical UUID looks:

c73a37c8-ef7f-40e4-b9de-8b2f81038441

Why use UUID?

Reason 1: Truly unique identification

UUID is the only way to guarantee you recognize the same drive or partition no matter what. For example, if you introduce to your system another hard drive, this might upset quite a few things, starting with the way your system boots up (or stops booting up upon the new drive introduction). Using UUID helps remedy most of such things.

Reason 2: Device names are not always persistent

Automatically assigned device names in your system are not consistent, they are according to the order of loading the kernel modules up during (most usually) the startup time, and thus the names will look different if you boot with one of your USB flashsticks attached and then reboot after you plug it out.

Generally, I’ve also found UUIDs really useful for mounting my removable media – I have a USB reader, one of the 24-in-1 kinds – it supports various types of cards and I use UUID to always mount the same card at the same location.

Reason 3: Most critical functionality of your Ubuntu system already depends on UUIDs

GRUB – your boot loader – relies on UUIDs as well. If you look into /boot/grub/menu.lst file, you’ll find something similar to this:

title Ubuntu hardy (development branch), kernel 2.6.24-16-generic
root (hd2,0)
kernel /boot/vmlinuz-2.6.24-16-generic root=UUID=c73a37c8-ef7f-40e4-b9de-8b2f81038441 ro quiet splash
initrd /boot/initrd.img-2.6.24-16-generic
quiet

List UUIDs for all your devices

If you are using one of the recent releases of Ubuntu (UUIDs have been there since Edgy), you can use the blkid command to get a list of all the drives and partitions along with their UUIDs:

ubuntu# blkid
/dev/sda1: UUID="2220CF8220CF5B83" TYPE="ntfs"
/dev/sda2: UUID="48E81F29E81F14B2" LABEL="DRIVE-D" TYPE="ntfs"
/dev/sdb1: UUID="c73a37c8-ef7f-40e4-b9de-8b2f81038441" SEC_TYPE="ext2" TYPE="ext3"
/dev/sdb5: TYPE="swap" UUID="abe7529e-dcd5-4afc-b714-05569dbcd30b"
/dev/sdb6: UUID="f34c8c7c-a020-4a14-8c97-257180240250" SEC_TYPE="ext2" TYPE="ext3"
/dev/sdb7: UUID="8fa274ca-5b22-411f-b5da-7469c1f276da" SEC_TYPE="ext2" TYPE="ext3"
/dev/sdc1: UUID="1e36f323-c4e5-4f55-ba0a-838643550bf9" TYPE="ext3" SEC_TYPE="ext2"
/dev/sdc2: UUID="83aa92e4-4df4-4aab-80f3-9bbb447e0459" TYPE="ext3" SEC_TYPE="ext2"

As you can see, I’ve still got a few NTFS partitions as I’m slowly migrating my data from Windows after my switch to Ubuntu desktop a couple months ago.

Get UUID for a particular device

If you know a device name and just want to confirm the UUID for it to later use it in /etc/fstab, here’s how you can do it using vol_id command:

ubuntu# vol_id -u /dev/sdb1
c73a37c8-ef7f-40e4-b9de-8b2f81038441

That’s all I can think of so far. I know a few more things about UUID which I’ll share in a separate post, but it’s a start.

Have you got any more great ideas and tips for UUID? Let me know and I’ll be sure to share them with others in the future posts.

Related books

If you want to learn more, here’s a great book:


ubuntu-kung-fu-practical-guide
Ubuntu Kung Fu

See also:




Ubuntu 8.04 (Hardy Heron) released!

Ubuntu 8.04 TLS

For all of you who were waiting for the next release of Ubuntu, it’s finally here! I’ve been using the beta of Ubuntu 8.04 (Hardy Heron) for the past month or so, and found it an excellent release to work with.

Ubuntu 8.04 links: