Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Cryptsetup is not working right

If none of the specific sub-forums seem right for your thread, ask here.
Post Reply
Message
Author
mrjpaxton
Posts: 18
Joined: 2021-07-09 02:35
Been thanked: 2 times

Cryptsetup is not working right

#1 Post by mrjpaxton »

Hi, I have a strange issue.

So I'm running Debian stable with a backported kernel 5.10.0-0.bpo.7-amd64 I'm and trying to open a LUKS2 encrypted partition. I know for a fact, 100 percent, that my password is correct, since I have also tested it successfully in a Debian LXQT live environment without the backported kernel.

But cryptsetup refuses to open it each time with my installed OS. The command I use is: `cryptsetup open /dev/disk/by-partlabel/filebox filebox`. It gives me "No key available with this passphrase." Any ideas what could be happening?

I do want to mention that this installed OS can, in fact, decrypt the LUKS root partition on my laptop just fine every time during boot. It's just that whenever I try cryptsetup on removable media, it just doesn't work... I don't get it.

mrjpaxton
Posts: 18
Joined: 2021-07-09 02:35
Been thanked: 2 times

Re: Cryptsetup is not working right

#2 Post by mrjpaxton »

So I was just reminded upon looking up solutions that there is a `cryptdisks_start` and `cryptdisks_stop` command.

By some miracle, putting this line in `/etc/crypttab`:

Code: Select all

filebox /dev/disk/by-partlabel/filebox none luks,discard
And then running `cryptdisks_start filebox` and entering in the password there actually works! Doesn't actually solve the problem with `cryptsetup` not working, but this is a great solution at least.

User avatar
cds60601
df -h | participant
df -h | participant
Posts: 706
Joined: 2017-11-25 05:58
Location: Florida
Has thanked: 129 times
Been thanked: 60 times

Re: Cryptsetup is not working right

#3 Post by cds60601 »

mrjpaxton wrote:Hi, I have a strange issue.

So I'm running Debian stable with a backported kernel 5.10.0-0.bpo.7-amd64 I'm and trying to open a LUKS2 encrypted partition. I know for a fact, 100 percent, that my password is correct, since I have also tested it successfully in a Debian LXQT live environment without the backported kernel.

But cryptsetup refuses to open it each time with my installed OS. The command I use is: `cryptsetup open /dev/disk/by-partlabel/filebox filebox`.
Try this:

cryptsetup luksOpen /dev/disk/by-partlabel/filebox filebox
Supercalifragilisticexpialidocious

mrjpaxton
Posts: 18
Joined: 2021-07-09 02:35
Been thanked: 2 times

Re: Cryptsetup is not working right

#4 Post by mrjpaxton »

cds60601 wrote:
Try this:

cryptsetup luksOpen /dev/disk/by-partlabel/filebox filebox
Same issue.

User avatar
cds60601
df -h | participant
df -h | participant
Posts: 706
Joined: 2017-11-25 05:58
Location: Florida
Has thanked: 129 times
Been thanked: 60 times

Re: Cryptsetup is not working right

#5 Post by cds60601 »

mrjpaxton wrote:
cds60601 wrote:
Try this:

cryptsetup luksOpen /dev/disk/by-partlabel/filebox filebox
Same issue.
I dunno - I never used LUKS with a partlabel (Im not saying that's the issue), Mine have always been/are pretty vanilla
Supercalifragilisticexpialidocious

CwF
Global Moderator
Global Moderator
Posts: 2638
Joined: 2018-06-20 15:16
Location: Colorado
Has thanked: 41 times
Been thanked: 192 times

Re: Cryptsetup is not working right

#6 Post by CwF »

? I checked a few setups and no LUKS volume or partition is enumerated in /dev/disk/by-partlabel.
Actual, there are no 'by-partlabel' at all. ?

User avatar
cds60601
df -h | participant
df -h | participant
Posts: 706
Joined: 2017-11-25 05:58
Location: Florida
Has thanked: 129 times
Been thanked: 60 times

Re: Cryptsetup is not working right

#7 Post by cds60601 »

CwF wrote:? I checked a few setups and no LUKS volume or partition is enumerated in /dev/disk/by-partlabel.
Actual, there are no 'by-partlabel' at all. ?
I dunno - all examples I ever saw were using something like cryptsetup luksOpen /dev/xxxx (target)
Then again, I never did extensive searches and never really used LVM.
The before mentioned always worked for me while using RedHat's Configuring LUKS: Linux Unified Key Setup as a guide.
So if by-partlabel is a thing, then I'll learn something new :)
Supercalifragilisticexpialidocious

mrjpaxton
Posts: 18
Joined: 2021-07-09 02:35
Been thanked: 2 times

Re: Cryptsetup is not working right

#8 Post by mrjpaxton »

cds60601 wrote:
CwF wrote:? I checked a few setups and no LUKS volume or partition is enumerated in /dev/disk/by-partlabel.
Actual, there are no 'by-partlabel' at all. ?
I dunno - all examples I ever saw were using something like cryptsetup luksOpen /dev/xxxx (target)
Then again, I never did extensive searches and never really used LVM.
The before mentioned always worked for me while using RedHat's Configuring LUKS: Linux Unified Key Setup as a guide.
So if by-partlabel is a thing, then I'll learn something new :)
Partition labels are something introduced in GPT layouts, which don't exist for MBR. In a nutshell, it is basically a way to name or label your partitions without labeling them with filesystem tools, or at a filesystem level. It is possible to have both a regular filesystem label and a partition label (even as the same name), but I don't do that.

So, for example, let's say you make a partition, whether it's Ext4, Btrfs, FAT32, unformatted or anything else, and then you encrypt it, or you even want to put it in an LVM container...

Well, without a partition label, any encrypted/LVM partition's filesystem label will be hidden and not accessible until opened/decrypted. But with GPT, since the name of the partition itself is in the partition table (or whatever they call it), it is always accessible, if that makes any sense. You can have the encrypted partition have the exact same partlabel as the same unencrypted partition if you want to. Heck, I can still mount separately by UUIDs even if they have the same partition label name.

Anyway, the point is, cryptsetup won't work, even if I do the regular unpredictable udev naming of like `/dev/sda1` or whatever, or even `/dev/disk/...` names.

I do press the enter key after cryptsetup asks for my password. Maybe it's reading in the enter key for some reason. I do have a custom ~/.inputrc file, and maybe it's conflicting with how it's supposed to work. I dunno, could be any multitude of factors. I've even tried it without tmux, but maybe the terminal emulator I'm using is sending in the extra enter key to it. Maybe `cryptsetup open` with a passphrase was not designed to handle the "enter" key correctly in all cases, but `cryptdisks_start` can?? Not sure, yet.

I suppose one thing I haven't tried it with a properly formatted key file. I'll report back sometime and see if that works...

User avatar
cds60601
df -h | participant
df -h | participant
Posts: 706
Joined: 2017-11-25 05:58
Location: Florida
Has thanked: 129 times
Been thanked: 60 times

Re: Cryptsetup is not working right

#9 Post by cds60601 »

mrjpaxton wrote: I suppose one thing I haven't tried it with a properly formatted key file. I'll report back sometime and see if that works...
That is exaclty how I have mine setup - I encrypt 3 drives and have them auto-open on boot using the key-file.
I added an additional slot and have a pass-phrase set as a Justin Case :)

Just to give you an idea on how it looks on my side - I'm doing so in the hopes that you might find something that sticks out at you
and allows you to have an "Ah Ha!" moment.

Code: Select all

/etc/crypttab:
# /dev/sda1 = /mnt/data
data UUID=7f2cf990-e9bd-4767-90d5-48955fbc32a7 /root/.key_file luks

# /dev/sdb1 = /mnt/backup1
backup1 UUID=efe5e12a-6f3b-4eae-829f-934fbee5f553 /root/.key_file luks

# /dev/sdc1 = /mnt/backup2
backup2 UUID=a8d6f317-a138-4e96-8bc3-39487c1ce2fe /root/.key_file luks

Code: Select all

/etc/fstab (relevant bits for LUKS)
### Custom Additions - nvme is the system drive
# Internal 1TB SSD drive - dev, uuid, or encrypted
/dev/mapper/data  /mnt/data ext4    defaults,nofail 0      0

# External Drives - dev, uuid, or encrypted
/dev/mapper/backup1  /mnt/nacjup1 ext4    defaults,nofail 0      0
/dev/mapper/backup2  /mnt/backup2 ext4    defaults,nofail 0      0
Supercalifragilisticexpialidocious

mrjpaxton
Posts: 18
Joined: 2021-07-09 02:35
Been thanked: 2 times

Re: Cryptsetup is not working right

#10 Post by mrjpaxton »

Okay, so I think the issue isn't the terminal emulator. I have tried `cryptsetup open` with both Kitty and LXTerminal, all without my usual tmux sessions, and both presented the same problem.

However, when I tried the keyfile. I made sure to use: `set binary noeol` in Vim and copy-pasted they key into a text file in "/tmp/keyfile.txt".

When I did this:

Code: Select all

cryptsetup --key-file=/tmp/keyfile.txt open /dev/disk/by-partlabel/filebox filebox
It actually worked! I saw the `/dev/mapper/filebox` mounted it and checked some of the files, closed it afterwards. Everything was good. So it looks like at least cryptsetup isn't completely broken, it's just having a hard time reading from standard input for some reason. As least I'm getting somewhere with narrowing down the problem...

Maybe I will check with the cryptsetup folks if there are any potential bugs that have been fixed in newer versions. I know Debian likes to use older stable versions whenever possible, but maybe I have an uncommon issue here that could be looked more into.
cds60601 wrote:
mrjpaxton wrote: I suppose one thing I haven't tried it with a properly formatted key file. I'll report back sometime and see if that works...
That is exaclty how I have mine setup - I encrypt 3 drives and have them auto-open on boot using the key-file.
I added an additional slot and have a pass-phrase set as a Justin Case :)

Just to give you an idea on how it looks on my side:

Code: Select all

/etc/crypttab:
# /dev/sda1 = /mnt/data
data UUID=7f2cf990-e9bd-4767-90d5-48955fbc32a7 /root/.key_file luks

# /dev/sdb1 = /mnt/backup1
backup1 UUID=efe5e12a-6f3b-4eae-829f-934fbee5f553 /root/.key_file luks

# /dev/sdc1 = /mnt/backup2
backup2 UUID=a8d6f317-a138-4e96-8bc3-39487c1ce2fe /root/.key_file luks

Code: Select all

/etc/fstab (relevant bits for LUKS)
### Custom Additions - nvme is the system drive
# Internal 1TB SSD drive - dev, uuid, or encrypted
/dev/mapper/data  /mnt/data ext4    defaults,nofail 0      0

# External Drives - dev, uuid, or encrypted
/dev/mapper/backup1  /mnt/nacjup1 ext4    defaults,nofail 0      0
/dev/mapper/backup2  /mnt/backup2 ext4    defaults,nofail 0      0
Oh, so you store your keyfile in "/root"? That is intriguing.

Actually, since only a couple years ago when I finally took the plunge and started the endeavor of figuring out LUKS and FS/block encryption works, I have since then wanted a clean and easy way to be able to use a removable thumb drive, much like a USB "key" with keyfiles on it that when inserted at boot would unlock the OS filesystem(s). I've also never liked the limitations of FAT32, so my reason for using a kernel that is at least version 5.6 (or whenever native ExFat was introduced) was so that I didn't have to use the userspace ExFat FUSE drivers. Instead, I would like to insert an ExFat formatted drive with keyfiles to unlock it, and have it be read by GRUB2.

Turns out that task can be a bit more complicated, especially with Debian Stable that still uses 4.19 kernel by default, and IIRC it doesn't enable ExFat drivers in the initramfs without explicitly specifying it so it can be used at boot time. I also have to think about how in the world removable drives are gonna be auto-mounted like that before "/etc/fstab" is even read. I don't think GRUB2 can use it either, so trying to decrypt "/boot" with an ExFat drive inserted still seems to be out of the question. I don't bother encrypting "/boot" anyway. There doesn't seem to be too much personal data ever on there for me to care about that. It's also a hassle having to still use LUKS1 for encrypting the boot partition. Lol.

Anyway... sorry to go too off topic. yeah, I just use a simple passphrase at boot, but I really should take advantage of some more of the LUKS features and use the multiple keyslots sometime. Haven't bothered to do that yet, and I also need to figure out how to confidently backup the RAID1 /w encryption setup on my PC before I do that, too.

CwF
Global Moderator
Global Moderator
Posts: 2638
Joined: 2018-06-20 15:16
Location: Colorado
Has thanked: 41 times
Been thanked: 192 times

Re: Cryptsetup is not working right

#11 Post by CwF »

mrjpaxton wrote: Partition labels are something introduced in GPT layouts, which don't exist for MBR.
Thanks for the clarification, I did not know that.

User avatar
cds60601
df -h | participant
df -h | participant
Posts: 706
Joined: 2017-11-25 05:58
Location: Florida
Has thanked: 129 times
Been thanked: 60 times

Re: Cryptsetup is not working right

#12 Post by cds60601 »

mrjpaxton wrote: Anyway... sorry to go too off topic. yeah, I just use a simple passphrase at boot, but I really should take advantage of some more of the LUKS features and use the multiple keyslots sometime. Haven't bothered to do that yet, and I also need to figure out how to confidently backup the RAID1 /w encryption setup on my PC before I do that, too.
S'ok - I learned a bit here also. Yeah - the key-file may not be in the best of places and even though its set to chmod 0400, its still not a perfect situation.
As to off topic - lol, I'm trying to figure a good way to backup the laptop when I move to encrypting that. Currently, I enjoy the ease of Clonezilla.
I'm not finding "easy" solutions, but at least there are some.
Supercalifragilisticexpialidocious

CwF
Global Moderator
Global Moderator
Posts: 2638
Joined: 2018-06-20 15:16
Location: Colorado
Has thanked: 41 times
Been thanked: 192 times

Re: Cryptsetup is not working right

#13 Post by CwF »

cds60601 wrote:As to off topic - lol, I'm trying to figure a good way to backup the laptop when I move to encrypting that. Currently, I enjoy the ease of Clonezilla.
Boot a usb or other OS and use qemu-img. The bad is image is uncompressed and real size. I've used it for multiple encrypted OS backups. Actual not a backup, I image to a new device (ssd) every so often, the one I take out is the backup..the temp image on a HD is also a backup.

mrjpaxton
Posts: 18
Joined: 2021-07-09 02:35
Been thanked: 2 times

Re: Cryptsetup is not working right

#14 Post by mrjpaxton »

CwF wrote:
mrjpaxton wrote: Partition labels are something introduced in GPT layouts, which don't exist for MBR.
Thanks for the clarification, I did not know that.
I mean, as a little tech project idea, anyone can try out GPT on any modern PC. There are ways to convert any existing system from MBR to GPT. Sometimes the tutorials will leave out something important: You may also need to create a GPT BIOS partition, which is needed for non-UEFI (BIOS) systems that only support MBR. Without this partition, not even GRUB will be able to start up. The Arch Linux Wiki and other tech blogs have been really helpful on this topic. I can't remember which MBR to GPT conversion tutorials I have used years before, but there may even be some info on the Debian Wiki, not sure... But it is risky, so always backup! :)
cds60601 wrote:
mrjpaxton wrote: Anyway... sorry to go too off topic. yeah, I just use a simple passphrase at boot, but I really should take advantage of some more of the LUKS features and use the multiple keyslots sometime. Haven't bothered to do that yet, and I also need to figure out how to confidently backup the RAID1 /w encryption setup on my PC before I do that, too.
S'ok - I learned a bit here also. Yeah - the key-file may not be in the best of places and even though its set to chmod 0400, its still not a perfect situation.
As to off topic - lol, I'm trying to figure a good way to backup the laptop when I move to encrypting that. Currently, I enjoy the ease of Clonezilla.
I'm not finding "easy" solutions, but at least there are some.
So on my laptop, I have a Bash script in a cron job doing once-every-5-hour, read-only Btrfs snapshots for backing up the OS filesystem, which I can use to recover from any simple mistakes. There's more graphical utilities like Timeshift that can aid in this, but I prefer doing it all CLI because I'm crazy like that... And the bash script is designed only to keep snapshots for 7 days.

Then the filesystem OS, along with the snapshots (which are in the OS filesystem), I tend to back that up manually like once a month on an external drive. I think you can use btrfs send/receive for that for Btrfs, or otherwise rsync will work for Ext4 or whatever. I was warned and advised not to use `dd` to do it, since it will copy over UUIDs/inodes and everything with it, causing potential problems when both are mounted. so DON'T do that. I think I learned that the hard way when my system froze up once when I attached the disk. Lol. I might try rsnapshot or rdiff-backup or something else in case pure rsync is a little too inconvenient for me...

But yeah, I've always personally struggled with trying to find out good backup solutions, specially with RAID drives. I've also heard backing up is the easier part, but figuring out how to recover from backups is the hard and stressful part. And I haven't had enough experience doing that because most of my drives have been working great for many years. Haha.

p.H
Global Moderator
Global Moderator
Posts: 3049
Joined: 2017-09-17 07:12
Has thanked: 5 times
Been thanked: 132 times

Re: Cryptsetup is not working right

#15 Post by p.H »

mrjpaxton wrote:filebox /dev/disk/by-partlabel/filebox none luks,discard
Note that crypttab also supports the more compact syntax PARTLABEL=filebox (as well as PARTUUID=, UUID=, and LABEL=).
mrjpaxton wrote: Okay, so I think the issue isn't the terminal emulator. I have tried `cryptsetup open` with both Kitty and LXTerminal, all without my usual tmux sessions, and both presented the same problem.
Could it be some "unusual" (non ASCII ?) character in the passphrase ?
mrjpaxton wrote:anyone can try out GPT on any modern PC
Also on any older PC like mine (2006), and get rid of the awful extended and logical partitions. Any BIOS should not care about the partition layout. Some BIOS just require to mark the GPT partition bootable in the MBR.
mrjpaxton wrote:There are ways to convert any existing system from MBR to GPT.
I did it online with gdisk from the system installed on the disk. Didn't need any tutorial.
mrjpaxton wrote:You may also need to create a GPT BIOS partition, which is needed for non-UEFI (BIOS) systems that only support MBR. Without this partition, not even GRUB will be able to start up.
A BIOS boot partition is not mandatory for GRUB in all situations (/boot/grub in a plain ext4 partition does not require it), but I still recommend it for reliability.
The size requirement for the BIOS boot partition is so low (100 kB) that it can usually fit in the empty space between the main partition table and the first partition, or in the space previously used by the extended partition.

mrjpaxton
Posts: 18
Joined: 2021-07-09 02:35
Been thanked: 2 times

Re: Cryptsetup is not working right

#16 Post by mrjpaxton »

p.H wrote: 2021-07-10 11:08
mrjpaxton wrote:filebox /dev/disk/by-partlabel/filebox none luks,discard
Note that crypttab also supports the more compact syntax PARTLABEL=filebox (as well as PARTUUID=, UUID=, and LABEL=).
mrjpaxton wrote: Okay, so I think the issue isn't the terminal emulator. I have tried `cryptsetup open` with both Kitty and LXTerminal, all without my usual tmux sessions, and both presented the same problem.
Could it be some "unusual" (non ASCII ?) character in the passphrase ?
mrjpaxton wrote:anyone can try out GPT on any modern PC
Also on any older PC like mine (2006), and get rid of the awful extended and logical partitions. Any BIOS should not care about the partition layout. Some BIOS just require to mark the GPT partition bootable in the MBR.
mrjpaxton wrote:There are ways to convert any existing system from MBR to GPT.
I did it online with gdisk from the system installed on the disk. Didn't need any tutorial.
mrjpaxton wrote:You may also need to create a GPT BIOS partition, which is needed for non-UEFI (BIOS) systems that only support MBR. Without this partition, not even GRUB will be able to start up.
A BIOS boot partition is not mandatory for GRUB in all situations (/boot/grub in a plain ext4 partition does not require it), but I still recommend it for reliability.
The size requirement for the BIOS boot partition is so low (100 kB) that it can usually fit in the empty space between the main partition table and the first partition, or in the space previously used by the extended partition.
Hi p.H,

Thanks a lot for your clarifications and additional info! I wasn't too sure that "/etc/crypttab" supported those inline variables/definitions, but I know for a fact that cryptsetup on the other hand does NOT, so that's what I was concerned about. I use them in "/etc/fstab" as well.

So when I generate my passwords in KeePassXC, typically I turn extended ASCII off (or add them if a Website requires it). So I only have "[A-Z][a-z][0-9]" being used here. And I understand while it does make the passwords more compatible with things in a sense, it also makes them have less entropy, but that can be managed with using longer passwords.

But yes, I always, always mention the GPT boot partition because I had been scratching my head over that for hours trying to learn the hard way about that. I also couldn't boot in anymore without it. It's always good to have another computer around, or have a live system or backup OS/drive around before messing with that stuff, and getting confused why it didn't boot until I learned that. ;)

Okay, back on the topic. Still no luck trying to decrypt it with standard `cryptsetup`, I also want to mention that I also have another private drive encrypted with LUKS that I have used `cryptsetup` on in the terminal, and that one also does not open using the same method...

So I'm still blaming the enter key, or something like that. Some other people have said that locale settings could be an issue. I'm not so sure... But typing `locale` shows normal output (I think) like this, at least for the US:

Code: Select all

LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
Does this look right?

Interesting thing to note also, is that the newline isn't processed from a terminal, which is what I thought. So if it does process it, then it's a bug.

I then saw a section from the manpage of cryptsetup(8):

Code: Select all

NOTES ON PASSPHRASE PROCESSING FOR PLAIN MODE
       Note that no iterated hashing or salting is done in plain mode.  If hashing is done, it is a single direct hash. This means that low-entropy passphrases are easy to attack in plain mode.

       From a terminal: The passphrase is read until the first newline, i.e. '\n'.  The input without the newline character is processed with the default hash or the hash specified with --hash.  The hash result will  be  truncated  to
       the key size of the used cipher, or the size specified with -s.

       From  stdin:  Reading will continue until a newline (or until the maximum input size is reached), with the trailing newline stripped. The maximum input size is defined by the same compiled-in default as for the maximum key file
       size and can be overwritten using --keyfile-size option.

       The data read will be hashed with the default hash or the hash specified with --hash.  The hash result will be truncated to the key size of the used cipher, or the size specified with -s.

       Note that if --key-file=- is used for reading the key from stdin, trailing newlines are not stripped from the input.

       If "plain" is used as argument to --hash, the input data will not be hashed. Instead, it will be zero padded (if shorter than the key size) or truncated (if longer than the key size) and used directly as the binary key. This is
       useful for directly specifying a binary key.  No warning will be given if the amount of data read from stdin is less than the key size.

       From a key file: It will be truncated to the key size of the used cipher or the size given by -s and directly used as a binary key.

       WARNING: The --hash argument is being ignored.  The --hash option is usable only for stdin input in plain mode.

       If  the  key  file is shorter than the key, cryptsetup will quit with an error.  The maximum input size is defined by the same compiled-in default as for the maximum key file size and can be overwritten using --keyfile-size op‐
And note the part where it doesn't process the newline. So I guess that can't be it. I'm just at a loss of words what it could possibly be at this point... Again, I can still use `cryptsetup` with the "--key-file=" option, and it works. Just veeeeery odd.

Anyway, I'm still just using `cryptdisks_start` and `cryptdisks_stop` for now, since those actually work right. :lol:

Also, nice to see that the forums just got updated from HTTP to HTTPS! Cool.

p.H
Global Moderator
Global Moderator
Posts: 3049
Joined: 2017-09-17 07:12
Has thanked: 5 times
Been thanked: 132 times

Re: Cryptsetup is not working right

#17 Post by p.H »

Trying to figure out what could cause this behaviour...
- cryptsetup is redefined as an alias with a weird option
- your terminal (or some layer between it and the shell) translates the enter key into CR+LF (\r\n) instead of just LF, so cryptsetup treats CR as part of the passphrase.

mrjpaxton
Posts: 18
Joined: 2021-07-09 02:35
Been thanked: 2 times

Re: Cryptsetup is not working right

#18 Post by mrjpaxton »

p.H wrote: 2021-07-15 11:39 Trying to figure out what could cause this behaviour...
- cryptsetup is redefined as an alias with a weird option
- your terminal (or some layer between it and the shell) translates the enter key into CR+LF (\r\n) instead of just LF, so cryptsetup treats CR as part of the passphrase.
The first one is not it. I checked.
Second one is plausible, but how would I disable carriage return? Through `stty` or something similar?

Here is what mine looks like:

Code: Select all

# stty -a
speed 38400 baud; rows 61; columns 240; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = <undef>; stop = <undef>; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;                       
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -ixon -ixoff -iuclc -ixany -imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc
Which I think is pretty standard for most terminals to work correctly.

p.H
Global Moderator
Global Moderator
Posts: 3049
Joined: 2017-09-17 07:12
Has thanked: 5 times
Been thanked: 132 times

Re: Cryptsetup is not working right

#19 Post by p.H »

Before looking for how to disable CR, you could check whether it is present or not. I guess a simple

Code: Select all

cat | hd
should do it. Type some lines, then ctrl+d to quit. LF is hex 0a and CR is hex 0d.

padet
Posts: 1
Joined: 2022-01-24 18:31

Re: Cryptsetup is not working right

#20 Post by padet »

I had the exact same problem on Ubuntu 20.04.3 LTS. I didn't update or reboot it since i installed it in November 2020. After doing apt upgrade and rebooting it today i was not able to mount the crypt volumes. Same error message.
It obviously was because something has been changed on the cryptsystem. When i create a new volume now then everything works as expected. I can mount it with cryptsetup luksopen. But the old volumes created before the update can not be mounted with cryptsetup luksopen.
Thanx for that /etc/crypttab solution!
That works for me as well.

Post Reply