The way .ssh/authorized_keys is typically used is not secure. Because using it securely is hard, and dumping in passwordless ssh keys is easy. I spent about 5 hours today locking down my authorized_keys.

rsync

The only easy case is a rsync of a single directory. Follow these good instructions.

If you need to rsync multiple separate directories, it's easy to find several documents involving a validate-rsync.sh. Do not use, it is insecure -- it allows rsync to be run with any parameters. Including parameters that allow the remote system to rsync in a new ~/.ssh/authorized_keys. Oops. (You can probably also trick validate-rsync.sh into running other arbitrary commands.) To be secure, you have to check the rsync parameters against some form of whitelist.

git

Locking down git should be easy. Use git-shell.

Unless you also want to be able to log in to an interactive shell on the same account. To do that, you'll need to generate a separate ssh key for git. Both git servers I use are named git.*, so I set it up like this in ~/.ssh/config on the client:

Host git.*
    IdentityFile ~/.ssh/id_rsa.git

Then on the server, I added the key to authorized_keys, prefixed with this:

command="perl -e 'exec qw(git-shell -c), $ENV{SSH_ORIGINAL_COMMAND}'"

(I also tried the simpler command="git-shell -c $SSH_ORIGINAL_COMMAND"; but it didn't work with alioth's old version of openssh, and I didn't want to worry about exposing SSHORIGINALCOMMAND to the shell.)

Before arriving at that, I took a detour to using gitosis. It can make it impressively easy to manage locked down git over ssh, but you have to fit how it does things. Including repository layout, and a dedicated account. So I spent several hours changing my git repo layout. In the end, I decided gitosis was too complicated and limiting for what I needed, but I do recommend checking it out.

svn

Like git, this is fairly easy, since svn provides svnserve. The svnbook documents how to use it in .authroized_keys. Basically, just use

command="svnserve -t"

A similar approach as used for git can be used here if you want to have a dedicated ssh key that causes svnserve to be run.

d-i daily builds

d-i has a d-i-unpack-helper that can be put in authorized_keys.

unison

Can probably be locked down similarly to rsync, but I haven't tried yet.

duplicity

The only way seems to not use duplicity over ssh at all, and instead use a different transport.

too hard

What if you want to allow locked down git, and a rsync, and maybe unison too, all to the same account? You'll end up with some nasty mismash of all of the above, and there are plenty more things using ssh as a transport that need other techniques to lock them down.

Until this becomes easier, a majority will just dump passwordless ssh keys in ~/.ssh/authorized_keys, creating exploitable trust paths that don't need to exist.

This is another case of a udev rule that took over an hour to figure out, and now seems very clear and obvious. Which probably means it won't next time I need it.

I have a bunch of USB to serial adapters, all using pl2303, all so cheap that there's no product ID or any way to tell them apart. This is cheaper than buying actual console server hardware nowadays. So how to know which ttyUSB* device is hooked up to what? The solution is to use the USB bus ID, which corresponds to the usb port the device is plugged into. My /etc/udev/rules.d/z25_persistent_usb_serial.rules:

SUBSYSTEMS=="usb", ID=="3-2", KERNEL=="ttyUSB*", NAME="ttyUSB_front_upper"
SUBSYSTEMS=="usb", ID=="2-2", KERNEL=="ttyUSB*", NAME="ttyUSB_front_lower"

The ID numbers can be found in dmesg.

I dug up an old radio and threw this together tonight. It's been done before, but the scripts out there seemed overly complex and didn't use alsa. Here's how I did it:

• radiorecord is a shell script to record a given number of minutes from the radio to an ogg file.
• crontab to schedule when to record shows

Of course, this assumes that the station doesn't move shows around and that the times are in sync. To do this really right, I'd need a radio programming data source, and some post-processing to identify exactly where the gaps are between programs.

As the first step in moving my automated d-i install testing away from the dilab and over to emulation, I've added support to the d-i regression tester (digress) to use qemu for serial-console based CDROM installation tests. It was fairly straightforward to do that, since digress already supported bochs and hercules.

I don't currently have an enourmous fast machine I can run qemu on. Actually, all of my servers, including my only amd64 server, have xen on them, which isn't ideal in combination with qemu (no kqemu..). So I thought I'd put this out as a howto, in the hope that lots of people will set up their own automated tests. If you do, please mail me and let me know, and I will aggregate all the tests together into a nice status page.

Here's how to set it up:

• sudo apt-get install qemu subversion libexpect-perl expect lockfile-progs
• sudo apt-get install kqemu-modules-2.6.18-4-686 # or similar, using unstable
• sudo modprobe kqemu
• svn co svn+ssh://svn.debian.org/d-i/trunk/scripts/digress
• Now edit digress/schemes/qemu/common, and set ISO to point to the CD image you want to test. You may also want to tune QEMU_DISK_SIZE, QEMU_EXTRA_PARAMS, STAGE_1_MAX_TIME, STAGE_2_MAX_TIME, and USER_PASSWORD. digress's README has more details about all the config options.
• Also edit digress/schemes/qemu/d-i, and change "url=kodama" to control where d-i will download its preseed file from. Until qemu bug #414342 is fixed, it can't support colons or slashes in the url to the preseed file, so the example is taking advantage of the default url guessing in d-i, which will look in eg http://kodama/d-i/etch/./preseed.cfg. Put in your hostname and set up a preseed file. digress/preseed.cfg is a reasonable starting point.
• To start a test, run ./test-harness qemu d-i
• The test will proceed automatically; digress will hit Enter at any prompts. Your preseed file should take care of any other choices.
• To cron the test, run cd ~/digress; ./daily-tests qemu d-i (be sure to update the CD image too). This will drop logs into digress/logs, and if you put that directory up on the web, I can produce a nice status page.

(Wonder if I should make a package of digress?)

A few ideas for things to test:

• netinst iso
• businesscard iso
• netboot mini iso
• true netboot (qemu -boot n)
• gnome desktop install
• kde desktop install
• xfce desktop install
• web server install
• lvm
• raid
• small disk
• lowmem
• amd64
• lilo
• all kinds of fun combos of the above, like lowmem gnome+web server install on lvm

random tip: redirecting alsa to usb sound card

This took a bit too much work to figure out so here it is. If you're like me and had to buy a usb sound card (nearly as sensible a name as a cable modem) since the laptop's onboard headphone jack broke, and would like to have that card used by default when it's plugged in, but otherwise have builtin card be used, create an /etc/udev/rules.d/00_local.rules containing:

# Default to using additional (USB) sound cards when they are available.
KERNEL=="pcmC[D0-9cp]*", ACTION=="add", PROGRAM="/bin/sh -c 'K=%k; K=$${K#pcmC}; K=$${K%%D*}; echo defaults.ctl.card $$K > /etc/asound.conf; echo defaults.pcm.card $$K >>/etc/asound.conf'"
KERNEL=="pcmC[D0-9cp]*", ACTION=="remove", PROGRAM="/bin/sh -c 'echo defaults.ctl.card 0 > /etc/asound.conf; echo defaults.pcm.card 0 >>/etc/asound.conf'"

Only programs started after the sound card is plugged in will use it of course, and this might not work if you have it plugged in while booting.