search

Nitrokey / nitrokey-start-firmware

A mirror of Gnuk's 1.0.x and 1.2.x branches.
56 stars 15 forks source link

OpenSSH 9.0 support #67

Closed szszszsz closed 1 year ago

szszszsz commented 2 years ago

We have received a report, that Nitrokey Start might have some problems with OpenSSH 9.0 support. At the moment we do not know if the cause is located in the Nitrokey Start firmware (RTM.12 / 1.2.15) or the client applications (GnuPG or OpenSSH).

Connected tickets:

Pasting redacted content of the HT28294 ticket below. Regarding the mentioned log, the last PC_to_RDR_XfrBlock packet sizes just before the failure are 259 and 33. The former looks too big at a first glance. Ideal would be to compare full log output with the one produced by a working setup.

I'm currently trying to setup my Nitrokey Start for SSH authentication.

I have setup ~/.gnupg/gpg-agent.conf to use `enable-ssh-support` and
point my `SSH_AUTH_SOCK` to the correct place while ensuring that
`GPG_TTY` is set correctly and that this is used properly in my ssh
config via `Match host * exec "gpg-connect-agent UPDATESTARTUPTTY
/bye"`.
My main key has the [SC] capability (ed25519) and I have two subkeys
(one with [E] (cv25519) and one with [A] (ed25519) capabilities).
You can get it via `sq wkd get dave@******.de`.

I have setup a test host with the exported key `gpg --export-ssh-key
<ID>` and when attempting the ssh connection I get queried for the
nitrokey's PIN.
After entering the pin though I get the infamous:

    sign_and_send_pubkey: signing failed for ED25519 "cardno:FFFE ********" from agent: agent refused operation

and scdaemon provides me with

    2022-05-01 19:25:25 scdaemon[3354468] operation auth result: Conditions of use not satisfied
    2022-05-01 19:25:25 scdaemon[3354468] app_auth failed: Conditions of use not satisfied
    2022-05-01 19:25:25 scdaemon[3354468] DBG: chan_7 -> ERR 100663427 Conditions of use not satisfied <SCD>

(Full log in attachment)

I have also tried adding the [S] capability to the [A] subkey, but this
leads to the same result.

This is gnupg 2.2.35, openssh 9.0p1 and the latest firmware for the
Nitrokey Start (on Arch Linux).

For testing purposes I also provided `-o
KexAlgorithms=-sntrup761x25519-sha512@openssh.com` to ssh to disable the
newer openssh default as there have been issues with it since the
openssh 9 release (these are allegedly fixed with gnupg 2.2.35). This
unfortunately changed nothing.
sanosis commented 2 years ago

Linux Arch, ssh client OpenSSH_9.0p1, OpenSSL 1.1.1n 15 Mar 2022, gpg (GnuPG) 2.2.35, FSIJ-1.2.15-43135739: Nitrokey Nitrokey Start (RTM.10), ed25519

Problems only affect connections to 9p1 servers (maybe 8.9 as well) - I had no problems with dropbear, 7.5, 8.2 servers…

Disallowing -sntrup761x25519-sha512@openssh.com allows direct connection to 9p1 servers, but does not help with connection behind ProxyJump/-J

sanosis commented 2 years ago

When used with new full gpg key (3 subkeys, stored on disk) connections work (both direct and ProxyJump) with and without sntrup761x25519-sha512@openssh.com

szszszsz commented 2 years ago

@sanosis Thank you for sharing! Looks like then the problem lies on the OpenSSH side. Once we will confirm that on our side we can close this ticket. It would be nice to learn, why it does not work for the original reporter, but this is a case for the Nitrokey's Support Forum.

Leaving here a draft of Docker-based scripts for the further/future versions retesting:

dvzrv commented 2 years ago

FWIW: I have the RTM.12 firmware version on that nitrokey start. Even after setting

KexAlgorithms -sntrup761x25519-sha512@openssh.com

in /etc/ssh/ssh_config I am unable to connect to the target host running openssh 9.0p1 (client running 9.0p1).

I have now also tried with 8.9p1 on the target and client host (still fails).

However, this works with 8.8p1 on the client host and whichever version on the target host (also without the KexAlgorithms modification, as that has been implemented only later to guard against post-quantum attacks AFAIK)!

@sanosis: Does this also work for you with RTM.12 firmware version?

@szszszsz: What logs can I provide for a better debug scenario?

dvzrv commented 2 years ago

I sent a mail with ssh and scdaemon logs for openssh 8.8p1 and openssh 9.0p1 to support@nitrokey.com now.

dvzrv commented 2 years ago

A user in the downstream bug report with Arch Linux noticed that gnuk would have to be >= 1.2.16, according to the gnupg ticket: https://dev.gnupg.org/T5931#157711

I guess this would require a firmware > RTM.12?

szszszsz commented 2 years ago

I have just confirmed that there are no 1.2.16 commits in the latest Nitrokey Start firmware release (so it is a plain 1.2.15, not 1.2.15+).

dvzrv commented 2 years ago

@szszszsz Are there any plans of a firmware upgrade, which makes use of gnuk >= 1.2.16?

Currently this setup limits me to using openssh 8.8p1 on all clients and the new KexAlgorithms default sntrup761x25519-sha512@openssh.com has been put in place to prevent "record now, decrypt later" type of attacks.

szszszsz commented 2 years ago

Hi! I am sorry, but the tests results got delayed. Perhaps we can make the release with 1.2.16+ without any further waiting. I will update this ticket about that.

seifertm commented 2 years ago

I'm also affected by this issue for some time now. Is there something I can do to support this?

szszszsz commented 2 years ago

Hi! Just a quick update: we have work on the new release scheduled for the next week, which should fix this ticket.

dvzrv commented 2 years ago

Just a quick update: we have work on the new release scheduled for the next week, which should fix this ticket.

Any news on this? :)

szszszsz commented 2 years ago

Hey @dvzrv ! Sorry for the delay. There are 2 RC versions now released, and are scheduled for retests, along with checking the update procedure over pynitrokey (specifically testing for the right udev rules installed before the update is attempted). While I do not expect any issues regarding the updates (except maybe LED mixup), I recommend to wait just a bit longer until this will be confirmed.

Related:

cc @nitrosimon @robin-nitrokey

seifertm commented 1 year ago

I installed RTM.13-RC2 today and I can confirm it fixes the issue.

szszszsz commented 1 year ago

Great to hear that! If that's not too much to ask, can you test other features too? E.g. multiple identities?

dvzrv commented 1 year ago

Hi, any movement on this?

dvzrv commented 1 year ago

I've now tested this with two identities with firmware RTM.13-RC2 and that seems to be good with both (and client side openssh >= 9.1p1).

seifertm commented 1 year ago

Thank you. I didn't test with multiple identities, but I've been using the new firmware for a month without issues.

dvzrv commented 1 year ago

@szszszsz when will there be an official RTM.13 release for the nitrokey start?

szszszsz commented 1 year ago

@dvzrv I plan it today. I've done the tests yesterday, and all looks good.

szszszsz commented 1 year ago

@dvzrv RTM.13 is finally released. Have fun!