View Issue Details

IDProjectCategoryView StatusLast Update
0005584Kali Linux[All Projects] Kali Package Bugpublic2019-07-10 08:18
Reporter2raziel3Assigned To 
PriorityhighSeveritymajorReproducibilityalways
Status newResolutionopen 
Product Version2019.2 
Target VersionFixed in Version 
Summary0005584: Cryptroot-unlock Timeout on askpass
DescriptionPackage: cryptsetup
Version:2:2.1.0

Error message is;
Error: Timeout reached while waiting for askpass

Command run is;
cryptroot-unlock

kernel is;
4.19.0-kali5-amd65 0000001 SMP Debian 4.19.37-5kali1

C version;
2.28-10

I am pretty sure that the upgrade from cryptsetup 2:2.0.6 to the version above caused this issue.
Steps To Reproducethis is my full procedure, sorry its a little long.

Objective
trying to get an SSH shell to open up on boot to allow for the luks password to be supplied.
This should work on equipment that has no hardware TPM.

Guide
on kali installation you may need to mount the scsi drive to cdrom, this is done by.
Load cdrom drivers from removable media = NO
manually select = YES
cdrom
continue
continue
execute shell
continue
 
~ # blkid
/dev/sdb1: UUID="2018-04-12-12-04-16-00" LABEL="Kali Live" TYPE="iso9660" PARTUUID="81c5e086-01"

~ # mount -t iso9660 /dev/sdb1 /cdrom
exit

select Detect and mount CD-rom
select eth0 , make sure this is the one jacked in

*MAKE SURE YOU DO NOT FORCE UEFI*

on partition disks select;
Guided - uses entire disk and set up encrypted LVM
All files
set encryption password
max
finish
yes
network mirror = yes
install grub loader on master boot record = yes
select the non-live-boot drive
once logged in update the OS

# apt-get update && apt-get -y dist-update && apt-get -y autoremove note: this will take a while

Wireshark prompt = no
restart services = yes
display manager must restart manually = ok
(good time for cup of tea)
configure postrgessql-common = ok
(good time for second cup of tea)
king-phisher server_config.yml = default=N

apt-get install busybox dropbear dropbear-initramfs

You will get a warning here as it completes: dropbear: WARNING: Invalid authorized_keys file, remote unlocking of cryptroot via SSH won’t work!,
just ignore it for now.

nano /etc/initramfs-tools/initramfs.conf
....
BUSYBOX=y
DROPBEAR=y
....

cd /etc/dropbear-initramfs/
/usr/lib/dropbear/dropbearconvert dropbear openssh dropbear_rsa_host_key id_rsa
dropbearkey -y -f dropbear_rsa_host_key |grep "^ssh-rsa " > id_rsa.pub

Add the deployment server public key to the authorized_keys. 
echo "clients public key" >> authorized_keys

we now want to limit what can be done in this shell so we edit the authorized_keys as follows;
nano authorized_keys
no-port-forwarding,no-agent-forwarding,no-X11-forwarding ssh-rsa .................

we can set dropbear to start
nano /etc/default/dropbear
....
NO_START=0
....

we change the port that dropbear listens on from 22 so that we do not get a MitM warning due to conflicts with openSSH
nano /etc/dropbear-initramfs/config
....
DROPBEAR_OPTIONS="-p 50000 -s -j -k -I 60" THE LAST SWITCH IS AN UPPERCASE i

we need to enable root ssh access;
nano /etc/ssh/sshd_config
......
PermitRootLogin yes
......

systemctl restart ssh.service

we need to disable Screen Lock, power saving and Automatic suspend

wget --no-check-certificate \ "https://gist.githubusercontent.com/gusennan/712d6e81f5cf9489bd9f/raw/fda73649d904ee0437fe3842227ad8ac8ca487d1/crypt_unlock.sh" \
 -O /etc/initramfs-tools/hooks/crypt_unlock.sh

make sure the script ends in a single new line after fi (sometimes does not copy properly)
so if you cat it it ends in;
fi
root@xxxxxxx:~#

not
firoot@xxxxx:~#

chmod +x /etc/initramfs-tools/hooks/crypt_unlock.sh

update-initramfs -u

systemctl disable dropbear

reboot first re-boot might take a while

the cryptodog should seem to hang on;
filename :

from the control server you should now be able to ssh to the CryptoDog using;
ssh root@"ip" -p 50000

 It is at this point that we run the cryptroot-unlock command and get the timeout for askpass.

what should happen is it prompts for the password and upon entering the password your device decrypts/boots.

Activities

rhertzog

2019-07-10 08:18

administrator   ~0010778

Quick question: do you have cryptsetup-nuke-password installed in your system?

If yes, you must be aware that it hijacks the "askpass" executable provided by cryptsetup. It might related. See http://gitlab.com/kalilinux/packages/cryptsetup-nuke-password

It might be interesting to know if your problem is introduced by the presence of cryptsetup-nuke-password or simply because we switched to cryptsetup 2.1. So maybe try again after having removed cryptsetup-nuke-password ?

Issue History

Date Modified Username Field Change
2019-07-09 13:21 2raziel3 New Issue
2019-07-10 08:18 rhertzog Note Added: 0010778