Shallow Thoughts : tags : security

Passwordless ssh with a key: the part most tutorials skip

I'm working on my Raspberry Pi crittercam again. I got a battery, so it can be a standalone box -- it was such a hassle to set it up with two power cords dangling from it at all times -- and set it up to run automatically at boot time.

But there was one aspect of the camera that wasn't automated: if close enough to the house to see the wi-fi router, I want it to mount a filesystem from our server and store its image files there. That makes it a lot easier to check on its progress, and also saves wear on the Pi's SD card.

Only one problem: I was using sshfs to mount the disk remotely, and ssh always prompts me for a password.

Now, there are a gazillion tutorials on how to set up an ssh key. Just do a web search for ssh key or passwordless ssh key. They vary a bit in their details, but they're all the same in the important aspects. They're all the same in one other detail: none of them work for me. I generate a new key (various types) with no pass phrase, I copy it to the server's authorized keys file (several different ways, two possible filenames), I try to ssh -- and I'm prompted for a password.

After much flailing I finally found out what was missing. In addition to those two steps, you need to modify your .ssh/config file to tell it which key to use. This is especially critical if you have multiple keys on the client machine, or if you've named the file anything but the default id_dsa or id_rsa.

So here are the real steps for making an ssh key. Assume the server, the machine to which you want to ssh, is named "myserver". But these steps are all run on the client machine, the one from which you want to run ssh.

ssh-keygen -t rsa -C "Comment"

ssh-keygen -t rsa -C "Comment" -f ~/.ssh/id_rsa_myserver

Now copy your key to the remote machine:

ssh-copy-id -i .ssh/id_rsa_myserver user@myserver

Then on the local machine, edit ~/.ssh/config, and add an entry like this:

Host myserver
  User my_username
  IdentityFile ~/.ssh/id_rsa_myserver

Update July 2021: You may need one more step. Keyed ssh will fail silently if it doesn't like the permissions in the .ssh/ directory. If it's still prompting you for a password, try, on the remote server:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Eliminating strict host key checking

Of course, you can use this to go the other way too, and ssh to your Pi without needing to type a password every time. If you do that, and if you have several Pis, Beaglebones, plug computers or other little Linux gizmos which sometimes share the same IP address, you may run into the annoying whine ssh is prone to:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

You're supposed to be able to turn off this check with StrictHostKeyChecking no, but it doesn't work. Fortunately, there's a trick I discovered several years ago and discussed in Three SSH tips. Here's how the Pi entry ends up looking in my desktop's ~/.ssh/config:

Host pipi
  HostName pi
  User pi
  StrictHostKeyChecking no
  UserKnownHostsFile /dev/null
  IdentityFile ~/.ssh/id_pi

Privacy Policy

I got an envelope from my bank in the mail. The envelope was open and looked like the flap had never been sealed.

Inside was a copy of their privacy policy. Nothing else.

The policy didn't say whether their privacy policy included sealing the envelope when they send me things.

Bank Website Security

Conversation today with a bank person over the phone:

Me: Can I get you to start sending me statements in the mail again?

Bank rep: We've gone all online now! It's so easy and convenient!

Me: I prefer to limit how much banking I do online, for security reasons.

Bank rep: Oh, but we have two factor security! It's secure! You can change your account name so it doesn't have to be your social security number -- AND you can set a security question so only you can reset your password!

Me: Right.

(The conversation progresses. She promises to send me a statement, but meanwhile it develops that there are some questions I need answered that can't be done easily over mail and require an online account. We proceed to set that up ...

Bank rep: ... and now you're at the password screen, right?

Me (reviewing the list of security questions): Um, you know that every one of your security questions is something that anyone could look up, right? Last 4 digits of driver's license? Last 4 digits of phone number? Last 4 digits of credit card?

Bank rep (astonished): What? Aren't there any that couldn't be looked up?

Me (scanning through list again): Well, the one on "last 4 digits of your best friend's phone number" at least requires guessing who your best friend is before they look up the number.

Seriously, every single one of their security questions was "last 4 digits of" something that's either a matter of public record, or something that's probably trivially available for $5 on shady websites.

Of course, you're thinking, you don't have to use the real 4-digit numbers for any of these. No, of course you don't! You can make up a number and use it as the answer for any of these.

In which case a better, more honest, security question would be: "Please enter a 4-digit PIN."

Creating and mounting a LUKS encrypted disk

But modern Gnome systems can't read cryptoloop. Or, rather, they can, but you have to fiddle with them as root -- they won't recognize and mount the filesystem automatically.

It turns out that's because the "new way", instead of cryptoloop, is to use a system called LUKS. But it has a few pitfalls, and there's no documentation about how to use it on a system that doesn't recognize it automatically. So here's some.

Creating a LUKS filesystem

Palimpsest, described below, no longer seems to exist. But it's just as easy to set up a LUKS filesystem with cryptsetup.

I'm using "SECRET" as the disk label; this is a name you'll use to mount the disk later. Of course, all these commands require root.

cryptsetup -v luksFormat --label SECRET /dev/TARGET_DISK_PARTITION

Update: This used to be enough to make the device available in /dev/mapper, but in 2024, you have to open it explicitly: sudo cryptsetup luksOpen /dev/PARTITION SECRET

Now your new encrypted device is available on /dev/mapper/SECRET. Next, create a filesystem on the encrypted device:

mkfs.ext4 /dev/mapper/SECRET

Finally, make sure you can mount it:

mount /dev/mapper/SECRET /mnt

This next part, written in 2010, is now obsolete:

Mounting a LUKS filesystem from Gnome or Another Desktop

In theory, you should be able to plug in the device and after a few seconds you'll be prompted for your password. If it doesn't, which sometimes happens, try again, wait longer this time and cross your fingers. If it still doesn't mount, try the command-line version in the next section. Even if it doesn't work, you might get a useful error message.

Mounting a LUKS filesystem from the commandline

Assuming you used the partition label "SECRET" when you created the LUKS encrypted partition, the physical partition is on /dev/sdb2, and you want to mount it on /media/SECRET (which already exists), these two commands (as root) will mount it:

sudo cryptsetup luksOpen /dev/sdb2 SECRET
  (prompts for sudo password)
  (prompts for LUKS password)
sudo mount /dev/mapper/SECRET /media/SECRET

Easy -- yet a bit frustrating. There seems to be no way to do this purely through /etc/fstab, so you have to remember the cryptsetup command, or write an alias or script to do the two steps for you. And you always have to type your sudo password as well as the password for the filesystem, whereas with cryptoloop you only needed the filesystem's password.

In the end, I'm not convinced LUKS is a win. But since it's so hard to manage cryptoloop filesystems from a Gnome desktop, it's probably worth hassling with LUKS if you need to be able to interoperate with Gnome.

Update: I wrote that yesterday. Today, maybe three weeks after I started using the card on a fairly regular basis to transfer personal files between home and laptop, I had a filesystem failure: I wrote to the card from the desktop, synced, unmounted, put it in the laptop -- and got I/O errors and "You must specify filesystem type" trying to mount it. I was able to fsck, and it apparently restored from an old journal -- including old data.

No loss here, because the card is just a copy of what was on the desktop machine. But the lesson here is: these encrypted cards are great for emergency backups. But you probably don't want to rely on one as your main storage for anything important.

"Joe-job" spam (forged From addresses)

The list owner posted a message about using good passwords so your account isn't hacked since that causes problems for everyone.

Of course, that's good advice and using good passwords is always a good idea. But I though this sounded more like a Joe-job spam, in which the spammer forges the From address to look like it's coming from someone else.

Normal users encounter this in two ways:

1. You start getting tons of bounce messages that look as though you sent spam to hundreds of people and they're refusing it.
2. You see spam that looks like it came from a friend of yours, or spam on a mailing list that looks like it came from a legitimate member of that list.

Since this sort of attack is so common, I felt the victim didn't deserve being harangued about not having set up a good password. So I posted a short note to the list explaining about Joe-jobs. But to make the point, I forged the From address of the list owner. Indeed, it got through Yahoo and out to the list just fine:

[ ... ] the spam probably wasn't from a bad password. It was probably just a spammer forging the header to look like it's from a legitimate user. It's called a "joe-job": http://en.wikipedia.org/wiki/Joe-job

To illustrate, I've changed the From address on this message to look like it's coming from Adam. I have not hacked [listowner]'s account or guessed his password or anything else. If this works, and looks like it came from [listowner], then the spam could have been done the same way -- and there's no need to blame the owner of the account, or accuse them of having a bad password.

Why does this work? Why doesn't Yahoo just block messages from user@isp.com if the mail doesn't come from isp.com?

They can't! Many, many people don't send mail from the domains in their email addresses. In effect, people forge their From header all the time. Here are some examples:

• You're using you@gmail.com, but you're using Thunderbird or Eudora or Evolution or something to read and send mail from home.
• You're on your computer at home, but you're sending work-related email from your work account.
• You're on your laptop, using Thunderbird or whatever, mailing from you@isp.com, but you're at a friend's house or a hotel or conference or somewhere.
• You're sending mail from a public terminal somewhere (eek, do people really type their mail info in to these things?)
• You're reading and sending mail from a mobile phone.
• You're sending mail from your own domain, me@mydomain.com, but you're at home or somewhere else other than wherever mydomain.com is hosted.

If mailing lists rejected posts in all these cases, people would be pretty annoyed. So they don't. But that means that now and then, some Joe-job spam gets through to mailing lists. Unfortunately.

(Update: The message that inspired this may very well have been a hacked password after all case, based on the mail headers. But I found that a lot of people didn't know about Joe-jobbing, so I thought this was worth writing up anyway.)

Quickie tutorial: Making an encrypted USB key or SD card

But that convenient small size also means it's easy to lose your USB key, or leave it somewhere. Someone could pick it up and have access to anything you put there. Wouldn't it be nice to encrypt it?

There are lots of howtos on the net, like this and this, but most of them are out of date and need a bit of fiddling to get working. So here's one that works on Ubuntu hardy and a 2.6.28 kernel. I'll assume that the drive is on /dev/sdb.

First, consider making two partitions on the flash drive. The first partition is a normal unencrypted vfat partition, so you can use it to transfer files to other machines, even Windows and Mac. The second partition will be your encrypted file system. Use fdisk, gparted or your favorite partitioning tool to make the partitions, then create a filesystem on the first:

mkfs.vfat /dev/sdb1

Update: On many distros you'll probably need to load the "cryptoloop" module before proceeding with the following steps. Mount it like this (as root):

modprobe cyptoloop

Easy, moderate security version

Now create the encrypted partition (you'll need to be root). I'll start with a relatively low security version -- good enough to keep out most casual snoops who happen to pick up your flash drive.

losetup -e aes /dev/loop0 /dev/sdb2
[type a password or pass phrase]
mkfs.ext2 /dev/loop0
losetup -d /dev/loop0

I used ext2 as the filesystem type. I want a Linux filesystem, not a Windows one, so I can store dot-filenames like .gnupg/ and so I can make symbolic links. I chose ext2 rather than a journalled filesystem like ext3 because of kernel configuration warnings: to get encrypted mounts working I had to enable loopback and cryptoloop support under drivers/block devices, and the cryptoloop help says:

WARNING: This device is not safe for journaled file systems like ext3 or Reiserfs. Please use the Device Mapper crypto module instead, which can be configured to be on-disk compatible with the cryptoloop device.

Now the filesystem is ready to use. Mount it with:

mount -o loop,encryption=aes /dev/sdb2 /mnt
[type your password/phrase]

Higher security version

There are several ways you can increase security. Of course, you can choose other encryption algorithms than aes -- that choice is up to you.

You can also use a random key, rather than a password you type in. Save the random key to a file on your system (obviously, you'll want to back that up somewhere else). This has both advantages and disadvantages: anyone who has access to your computer has the key and can read your encrypted disk, but on the other hand, someone who finds your flash drive somewhere will be very, very unlikely to be able to use it. Set up a random key like this:

dd if=/dev/random > /etc/loop.key bs=1 count=60
mkfs.ext2 /dev/loop0
losetup -e aes -p 0 /dev/loop0 /dev/sdb2 < /etc/loop.key

(Update: skipped mkfs.ext2 step originally.)

Then mount it with:

cat /etc/loop.key | mount -p0 -o loop,encryption=aes /dev/sdb2 /crypt

Finally, most file systems write predictable data, like superblock backups, at predictable places. This can make it easier for someone to break your encryption. In theory, you can foil this by specifying an offset so those locations are no longer so predictable. Add -o 123456 (of course, use your own offset, not that one) to the losetup line, and ,offset=123456 in the options of the mount command. In practice, though, offset doesn't work for me: I get

ioctl: LOOP_SET_STATUS: Invalid argument

Chase "Blink" RFID credit cards

Yes, it's RFID (Radio Frequency ID tags), the small low-power radio transmitters also used by Walmart and various other retailers, and in other applications such as company security badges/access cards (and, unfortunately, new passports in quite a few countries).

It seems a little odd to me that Chase's marketing implies that most people would think it's a good thing to have a credit card that can be charged easily without even taking it out of your wallet ... to have a card that can be charged from some distance away without your even knowing about it.

It's apparently easy and cheap to build an RFID credit card skimmer: Bruce Schneier has collected several articles about it, and in a later article he offers several links to articles on how to build your own RFID skimmer.

We called Chase right away and told them we didn't want the "Blink" cards. They said we could keep our old, non-RFID cards and continue to use them, and destroy the new ones. Whew!

Googling for links for this article, I found that we're not the only Chase customers to want to decline Blink.

For anyone wondering how secure this technology is, the recent debacle of the cracked Dutch RFID subway cards gives you an idea (Bruce Schneier, "Dutch RFID Transit Card Hacked"; The Register, "Dutch transit card crippled by multihacks", and a followup where the MBTA, Boston's transit agency, used the courts to muzzle three MIT students who were trying to present a paper at Defcon on the security holes in the MBTA's RFID-based pay system.

For anyone who gets stuck with an RFID credit card, here's how to make an RFID-blocking wallet, and how to make an RFID zapper.

New "Amabot" Phishing Scam Spoofing Amazon

But yesterday's was different. The URL was this:
http://www.amazon.com/gp/amabot/?pf_rd_url=http://211.75.237.149/%20%20/amazon/xec.php?cmd=sign-in

Check it out: they're actually using amazon.com, and Amazon has a 'bot called amabot that redirects you to somewhere else. Try this, for example: http://www.amazon.com/gp/amabot/?pf_rd_url=http://bn.com -- you start on Amazon's site and end up at Barnes & Noble.

When a family member got tricked by a phish email a few months ago (fortunately she became suspicious and stopped before revealing anything important) I gave her a quick lesson in how URLs work and how to recognize the host part. "If the host part isn't what you think it should be, it's probably a scam," I told her. That's pretty much the same as what Amazon says (#6 on their "Identifying Phishing or Spoofed E-mails" page). I guess now I need to teach her how to notice that there's another URL embedded in the original one, even when the original one goes to the right place. That's a bit more advanced. I suspect a lot of anti-phishing software uses the same technique and wouldn't have flagged this URL.

I reported the phish to Amazon (so far, just an automated reply, but it hasn't been very long). I hope they look into this use of their amabot and consider whether such a major phishing target really needs a 'bot that can redirect anywhere on the net.

Edit sources.list To Get Ubuntu Security Updates

After about a month with no security updates on any ubuntu machines (during which time I know there were security alerts in Debian for packages I use), I finally tracked down the answer.

It turns out that if you use synaptic, click on "Mark All Upgrades", then click on Apply, synaptic will pull in security updates. However, if you use the "Ubuntu Upgrade Manager" in the System->Administration menu, or if you use commands like apt-get -f dist-upgrade or aptitude -f dist-upgrade, then the sources which synaptic wrote into sources.list are not sufficient to get the security updates. (Where synaptic keeps its extra sources, I still don't know.)

When I asked about this on #ubuntu, I was pointed to a page on the Ubuntu wiki which walks you through selecting sources in synaptic. Unfortunately, the screenshots on the wiki show lots of sources that none of my Ubuntu machines show, and the wiki doesn't give you the sources.list lines or tell you what to do if synaptic doesn't automagically show the security sources.

The solution: to edit /etc/apt/sources.list and make sure the following lines are there (which some of the people on the IRC channel were kind enough to paste for me):

## All officially supported packages, including security- and other updates
deb http://archive.ubuntu.com/ubuntu hoary main restricted
deb http://security.ubuntu.com/ubuntu hoary-security main restricted
deb http://archive.ubuntu.com/ubuntu hoary-updates main restricted

deb http://archive.ubuntu.com/ubuntu hoary universe multiverse
deb http://security.ubuntu.com/ubuntu hoary-security universe multiverse
deb http://archive.ubuntu.com/ubuntu hoary-updates universe multiverse

Virus attack on Shallow-sky

Messages were sent to the list, ostensibly from his address, containing various attachments which were obviously Windows viruses. Unfortunately, I was out on a hike when the attack happened, so five of them slipped through before I found out about it and blocked his address in order to investigate further.

The virus turned out to be W32.Beagle.AG@mm (W32 is obvious, and f3ew tells me that "mm" stands for "mass mailing").

Pasc gave me a procmail rule to block this virus, to put in smartlist's rc.submit. It should have worked, but it didn't, so I ended up using a more general rule to block all base64 encoded attachments (that'll probably piss off some people who like to send images to one of our other lists, but Dave says he's asked them not to do that anyway and doesn't mind having the rule there).

Of course, the messages weren't really coming from Tim: he doesn't even use Windows (Mac and Sun, usually). It turns out they're coming from a Comcast address, which doesn't narrow things down much. There are nine @comcast.net addresses on the list, so I notified them privately, but it could easily be someone else or even someone off the list (though I suspect it's a list member, since it's someone who has Shallow in their addressbook).

I suppose I'll probably never know who it was. The "Tim" attacks have stopped (so I don't even know for sure that my filter works, though it worked for a test message I sent) but I've gotten two attempts spoofing Peter J (who is not currently on the list, so they bounced with "Not on accept list" before they could test the filter).

Grumble grumble Windows security grumble ...