If you try to authenticate using an Aventra MyEID you can get hit with a "Smart card malfunction" error message. This is what the log says:
> 2020-12-04T09:40:16: SSH agent request: SSH2_AGENTC_SIGN_REQUEST
> 2020-12-04T09:40:16: Preparing signature operation...
> 2020-12-04T09:40:16: Finding certificate with serial 009c110178275b0b34
> 2020-12-04T09:40:16: Getting certificates for slot 0
> 2020-12-04T09:40:16: Getting certificate with id 39526224
> 2020-12-04T09:40:16: Certificate found
> 2020-12-04T09:40:16: Logging in...
> 2020-12-04T09:40:16: Querying user for passphrase...
> 2020-12-04T09:40:17: Finding private key...
> 2020-12-04T09:40:17: Signing data...
> 2020-12-04T09:40:17: Signature operation failed (33)
> 2020-12-04T09:40:19: SSH agent response: Failed to produce signature
This seems to be some bug or limitation with the Aventra cards as it only happens when the signature data is above a certain limit. In practice that means that the rsa-sha2-512 algorithm doesn't work, but everything else is fine.
The limit scales with the key size, so this only happens with 1024 bit keys. The limit for 2048 bit keys is large enough to handle rsa-sha2-512. So in practice this is hopefully not an issue.
This also happens in very old SetCOS cards. We can reproduce the exact same problem with Telia EID IP2s cards, that are using Setec Oy¹ SetCOS 4.4.1. With a 1024 bit key 51 bytes works, and 52 bytes fails, just like the Aventra cards.
On the plus side, the later Telia EID IP5a cards, using SetCosXpresso 2.1.0, don't seem to have this limitation. With a 2048 bit key I can sign all the way up the expected limit of 245 bytes.
Unfortunately we cannot program these cards so we cannot test with other key sizes.
¹ Later Gemplus, then Gemalto, now Thales DIS
In theory you should be able to work around this by disabling rsa-sha2-512 in sshd. Unfortunately they have a FIXME in the code that advertises supported algorithms to the client:
> /* XXX filter algs list by allowed pubkey/hostbased types */
So sshd will always advertise absolutely everything, no matter what the config says. The client will then try rsa-sha2-512, since sshd claims that is supported, and then fail once the proper check is done:
> Sep 20 14:35:07 ubuntu2004 sshd: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedKeyTypes [preauth]
I've poked upstream and see if this might be fixed in a future update: