action #120459

[security] luks1_decrypt_ssh_server fails on tumbleweed; test-logic: unlock_via_ssh_server seems flawed

Added by dimstar 3 months ago. Updated about 1 month ago.

In Progress
Bugs in existing tests
Target version:
Start date:
Due date:
% Done:


Estimated time:
48.00 h



The test is based on two machines, client (admin interface) and server (remote server)
The idea is that a remote server with encrypted disk can be rebooted and then the password to decrypt entered via ssh.

The test somewhat 'works' (worked) with some (unnoticed flaws):

  • The server is setup with a 'strange' partition layout: /boot encrypted, but / is not

As a consequence, before the ssh server is even reachable, an admin needed to locally unlock the /boot encryption (making dracut-ssh completely useless, as an admin was already local to the system anyway)

This has now popped up as an error on openQA as recent grub forwards the key it receives to decrypt itself to the partitions - which in this case it 'auto-unlocks' during the boot process, making dracut-ssh not having anything to do (tried to unlock /boot again)

IMHO, the partitioning layout it inversed: / should be encrypted, /boot decrypted

openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-luks1_decrypt_ssh_server@64bit fails in

Test suite description

Maintainer: QE Security

Fails since (at least) Build 20221114

Last good: 20221109 (or more recent)

Further details

Always latest result in this scenario: latest

This test uses HDD Created by test suite create_hdd_gnome_encrypt_separate_boot using YAML schedule/security/autoyast_btrfs_luks1_separate_boot.yaml, which refers to autoyast_sle15/autoyast_btrfs_luks1_separate_boot.xml, and the test itself uses YAML schedule/security/luks1_decrypt_ssh_server.yaml.

Internal discussion that resulted in filing this ticket

Related bug report

Acceptance Criteria

  1. Restructure create_hdd_gnome_encrypt_separate_boot to create a qcow2 with unencrypted boot and encrypted /, accepting passphrase for / over SSH server started in initrd from /boot
  2. Update the maintainer of the test to be QE Security


#1 Updated by maritawerner 3 months ago

  • Subject changed from test-logic: unlock_via_ssh_server seems flawed to [security] test-logic: unlock_via_ssh_server seems flawed

#2 Updated by tjyrinki_suse 3 months ago

  • Subject changed from [security] test-logic: unlock_via_ssh_server seems flawed to [security] luks1_decrypt_ssh_server fails on tumbleweed; test-logic: unlock_via_ssh_server seems flawed
  • Description updated (diff)
  • Start date deleted (2022-11-15)
  • Estimated time set to 48.00 h

Added more further details and also acceptance criteria (debatable..). I've checked and the HDD in question seems to be only used for this one particular test, so the restructuring should be possible.

#3 Updated by tjyrinki_suse 3 months ago

  • Description updated (diff)

#4 Updated by openqa_review 2 months ago

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: luks1_decrypt_ssh_server

To prevent further reminder comments one of the following options should be followed:

  1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
  2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
  3. The bugref in the openQA scenario is removed or replaced, e.g. label:wontfix:boo1234

Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.

#5 Updated by punkioudi about 1 month ago

  • Status changed from New to In Progress
  • Assignee set to punkioudi

Also available in: Atom PDF