About remote unlocking of a LUKS partition, /usr/share/doc/cryptsetup/README.Debian.gz says

You can then unlock the disk remotely via SSH with

ssh -tF ~/.luks/ssh.conf root@remote.system.com cryptroot-unlock

Or, using a local gpg-encrypted key file:

gpg --decrypt ~/.luks/remote.key.gpg | ssh -TF ~/.luks/ssh.conf root@remote.system.com cryptroot-unlock

In my case, "ssh -t ..." works fine:

X11 forwarding request failed on channel 0
Please unlock disk nvme0n1p3_crypt:
cryptsetup: nvme0n1p3_crypt set up successfully

But if I do

cat file | ssh -T ...

where "file" is a text file just containing the passphrase,
I get an error:

X11 forwarding request failed on channel 0
Please unlock disk nvme0n1p3_crypt
cryptsetup: cryptsetup failed, bad password or options?

What could be the cause?

--
Vincent Lef?vre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

--- PyGate Linux v1.5.18
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-07-06 16:11:11 +0200, Vincent Lefevre wrote:

But if I do

cat file | ssh -T ...

where "file" is a text file just containing the passphrase,
I get an error:

X11 forwarding request failed on channel 0
Please unlock disk nvme0n1p3_crypt
cryptsetup: cryptsetup failed, bad password or options?

What could be the cause?

I've eventually found the issue. This is due to the newline character
after the passphrase, which cryptroot-unlock doesn't remove! I could
confirm with "echo -n <passphrase> | ssh ...", which works.

I've reported the bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1141580

(I thought I had tried with "printf %s <passphrase>" earlier,
but I may have made a mistake in my test.)

--
Vincent Lef?vre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

--- PyGate Linux v1.5.18
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Mon, Jul 6, 2026 at 11:52?AM Vincent Lefevre <vincent@vinc17.net

wrote:

On 2026-07-06 16:11:11 +0200, Vincent Lefevre wrote:

But if I do

cat file | ssh -T ...

where "file" is a text file just containing the passphrase,
I get an error:

X11 forwarding request failed on channel 0
Please unlock disk nvme0n1p3_crypt
cryptsetup: cryptsetup failed, bad password or options?

What could be the cause?

I've eventually found the issue. This is due to the newline character
after the passphrase, which cryptroot-unlock doesn't remove! I could
confirm with "echo -n <passphrase> | ssh ...", which works.

I've reported the bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1141580

(I thought I had tried with "printf %s <passphrase>" earlier,
but I may have made a mistake in my test.)

It feels like something like IFS=$'\n\0' should be used somewhere, but
I guess not.

Jeff

--- PyGate Linux v1.5.18
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Mon, Jul 06, 2026 at 14:55:57 -0400, Jeffrey Walton wrote:

On Mon, Jul 6, 2026 at 11:52?AM Vincent Lefevre <vincent@vinc17.net> wrote:

I've eventually found the issue. This is due to the newline character
after the passphrase, which cryptroot-unlock doesn't remove! I could confirm with "echo -n <passphrase> | ssh ...", which works.

I've reported the bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1141580

(I thought I had tried with "printf %s <passphrase>" earlier,
but I may have made a mistake in my test.)

In your bug report, you mention that you didn't want to use
"echo -n <passphrase>" on a multi-user system. Presumably, this is
because you want to avoid having the passphrase visible in "ps" or
similar process listings. But echo is a shell builtin, in both bash
and dash. Because it's a shell builtin, it will not be visible as a
process.

That said, "printf %s" is superior to "echo -n", because "echo -n" will potentially interpret some of the characters in its argument. "printf %s"
is guaranteed not to do so. And printf is also a shell builtin, in both
bash and dash, so it's also safe from being listed as a processm, just
like echo.

It feels like something like IFS=$'\n\0' should be used somewhere, but
I guess not.

This is not possible in shells. Shell variables are stored as C strings,
in which the NUL byte marks the end of the string. It's simply impossible
to include a NUL byte as a meaningful character in a string in a shell,
even in special variables like IFS. If you execute IFS=$'\n\0' you will
get exactly the same result as if you'd used IFS=$'\n'.

There are tricks you can use in shells to handle streams of NUL-delimited
data. The three most common are:

* You can call tools like "xargs -0", "sort -z" and so on.

* Bash has had "read -d" forever (since version 2.04), which lets read
a single string terminated by a specific delimiter. It lets you pass
the empty string '' as the delimiter, to signify the NUL byte.

* Bash 4.4 and above also have "readarray -d", which lets you populate
a shell array variable with elements read from a stream with a chosen
delimiter. As with "read -d", you can pass '' as the delimiter to
indicate a NUL-delimited input stream.

--- PyGate Linux v1.5.18
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-07-06 15:15:09 -0400, Greg Wooledge wrote:

In your bug report, you mention that you didn't want to use
"echo -n <passphrase>" on a multi-user system. Presumably, this is
because you want to avoid having the passphrase visible in "ps" or
similar process listings. But echo is a shell builtin, in both bash
and dash. Because it's a shell builtin, it will not be visible as a
process.

Indeed, but I'm wondering whether I can be sure as this is a machine
where I am not the admin. This needs to remain true for at least
10 years, for any /bin/sh that could be used.

Using "tr -d '\n' < file" is probably better.

That said, "printf %s" is superior to "echo -n", because "echo -n" will potentially interpret some of the characters in its argument. "printf %s"
is guaranteed not to do so. And printf is also a shell builtin, in both
bash and dash, so it's also safe from being listed as a processm, just
like echo.

I suppose that for a passphrase (thus without control characters),
"echo -n" and "printf %s" are equivalent.

[...]

Shell variables are stored as C strings, in which the NUL byte marks
the end of the string.

This is a choice of implementation (zsh does not do that, for instance).
That said, NUL bytes in variables are not portable.

--
Vincent Lef?vre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

--- PyGate Linux v1.5.18
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)