Posts Tagged → linux
Finger print reader vs. encrypted home
Modern Linux distributions allow you to encrypt your home directory. When logging in the user’s password is used to decrypt the home directory. This works great unless you are using one of the many other options that PAM offers for authentication. PAM (Pluggable Authentication Modules) is an extensible authentication system, currently standard on most modern Unix systems including Linux.
On my Thinkpad notebooks I am used to the comfort of the finger print reader instead of having to type and remember passwords. As far as I know support for decrypting the home directory using your finger print has not been developed yet. Thus my preferred solution is:
- For initial login after use a password and decrypt home. This happens very seldom anyway.
- For everything else (sudo, screensaver, etc.) use the finger print reader
- Whenever the finger print is not available (ssh, injured finger, etc.) fall back to password
Luckily using pam this can be easily achieved. The solution below has been tested on Ubuntu but it should work with slight adoptions on most linux distributions. If you have configured an alternative authentication method like a finger print reader (or if your distribution or an setup script has done this for you) you will probably have edited /etc/pam.d/common-auth. Copy this file now e.g. to /etc/pam.d/common-auth-pass-only and remove the lines that you added during configuration in the new file. I am using fprint so I had to remove the following line:
auth [success=3 default=ignore] pam_fprintd.so
Now configure your login manager to use the password-only-configuration by substituting
@include common-auth through @include common-auth-pass-only. Your login manager is probably configured in one of those files:
/etc/pam.d/lightdm /etc/pam.d/gdm /etc/pam.d/kdm
You might want to do the same for /etc/pam.d/sshd or others as well.
If you know about a way to support the finger print reader during initial login in combination with an encryted home I’d be happy to hear about it in the comments.
Are you stuck in Debian/MySQL/Charset/Collation hell?
So while Debian still hasn’t changed the MySQL default caracter set and collation to utf8, we all know that the first thing to do on a vanilla Debian MySQL installation is to add the following utf8.cnf file to /etc/mysql/conf.d/:
[mysqld] default-character-set=utf8 default-collation=utf8_unicode_ci
However, if for some reason you didn’t do that and have used software which hasn’t been consistently explicit about character sets and collations, you end up with a nice mess of character sets and collations.
There is a great post on serverfault which helps you out. It comes down to one command which will take some time based on the size of your database:
mysql -B -N --user=user --password=secret -e "SELECT DISTINCT \ CONCAT( 'ALTER TABLE \`', TABLE_SCHEMA, '\`.\`', TABLE_NAME, '\` CONVERT \ TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;' ) FROM \ information_schema.COLUMNS WHERE TABLE_SCHEMA != 'information_schema';" \ | mysql --user=user --password=secret
Update:
And of course you need to alter the defaults for existing databases as well:
mysql -B -N --user=user --password=secret -e "SELECT DISTINCT \ CONCAT( 'ALTER SCHEMA \`', SCHEMA_NAME, '\` CHARACTER SET utf8 COLLATE \ utf8_unicode_ci;' ) FROM information_schema.SCHEMATA where SCHEMA_NAME \ != 'information_schema';" | mysql --user=user --password=secret
First steps with Chef
Today, Jens and I got to play with Chef which supposedly is the hot sh$&!t when it comes to infrastructure automation and such. Installing your own Chef server seems hard at first but will work in the end.
If you’re using Debian, the APT sources will save you some headaches. Just add
deb http://apt.opscode.com/ squeeze main
to your /etc/apt/sources.list and do something like
wget -qO - http://apt.opscode.com/packages@opscode.com.gpg.key | sudo apt-key add - sudo apt-get update
to be sure to be getting what you asked for. Then, a little sudo apt-get install chef will do the trick to set up a client and sudo apt-get install chef-server will supercharge your node with a fully blown chef server, including but not limited to CouchDB, Solr, RabbitMQ and other fancy stuff. (You’ll want to do this on two different nodes, so use Virtual Box or something.)
After you’ve set up two nodes like that, try following the rest of the instructions in this tutorial and do the first cookbook example, then you’ll have come as far as we have today.
I will update this post as we dig deeper – hopefully later this week.
Bazaar over chrooted sftp
How to set up bzr for chrooted sftp users
How to restrict a user’s access to sftp://.../var/bzr
For the prototyping editor itself and for a lot of our clients’ projects we are heavy Bazaar users at pidoco° to manage our distributed workflow. When we started some years ago we just installed bzr on one of the test servers where all of the developers had ssh access anyway. We put the repositories in /var/bzr and used sftp to checkout/push/pull source changes. This was handy as a sftp server comes with openssh installed.
As the team grew over the years we got to a point where we wanted to give new developers access to the bzr repositories without giving them full ssh access. However we did not want to have to change all the urls for existing repositories. Luckily this can be achieved easily since Debian Lenny.
Per Server Settings
On our scm server we have a user group called bzr that grants read/write access to most of the repositories (except of some personal or release branches) to all users with bzr access. And now we added the group sftponly. All users in this group will be restricted to sftp access only instead of a full shell.
sudo addgroup sftponly sudo addgroup bzr
You probably have to add ‘/usr/lib/sftp-server’ to /etc/shells to make it a valid shell, eg. like this:
root@host # echo '/usr/lib/sftp-server' >> /etc/shells
The following settings in /etc/ssh/sshd_config force the internal sftp server to be used by openssh and change the root directory for all users in the group sftponly to /var/chroot. Make sure to restart sshd afterwards.
Subsystem sftp internal-sftp
Match Group sftponly
ChrootDirectory /var/chroot
AllowTCPForwarding no
X11Forwarding no
ForceCommand internal-sftp
Up to now our repositories have been in /var/bzr. These need to be moved to /var/chroot/var/bzr to let the sftponly users access them. /var/chroot needs to have root:root as owner for openssh to work correctly. For the existing ssh users we add a symbolic link to keep the old paths working:
sudo mkdir /var/chroot sudo chown root:root /var/chroot sudo mkdir /var/chroot/var sudo mv /var/bzr /var/chroot/var sudo ln -s /var/chroot/var/bzr /var/bzr
Per User Settings
giving the user username sftp access, but nor ssh access:
USERNAME=username # give the user a name
sudo adduser ${USERNAME} # add user and data to system
sudo usermod -s /usr/lib/sftp-server ${USERNAME} # disallow ssh/bash, allow ssh/ftp (sftp)
sudo adduser ${USERNAME} bzr # allow group access to most bzr folders
sudo adduser ${USERNAME} sftponly # disallow access to /, allow access to /var/bzr
This changes user’s shell to sftp-server.
Result
As a result of these settings both normal ssh users as well as restricted users in the sftponly group can use the same url for their shared repositories
bzr checkout sftp://my.domain/var/bzr/my_repository. By using chroot however users in the group sftponly are restricted to using sftp and can only access the folders in the bzr subdirectory.
Sources
In the Debian Administration Weblog you can find information on how to setup an OpenSSH SFTP chroot() with ChrootDirectory and on how to restrict users to SFTP only instead of SSH.


