Ubuntu Installation :: Two-Factor Authentication On Dm-crypt/LUKS?
May 15, 2010
Since i'm on-the-road a lot encryption is crucial, with windows i've always used TrueCrypt and DiskCryptor, this is very easy to setup and allows me to create usb/cd devices that i can boot off and contain a keyfile, on boot it also requires a passphrase. Currently all i need to do is boot from harddisk and enter my passphrase. I would like to be able to boot from external device (in this case USB) that contains the bootloader and an integrated keyfile, also it should requist the passphrase. I found a guide on how to achieve two-factor authentication with dm-crypt on feisty but it's quite an old guide and is realy realy complicated for a newbie
It seems I've run into a bit of a problem. I recently upgraded to the latest kernel 2.6.32-24-generic (x86) but when I reboot into the new kernel and type in my password the system hangs, same when using a keyfile on the root file system.to give an outline of how the disks are setup.3 hard drives
I'm simply interested in a more basic discussion of why one would choose one of these methods over the other. What do they offer that the other does not? I'll start with what I know:
- dm-crypt/LUKS --- included in a lot of install images already; in other words, perhaps easier to implement on a fresh install - TrueCrypt --- multiple encryption algorithms possible
For me... I have no need for Windows compatibility, though I do use OS X on a dual booting MacBook. I believe TrueCrypt woks with OS X, so that could be a bonus, though I can simply encrypt my home folder on OS X with it's own FireVault and be fine.My setup (after wiping and starting over) will probably be like so:
- /boot on it's own primary partition - / on it's own primary partition with logical partitions within --- /usr, /var, /etc, /opt, and the like on a logical partition --- /home on a logical partition
/home will surely be encrypted and I'm leaning toward encrypting the rest as well, though perhaps it's not necessary. I'm open to input there as well -- is there anything the leaks from normal application use into /var or /tmp that would make one lean toward just encrypting the whole thing?
I opened up TrueCrypt just to look at it and since I can't encrypt a whole partition without losing data... I pretty much have to encrypt from what? A live CD? This could be a drawback -- I think since TrueCrypt isn't coming on install disks, I'd have to go with an unencrypted (or dm-crypt/LUKS) root partition and then use TrueCrypt to make a container (or partition) for /home only. I can't think of another way to do this since I can't encrypt the whole disk as one entity with my dual booting situation...
I'm trying to have a LUKS encrypted partition mounted at startup and to have GDM ask for my key so it will decrypt. Now I followed [URL] to the letter. Except for now, I have it just mounted into /mnt/cryptohome so I'm not messing with my system. My problem is the one everyone mentions in the comments, ubuntu isn't asking for the LUKS key in the X display, it's asking in the first terminal (Ctrl-Alt-F1). This will not do. I need it to ask to mount my drive before I'm even asked to login, so eventually I can encrypt my /home.
When I upgraded from FC11 to FC12 of the encrypted raid partitions started to request password on boot (in FC11 not having references to encrypted md1 in fstab and crypttab, was enough for FC11 not to ask for passwords on boot) despite the fact that I removed /etc/crypttab and there is nothing in /etc/fstab relating to encrypted md1 (raid array). I want my machine to boot w/o asking me passwords for encrypted devices, and I will open and mount them myself manually after boot.
The distribution I've been using does not have a proper two-factor login scheme. The daft buggers have configured the system so that whomever is sitting in front of a machine is gifted with the entire list of user names having access to the system. This, of course, only requires them to guess only one of the factors instead of both. So while said system is still a two-factor system it's one whose security has been crippled down to a single-factor system. Does anyone know which distributions have proper two-factor authentication schemes for logging in users?
No, I will not name the distribution I'm using so that a 'fix' can be provided. If the distributions creators have been willing to knowingly bugger the security of the system for the sake of user laziness at the login then heaven only knows what other holes exist. I have neither the time nor the inclination to discover or ask what they might be and how to 'fix' them as well. Better to simply move on to a distribution who won't knowlingly bugger the security.
After upgrading to Natty Narwhal my Crypt Keeper app will not launch. I am now unable to access secure files. Has anyone had this issue after their upgrade to Natty Narwhal? If so, How were able to resolve this issue.
I'm trying to manually boot (from the GRUB console) into a system set up as follows: crypt partition -> LVM -> root LV, and I'm having some trouble figuring out how to do this from the GRUB console.
I have successfully manually booted a system which is set up as just LVM -> VG -> root LV. All I have to do is load the LVM module. In GRUB, that partition shows up as (hd0,gpt5). Once I load the GRUB LVM module, I can see the logical volume within the LVM as well. (My volume group name is "caesar", and the single logical volume is named "root".)
Code: Select allgrub> ls ... (hd0,gpt5) ... grub> insmod lvm grub> ls ... (lvm/caesar-root) ...
It's fairly simple to manually boot:
Code: Select allgrub> set root=(lvm/caesar-root) grub> linux /vmlinuz root=/dev/mapper/caesar-root grub> initrd /initrd.img grub> boot
Where I am having difficulty is in trying to insert crypt before LVM. I can set up such a scheme, and put a minimal installation on it, without issues. It's booting into it upon reboot that I can't figure out. Once I load the GRUB crypto, cryptodisk and luks modules, I can mount the crypto partition:
Attempting to decrypt master key... Enter passphrase for hd0,gpt5 (<long hex string here>): <type my password> Slot 0 opened grub> ls ... (crypto0) ...
At this point, GRUB sees the crypto partition as (crypto0). But the GRUB LVM module doesn't see "inside" of the crypto partition, so I don't see the root logical volume within the LVM listed; all I see is (crypto0).
Code: Select allgrub> insmod lvm grub> ls ... (crypt0) ...
Setting it as root doesn't work:
Code: Select allgrub> set root=(crypto0) grub> ls / error: disk `crypto0' not found.
So, How do I get GRUB to "see" LVM inside the crypto partition?
I am trying to backup my system with a script I found here. It gives me an error message of invalid blocking factor for --exclude=lost+found I have no idea what this means. I tried to search this form for that message and received no hits.
I installed on LUKS+LVM, and I want to preserve my /home without moving the data to any external media (I don't have any). My partition layout is as follows:
sda1: /boot sda2: encrypted volume (sda2_crypt) sda2_crypt: LVM volume group, with /, swap and /home.
Having many previous (sad) experiences with completely borked experiments and data loss, I've decided to try the trick in VirtualBox first. I've installed Debian (testing, netinst, Dec 2009) with encrypted LVM, and touch'd a file in my $HOME so that I'd know if the contents were preserved. Then proceeded to install Ubuntu 10.04.1 from the alternative CD. After the installer started and loaded some of the basic components (but before it entered the partitioner) I've switched to a shell and read a scroll of identification:
* Another concern; after the installation, I've noticed that the contents of my $HOME were overwritten by Ubuntu's default skeleton (pictures, desktop, music, templates, and other crap). The control file I've touch'd after installing Debian wasn't there.
I am currently running 8.10 with full-disk (excluding /boot) encryption. I am going to be installing 10.04 on a new laptop, and I was wondering whether it supports multi-factor authentication. Specifically, I would like to have a keyfile on USB/SD memory that is required, in addition to the password, to decrypt the disk. Anyone know of a guide out there? So far my searches have turned up nil.
Is there any way to specify the bit strength for LUKS when one is installing OpenSUSE 11.4? I've tried to find it (because imho 256 bit aes is a bit high for what little i do with my netbook) but I have not. I was going to try to control+alt+F4 to a shell and create the partition setup and create the LUKS container and see if that works but in the past, trying that doesn't work either because 1) the installer doesn't ask for the LUKS password or 2) it asks, setup finishes normally, but yet I then get what seems to be random boot errors like some times the /home doesn't mount, sometimes the swap doesn't enable, etc.
Anyone care to give some input? I've been around and around the installer and can't seem to find a way to do it.
Root LUKS to be broken by apt-get update? This did happen to me on 3 different laptops, both on previous install (from Debian 8.0), and also on clean installs (Debian 8.1), repeatedly.
When I reboot, grub starts, but then it cannot find the root file system (I end up with the emergency console).
Code: Select allLoading Linux 3.16.0-4-amd64 ... Loading initial ramdisk ... Loading, please wait... [many seconds waiting] ALERT! /dev/mapper/sda2_crypt does not exists. modprobe: modprobe ehci-orion not found in modules.dep
This is the most simple, clean, conservative install ever, no closed driver.
But LUKS on the root file system:
Code: Select allone ext4 partition on /boot one ext4 partition on / (trough LUKS, all defaults)
There is no LVM.
All the 3 laptops killed at different time, when updating. Clean install is fine until the first update.
Booting on the rescue system allows me to see everything.
Code: Select all$ update-grub Generating grub configuration file ... Found background image: /usr/share/images/desktop-base/desktop-grub.png Found linux image: /boot/vmlinuz-3.16.0-4-amd64 Found initrd image: /boot/initrd.img-3.16.0-4-amd64 No volume groups found
I would like to configure my Debian Jessie system in this way.
1) /boot on /dev/sda1 2) everything else on /dev/sda2
I want to encrypt the second partition with LUKS. And then install over it a LVM volume. Inside the LVM volume i will create the / (root), /var, /opt and /home virtual partitions. In this way, i'll get asked only once for the password to decrypt all partitions. Because if i don't use LVM, then i'll get asked for the password for each encrypted partition.
I can follow and understand almost everything of this HOW-TO for Archlinux: [URL] ....
Only two passages are unclear to me:
1) Configuring mkinitcpio
I don't understand what i should do here in order to complete this. What should i do in Debian to configure "mkinitcpio"? what is the equivalent thing to do here?
I thought that the kernel would automatically recompile itself with all installed modules on the Debian system, once cryptosetup/LUKS or LVM2 get installed.
2) Configuring the boot loader
I don't understand what should i write in /etc/default/grub. Will GRUB automatically load the LUKS and LVM2 modules? Also, I don't think that i could boot the system in this way:
I am trying to setup 2-factor authentication for SSH with PAM. Its working well, but if the password is incorrect, it does not ask for validation code, but rather asks for the password again. Any way not to warn about an incorrect password?
and I'm dumped into recovery mode. However, if I remove these mounts from /etc/fstab via comments, I can wait for the system to boot (which it does very quickly) then mount the mapper devices myself. So what is going on? Has something changed wrt logical volumes, or is this just systemd? I can live with manual mounting, but any advice on resolving the automatic mounting situation would be great.
I'm looking to buy hardware to run my company's software.It usually runs on rack systems, but I want something that I can take with me on the plane, so a Small Form Factor system is what I'm looking for. My colleagues just stay in the server room, so don't know what to advise to take on the road ...
Here are the minimum specs:
- compatible with redhat 5.3 - 4GB of ram, extensible to 8GB - 64 bits Intel processor, 2 or 4 cores.
After falling out with KDE4.2.4 and using fluxbox for a while, I was sufficiently impressed with my experiments with KDE4.4.3 in slackware 13.1 that I decided to go back to KDE. In particular I'm keen to use plasma netbook on my eee pc 1000H.
But I've hit an annoying snag. The problem is that if I set it to use plasma netbook (System settings>Desktop>Workspace>Form factor>Netbook) it works just fine for the rest of that session but next time I startx it goes back to the Desktop form factor.
The strange thing is that this didn't used to happen, it only started recently and to the best of my knowledge I haven't made any other significant changes or updates to the system. I tried removing the ~/.kde dir and letting kde setup from scratch but that didn't help.
I'm trying to upgrade my Win8/Wheezy 64-bit machine to Jessie 8.1 by installing from the amd64-bit netinstall iso image on a USB flash drive. I had done the previous, Wheezy, install on a disk partition that was whole-partition LUKS/LVM drive, with separate logical partitions for swap, root, and home.
Before doing the upgrade, I booted to the BIOS to ensure that my UEFI system had the correct, CSM and Legacy modes enabled in it, so that installer would boot using the non-efi BIOS mode.
Step one of the upgrade was to boot the netinstall and enter the rescue mode so that I could manually do the cryptsetup/LVM business. When I returned to the installer, I mounted the now-recognized logical partitions normally, choosing to format only the swap and / partitions.
During the entire process, I had to go into rescue mode one more time to manually mount the unencrypted /boot partition, along with my /home partition. I copied a backup of my old /etc/crypttab from the latter, and after returning to the installer, finished the install. That finish included installing grub on my hard drive's main boot partition.
Everything seemed to finish with no problems. However, when I try to boot the debian bootloader, I get tossed to grub rescue with the message that '/grub/x86_64-efi/normal.mod' doesn't exist. At this point I returned to the installer, mounted the /boot partition, and saw that there grub-install didn't create that an x86_64-efi directory at all. Instead, it had created an i386 directory. The exact name escapes me at the moment.
I *think* that my install was clean other than the last bit that was related to installing the bootloader. How to reinstall the bootloader in such a way as to make all of this work.
I have a compressed backup that I want to crypt and upload to a remote server through ssh once in a while. The problem is with the size, more than 4 GB. If the connection drops how does scp know to resume? This should be an automated process.
I just bought a new laptop which will be running SSD (Corsair 120GB) as the boot drive and would like to migrate my OS to the new system. One of my requirements is full-disk encryption. I work with proprietary client data and need to encrypt the new drive, its swap partition, everything except for /boot. I've read instructions for doing this from the alternate install CD, but my OS is disturbingly customized (started out as 10.04) and it would take months to rebuild everything. I keep remastersys (-dist) ISOs to ensure I don't have to go through that process, but the ubiquity installer does not appear to have the option of doing disk-level crypt during the installation process. I can boot the ISO into CLI, but don't know how to run the alternate installer from there.
The in build cipher algorithms that are in the kernel are not critically secured, the best, I think, supports 384 bit encryption.
So I was looking forward towards stuff like DSA or very preferably OTP cipher with like... 8192 bit encryption using DM, I know it sounds insane, but so is the data. I want it to be uncrackable for the fastest supercomputer combined till 2070.
At first the problem was that the old volume group (containing all logical volumes for both physical volumes) had the same name as the new volume group. I did a reinstall where I changed the name and ran vgreduce --removemissing debian which seems to have removed all logical volumes from the old volume group.
When I try to unlock the drive in Gnomes Disk Utility I get "Incorrect Passphrase. Try again." but I *know* it's the right password, and I don't get any error when changing the password so that seems to be possible.
I found the oldest archive in /etc/lvm/archive/ and manually edited it to remove any stuff about the old LVs and PVs. Then I did vgcfgrestore --file VG_backup.vg groupname. With the help of blkid I edited /etc/fstab and /etc/crypttab to mount the disk at startup.
I can't believe that I did not write down the password to my encrypted volume. Had not rebooted in a long time so I had not typed it and now that I rebooted I don't remember what is was.
Is there any way to automate the trial of different passwords? I remember the basic structure of what the password was so if somehow I could automate trying passwords from a list I may have a good change to recover my volume.
If/when I do remember the password. Is there a way to change the password on an encrypted volume? I need to make it something I will remember for sure... or write it down somewhere safe..
I'm not a mathematician or cryptographer, only an end user of the technology trying to determine the "best" or safest future proof option to go with for long term archival while also maintaining reasonable performance with dual opteron ~2GHz or similar setup. I've noticed aes-cbc-essiv seems to be the default choice in various installers for reasons of backwards compatibility while others are moving towards XTS since the standardization.