I want to read the encrypted data on my (former) /home partition (if possible: on an external SSD).
I think I have encrypted the data via Yast (or during the installation of Leap 42.1). The password was the same as my user password and I was asked for it during the booting/logging in of Leap 41.1.
I seemed to have messed up my openSUSE Leap 42.1 installation - probably be deleting btrfs snapshots.
I could not longer log in in the graphical log in - nether as a normal user nor as root.
As I had already an other SSD at hand I took the messed up 42.1 SSD out of my main laptop and put it into an external USB 3.0 case. And I installed the newer Leap 42.2 on the new SSD in my laptop.
I used the same username as currently on my old (encrypted) installation/home-partition/home-directory (substituted in the code window below with username1) and probably one other username (substituted with username2).
If I connect the old SSD to the laptop I could see some directories and files:
linux-1234:/run/media/username1/12345678-90ab-cdef-1234-1234567890ab # ls
lost+found username1 username1.img username1.key username2
linux-1234:/run/media/username1/12345678-90ab-cdef-1234-1234567890ab # ls -l
total 20407188
drwx------ 2 root root 16384 Mar 5 2016 lost+found
drwxr-xr-x 31 root root 4096 Mar 19 2016 username1
-rw------- 1 username1 root 20971520001 Dec 31 14:59 username1.img
-rw------- 1 username1 root 288 Mar 19 2016 username1.key
drwxr-xr-x 22 1010 users 4096 Mar 19 2016 username2
Probably username1.img is the encrypted data and username1.key is the according (LUKS?) key for that.
1010 seems the number (uid) of the second (unencypted) username. I am able to look into the folders username1 and username2 - in there are typical directories and files of a /home-directory. Probably the old directory username1 contains the content of the (old?) home directory before encryption or before installing Leap 42.1.
Unless you happen on something very unexpected, you won’t be able to mount your encrypted partition(s) on another system and unlock it.
If you used snapper to delete your snapshots (you didn’t just “rm” the snapshots using a file management function, right?), snapper is supposed to protect you from doing anything disastrous by accident. At worst, you might be able to boot into a read-only image, but that should be enough to decrypt your files and copy elsewhere if necessary.
So,
What do you get when you boot?
Do you see a text login prompt?
So the next time I should try to encrypt a partition without Yast if I want to be able to read it from an other system just with my password (or with a key and the password)?
So I have to build in the old SSD again
or try to boot it from an external USB 3.0 case?
I was suspicious/afraid to ruin the system just even further that way…
As far as I recall I used snapper/the Yast2-snapper-modul.
I think I did see the graphical login but I was not able to log in after booting any of the offered read-only-images/snapshots - neither as the normal user nor as root (my name/username was not even offered).
Should I try again with a text prompt (I am not sure that I tried not that - but probably not with a read only snapshot)? Should I use any keys during the booting process or just switch to the text prompt/console via F1+Control+Alt?
So first…
Let’s talk about why anyone would encrypt files, including encrypting a partition.
It won’t protect you against losing files to a hacker while your machine is running. This is because encrypted files have to be unencrypted to be usable by anyone or anything including the running system.
It will protect you when the “data is at rest,” which means that nothing is actively accessing the data. This typically means that if you power off your machine (eg laptop) and go traveling… If you lose your laptop then someone else can’t mount your disk in someone else’ machine to read or boot your machine if you require a password on bootup.
Also, on general purposes security isn’t a black and white issue (you’re secure or you’re not).
Security is a graduated policy of what you don’t want to be accessible and when/how you want to grant access always understanding that any kind of access to some degree allows the possibility of being compromised.
The Security Guru knows exactly what to do to accomplish specific security objectives in various scenarios, understanding what procedures are effective and what aren’t.
The above should factor into your own decision whether encrypting the root partition is something that addresses your security objectives or not. IMO the large majority of computer users have no need to encrypt their root partitions, ordinary security without an encrypted partition is sufficient. And, as you’re now coming to realize there is a very big downside to encrypting the root partition… You need to scrupulously maintain fully working backups or risk everything (no exaggeration!).
What I’ve described applies no matter what encrypting method you use, it does not matter for instance whether you used YaST to encrypt or not, the end result does not change.
But, as I’ve described…
If you can boot to a login prompt, even a text-only login prompt…
And you can login…
Then you’re probably OK and won’t lose anything even if you might end up having to completely re-install (or at least maybe remove the encryption, but that typically is a very long and possibly problematic procedure).
Either can be done.
I’ve written elsewhere that if you’re running any Desktop other than those offered during the Install that they don’t install properly in 42.2, you need to install in 42.1 and then upgrade to 42.2. Problem Desktops which need this upgrade include
LXDE
LXQt
Mate
And, there are likely others. If you install KDE or Gnome directly into 42.2, then AFAIK you won’t have a problem.
If that works, it will create “/dev/mapper/somefunkyname” which you could then try to mount.
I don’t know if that will work. I’m guessing that you have already tried using a file browser and clicking on the container. And if that did not attempt to open it (prompting for a key), then you might be out of luck.
I have put in the old SSD again. Booting with the USB 3.0 case did not work at all.
I get a login prompt/screen but I cannot login.
I could not even write a password for the existing users.
If I use an existing usernamex = username1 OR username2 (names of the directories in the home partition) OR root] in the text/console login I get:
If I recall it right I was asked for the “pam_mount password” after choosing an existing username before I messed up with btrfs/snapper.
Is there any chance that I would be able to log in with a not existing username but the correct password?
If so I would try if I have changed my password (but I think I used any passwords I might have used).
And I have not chanced the root password - of that I am quite sure…
You should try any Username that already exists.
Even root (This is one of those special exceptions when your situation is dire enough, you are logging in to recover your system). If you are able to login with root successfully, then you can create new User accounts (but, why?) and set new passwords for any other accounts you are unable to login with.
The main objective is to login and then copy your /home and anything else you want to preserve to another location, then you can be free to do what you want with your existing system. If you don’t feel comfortable without a full Desktop, then ask for any commands you don’t understand, but in general you’ll probably want to run the following. Depending on whether your /home is encrypted will determine whether you can run this only once for any/all Users on your system or if you’d need to login as each User before copying. If you’re running anything that uses a database, you need to study where the database files are and the correct way to export or backup the data to external source (depends on the app, so I can’t describe anything specific).
Ad least if I mount it as I did:
as I understand username1 (uid 1000) have the only right to read and write from it - or not? :
But being the normal user unsername1 I am not able to run the decryption program lacking the root privileges/rights.
...]
Kann das Loopback-Gerät nicht benutzen, weil das Programm nicht mit Root-Rechten läuft. ...]
So should I mount the partition in an other way?
If the passphrase is changed is the key also changed?
So if the key was not changed untill Mar 19 2016 is the passphrase also still the same?
linux-1234:/ # cryptsetup luksOpen /run/media/username1/12345678-90ab-cdef-1234-1234567890ab/username1.img somefunkyname
Enter passphrase for /run/media/username1/12345678-90ab-cdef-1234-1234567890ab/username1.img:
No key available with this passphrase.
So a changed passphrase is not the cause of “No key available with this passphrase.”?
I have tried all three: both usernames with a directory in the /home-partition and also root. Only with a not existing username I get asked for the “pam_mount password”. With the existing usernames I get not asked for any password.
And this is likewise on the GUI/graphical login and the text/console login via Ctrl + Alt + F1.
At least with KDE, I think you can open the file browser as a super user. I would see if that works for accessing the encryted home.
If the passphrase is changed is the key also changed?
I don’t know the answer to that, as I have not encrypted home directory in that way.
The normal way that LUKS crypto works, a random key is generated and the data is encrypted with that. And then the encryption key (that random key) is then encrypted with the passphrase and stored in the LUKS header. But I’m not sure how that connects with your login password. It could be that the login password is used as if a passphrase for LUKS. Or it could be that the passphrase is further encrypted to that “username.key1” file.
/usr/sbin/cryptconfig open --key-file=username1.key username1.img
You will be asked for a password - this should be your user password from the previous installation. It sets up encrypted container with name /dev/mapper/username1.img (if it is full path, “/” is replaced with “_”).
If you forgot your original password, the only way is to brute force it.
Cool. - So if the file username1.key was changed on Mar 19 2016, that is also the date on which I changed/created the password.
username1@linux-1234:~> su -
Passwort:
linux-1234:~ # mount /dev/sdb3 /crypt
linux-1234:~ # cd /crypt
linux-1234:/crypt # ls -l
total 20407188
drwx------ 2 root root 16384 Mar 5 2016 lost+found
drwxr-xr-x 31 root root 4096 Mar 19 2016 username1
-rw------- 1 username1 root 20971520001 Dec 31 14:59 username1.img
-rw------- 1 username1 root 288 Mar 19 2016 username1.key
drwxr-xr-x 22 1010 users 4096 Mar 19 2016 sprachkurs
linux-1234:/crypt # /usr/sbin/cryptconfig open --key-file=username1.key username1.img
-bash: /usr/sbin/cryptconfig: No such file or directory
linux-1234:/crypt # cryptconfig open --key-file=username1.key username1.imgIf 'cryptconfig' is not a typo you can use command-not-found to lookup the package that contains it, like this:
cnf cryptconfig
linux-1234:/crypt # zypper in cryptconfig
…]
The following 20 NEW packages are going to be installed:
cryptconfig …]
...]
(19/20) Installing: pam_mount-32bit-2.15-4.5.x86_64 ......................[done]
(20/20) Installing: cryptconfig-32bit-0.3-97.4.x86_64 ....................[done]
linux-1234:/crypt # cryptconfig open --key-file=username1.key username1.img
Enter the key file password:
username1.img is now available as device /dev/mapper/_crypt_username1.img