Bug#1116363: openssh-client: ssh-sk-helper links libcbor.so.0.8 on trixie but only libcbor.so.0.10 is available

Now I feel stupid.
I'm sorry. You are on point, this is caused by a third party package 
which places an outdated libfido2 in /usr/local/lib.

Thank you and sorry for wasting your time.


On 9/26/25 12:18 PM, Colin Watson wrote:
> On Fri, Sep 26, 2025 at 11:55:07AM +0200, Yannik Schmidt wrote:
>>   * What led up to the situation?
>>
>>     Using and existing FIDO2/ecdsa-sk key will fail silently or with 
>> unspecific error messages like "agent refused the action".
>>
>>     Creating a FIDO2 ssh-key with the following command will expose 
>> the problem:
>>
>>        ssh-keygen -t ecdsa-sk -O resident -O verify-required -C "
>>
>>     I then checked:
>>
>>        ldd /usr/lib/openssh/ssh-sk-helper | egrep 'libcbor'
>>            libcbor.so.0.8 => not found
>
> I can't reproduce this on a trixie system here:
>
> $ ldd /usr/lib/openssh/ssh-sk-helper
>         linux-vdso.so.1 (0x00007f0f87f4f000)
>         libfido2.so.1 => /lib/x86_64-linux-gnu/libfido2.so.1 
> (0x00007f0f87ea0000)
>         libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 
> (0x00007f0f87800000)
>         libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0f8760a000)
>         libcbor.so.0.10 => /lib/x86_64-linux-gnu/libcbor.so.0.10 
> (0x00007f0f87e90000)
>         libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 
> (0x00007f0f87e4b000)
>         libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f0f875ea000)
>         /lib64/ld-linux-x86-64.so.2 (0x00007f0f87f51000)
>         libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 
> (0x00007f0f87520000)
>         libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 
> (0x00007f0f87e3d000)
>
> Please show me the full output of ldd, without the egrep on the end?  
> Note that ssh-sk-helper does not link to libcbor directly, but only 
> via libfido2, so something like a libfido2 installation in /usr/local 
> might cause this sort of problem.
>