Required key not available

[blaskovic]

$ sudo edit-chroot -all
name: debian
encrypted: no
Entering /mnt/stateful_partition/crouton/chroots/debian...
crouton: version 1-20170315143304~master:95589555
release: jessie
architecture: amd64
xmethod: xorg
targets: xfce,x11,xorg,xiwi
host: version 9460.60.0 (Official Build) beta-channel edgar 
kernel: Linux localhost 3.18.0-14582-g2fa17b5c810f #1 SMP PREEMPT Mon Jun 5 16:58:26 PDT 2017 x86_64 GNU/Linux
freon: yes
Not unmounting /mnt/stateful_partition/crouton/chroots/debian as another instance is using it.

Please describe your issue:

When I try to do write (reading is fine) action with Downloads directory, I always got:

$ echo asd > ~/Downloads/test
bash: /home/bblaskov/Downloads/test: Required key not available

Writing outside of Downloads is fine:

$ echo asd > ~/test
$ cat ~/test 
asd

Mounts:

$ mount | grep Downlo
/dev/mmcblk0p1 on /home/bblaskov/Downloads type ext4 (rw,nosuid,nodev,relatime,seclabel,commit=600,data=ordered)

What else can I provide?

[blaskovic]

Nobody?

[DennisLfromGA]

@blaskovic,

I can't repro your issue, from outside or inside the chroot -

chronos@localhost ~ $ mount | grep Downlo
/dev/sda1 on /run/crouton/var/crouton/chroots/trusty/home/denny/Downloads type ext4 (rw,nosuid,nodev,relatime,seclabel,commit=600,data=ordered)

chronos@localhost ~ $ echo asd > ~/Downloads/test
chronos@localhost ~ $ cat ~/Downloads/test 
asd

(trusty)denny@localhost:~$ echo asd > ~/Downloads/test
(trusty)denny@localhost:~$ cat ~/Downloads/test
asd

---

It looks like your chroot is in need of an update, I would do that first to see if the issue disappears.

-DennisL

[blaskovic]

I've got it updated. It's the same for debian and xenial chroots. It's buggy just in Downloads folder, any other folder is fine (so the bridge between chromeos and chroot is broken).

crouton is giving me this warning:

WARNING: Legacy booting is enabled; consider disabling it.
WARNING: Signed boot verification is disabled; consider enabling it.

Is it somehow useful?

[DennisLfromGA]

@blaskovic,

It's buggy just in Downloads folder, any other folder is fine (so the bridge between chromeos and chroot is broken).

Not for me. I haven't seen any other reports of this behavior either.
I'm not saying it's not happening, just that I can't reproduce it.

crouton is giving me this warning:

WARNING: Legacy booting is enabled; consider disabling it.
WARNING: Signed boot verification is disabled; consider enabling it.

Is it somehow useful?

It's useful for those that want to tighten down security -

• dev_boot_legacy - this enables a device to boot from SeaBIOS when a user presses the Control+L keys at the boot time warning screen.
• dev_boot_signed - the firmware will boot only Google signed-images (full verified boot), and only from the SSD.

See this page for info. about 'Developer Mode'.

Hope this helps,
-DennisL

[dnastase]

This is happening to me too the following way:

• I have two chromebooks with crouton setup
• I have setup and started sshd on one chromebook (inside the crouton)
• anything I try on the other chromebook that involves ssh-ing to the first one (rsync, ssh cat, even login (.bashrc)) and it's on a builtin storage it shows this error. As such:

chronos@localhost ~ $ ssh dan@192.168.1.58 cat .bashrc
dan@192.168.1.58's password: 
bash: /home/dan/.bashrc: Required key not available
cat: .bashrc: Required key not available

Notes:

• the error disappears if I just cat the file on the first chromebook manually first
• the error is not present if the files involved are on my sd card
• this is reproducible for me

[agriffis]

I've just hit this and might have stumbled on a clue.

I normally run this immediately after startup:

enter-chroot -u root -b sh -c '
    install -d -m 0755 /var/run/sshd
    /usr/sbin/sshd -D
'

then use Secure Shell to connect to the chroot, windowed and full-screen. This provides a better terminal experience, option profiles, etc.

I'm finding that I can write to Downloads from enter-chroot but not from the Secure Shell session. It seems like there's some different information in enter-chroot that isn't available to Secure Shell.

[agriffis]

Here's what I've figured out so far:

The Downloads dir (and possibly other dirs, maybe parents, I haven't checked) is encrypted on Chrome OS. It's using ext4 filesystem-level encryption.

The key for accessing the data is stored in the session keyring in the kernel. We can see the content of the keyring with keyctl:

chronos@localhost ~ $ keyctl show
Session Keyring
 373897794 ---ls-rv      0     0  keyring: _ses
 517397014 ---ls-rv      0     0   \_ keyring: dircrypt
 952297866 ----s--v      0     0       \_ logon: ext4:182e6824...

Access to the session keyring survives over fork/exec, also sudo and chroot. We can see it inside enter-chroot by installing the keyutils package:

chronos@localhost ~ $ sudo enter-chroot
Password: 
Entering /mnt/stateful_partition/crouton/chroots/xenial...

$ sudo apt-get install keyutils
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following NEW packages will be installed:
  keyutils
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/47.1 kB of archives.
After this operation, 129 kB of additional disk space will be used.
Selecting previously unselected package keyutils.
(Reading database ... 70875 files and directories currently installed.)
Preparing to unpack .../keyutils_1.5.9-8ubuntu1_amd64.deb ...
Unpacking keyutils (1.5.9-8ubuntu1) ...
Processing triggers for man-db (2.7.5-1) ...
Setting up keyutils (1.5.9-8ubuntu1) ...

$ keyctl show
Session Keyring
 373897794 ---ls-rv      0     0  keyring: _ses
 517397014 ---ls-rv      0     0   \_ keyring: dircrypt
 952297866 ----s--v      0     0       \_ logon: ext4:182e6824...

However this changes when connecting to sshd running in crouton:

$ keyctl show
Session Keyring
 207092121 --alswrv   1000  1000  keyring: _ses
 575122944 --alswrv   1000 65534   \_ keyring: _uid.1000

I imagine there's a way to share the keyring or key with the process tree running under sshd, but I haven't figured that out yet.

[AlexLewandowski]

I ran into this problem as well while trying to use spacemacs via Secure Shell into my local chroot. I couldn't compile latex files, and soon realized I couldn't write anything into the mounted ~/Downloads folder.

A solution that worked for me was to run emacs as a daemon on start-up (through sudo enter-chroot). Then, when I connect to the server using emacsclient in Secure Shell, emacs (and its shell/terminal) will have the necessary key.

[agriffis]

@AlexLewandowski That's a good idea. I've been thinking of something similar, which is to run sshd under my own user instead of as root. OpenSSH doesn't really support that, though, and I haven't looked for an ssh daemon that would.

Another possibility is to run a local terminal instead of Secure Shell. But SS always has the latest hterm.js which is important to me.

[awlnx]

I also have this issue, please let me know if there is any data that I can provide. I can create directories but not files

[agriffis]

@awlnx I switched to running crosh in a window, instead of running sshd and connecting to it. It's been working great.

[ihexon]

I found a easy way to keep the key session,using tmux

chroot $RFS/ /usr/bin/sudo -i -u $USERNAME 

# In this way you have right keyring and could write /sdcard/Downloads

and link the keys
`keyctl link @s @us && keyctl link @s @u`

and than Just execute tmux, and Ctrl-D running it background... 

Next time you ssh USERNAME@127.0.0.1 and just attach the tmux session by tmux attach.

the tmux session have right key session

[justchen1369]

can duplicate.

[jar349]

I suspect that this may be related to the fact that some versions of ChromeOS encrypt what eventually maps to ~/Downloads in crouton and that the key to decrypt it is not available.

[andrewmoise]

I also am experiencing this issue (since a recent update, Debian sid) -- I'm happy to help debug if anyone wants to try to track it down. It makes ~/Downloads unusable (either for reading or writing) from my crouton shells.

[cvmiller]

I am seeing this issue on a Asus C101PA with both Debian Buster & Ubuntu Bionic running CrOS 78.0.3904.106

[kapilhp]

The "quick and dirty" fix for this is to comment out the line revoking the key during su -l. The relevant line in /etc/pam.d/su-l should be commented out as below.

# session		optional	pam_keyinit.so force revoke

The point is that Debian/Ubuntu now revokes the keys when doing su -l by default. However, crouton activates the chroot via su -l. Perhaps crouton should be using some other method (schroot or other?) to enter the chroot.

[cvmiller]

Thanks for the "quick and dirty" fix. It works great. I agree, not the most elegant, but at least my editor can save to ~/Downloads/ again

Just to be clear for others, one needs to edit the /etc/pam.d/su-l file inside the chroot, and then restart the chroot.

[gmcmicken]

Thanks for the "quick and dirty" fix. It works great. I agree, not the most elegant, but at least my editor can save to ~/Downloads/ again

Just to be clear for others, one needs to edit the /etc/pam.d/su-l file inside the chroot, and then restart the chroot.

I didn't have an su-1 file and my su file didn't have that line so I searched in pam.d and found that it was in /etc/pam.d/sshd. Commented it out there and I can modify files in my ~/Downloads folder from ssh. Thanks a bunch!

edit this was on xenial with the cli-extra chroot.

[goldstar611]

I'd like to mention that on CloudReady v78 and Debian 10 Buster + XFCE both workarounds worked.

That is to say in crosh

shell
keyctl link @s @us && keyctl link @s @u
sudo startxfce4

works and editing the /edc/pam.d/ files to comment out

# session optional pam_keyinit.so force revoke

Just one method is necessary to get the key in the OS.

[zixijian]

I also encountered this problem when i use linuxdeploy on my android phone，my device is Redmi note7 pro，When I tried to change the USEPAM in sshd_config to no, the problem was solved. Hope that helps.

[Lerie82]

Logout of the chroot then..

sudo edit-chroot -a -y -e

you will be prompted to enter a key for the encryption.

chronos@localhost / $ sudo edit-chroot -a -y -e
Unmounting /mnt/stateful_partition/crouton/chroots/kali-rolling...
You must have a root password in Chromium OS to mount encrypted chroots.
Password: 
Verifying - Password: 
Choose an encryption passphrase for kali-rolling: 
Please confirm your passphrase: 
Generating keys (move the mouse to generate entropy)...
done
Encrypting kali-rolling; please wait....

[BonnieLeeRoot]

Thanks for the "quick and dirty" fix. It works great. I agree, not the most elegant, but at least my editor can save to ~/Downloads/ again
Just to be clear for others, one needs to edit the /etc/pam.d/su-l file inside the chroot, and then restart the chroot.

I didn't have an su-1 file and my su file didn't have that line so I searched in pam.d and found that it was in /etc/pam.d/sshd. Commented it out there and I can modify files in my ~/Downloads folder from ssh. Thanks a bunch!

edit this was on xenial with the cli-extra chroot.

In bullseye this fixed the problem. It makes the Downloads folder useful, as in I can read and write to it. I commented out the line in the su-l file inside the chroot, and all is well!