Bug#1012659: python3-paramiko: attempts to use RSA keys as DSA

[David Bremner]

Package: python3-paramiko
Version: 2.10.4-1
Severity: important
Tags: upstream

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

This is arguably RC, since it prevents python3-paramiko in bookworm
from working with RSA keys generated in bookworm.

It seems to be upstream issue 1839 [1], which has been open for more
than a year.

To duplicate,

0) Generate an RSA ssh key

$ ssh-keygen -f test_key -t rsa -P ''

1) Run the following python code. It doesn't really matter whether the
key is in the key is present in authorized_keys, but the test host
should resolve.

import paramiko

username = 'git'
hostname = 'salsa.debian.org'

# ssh-keygen -f test_key -t rsa -P ''
p_key = 'test_key'

client = paramiko.SSHClient()
client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
client.connect(hostname, username=username, key_filename=p_key)

2) Observe the traceback, with lots of talk about dsa

Unknown exception: q must be exactly 160, 224, or 256 bits long
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/paramiko/transport.py", line 2171, in run
handler(self.auth_handler, m)
File "/usr/lib/python3/dist-packages/paramiko/auth_handler.py", line 377, in _parse_service_accept
sig = self.private_key.sign_ssh_data(blob, algorithm)
File "/usr/lib/python3/dist-packages/paramiko/dsskey.py", line 109, in sign_ssh_data
key = dsa.DSAPrivateNumbers(
File "/usr/lib/python3/dist-packages/cryptography/hazmat/primitives/asymmetric/dsa.py", line 244, in private_key
return backend.load_dsa_private_numbers(self)
File "/usr/lib/python3/dist-packages/cryptography/hazmat/backends/openssl/backend.py", line 827, in load_dsa_private_numbers
dsa._check_dsa_private_numbers(numbers)
File "/usr/lib/python3/dist-packages/cryptography/hazmat/primitives/asymmetric/dsa.py", line 282, in _check_dsa_private_numbers
_check_dsa_parameters(parameters)
File "/usr/lib/python3/dist-packages/cryptography/hazmat/primitives/asymmetric/dsa.py", line 274, in _check_dsa_parameters
raise ValueError("q must be exactly 160, 224, or 256 bits long")
ValueError: q must be exactly 160, 224, or 256 bits long

[1]: https://github.com/paramiko/paramiko/issues/1839

- -- System Information:
Debian Release: bookworm/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.17.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-paramiko depends on:
ii python3 3.10.4-1+b1
ii python3-bcrypt 3.2.0-1+b1
ii python3-cryptography 3.4.8-1
ii python3-nacl 1.5.0-2
ii python3-six 1.16.0-3

Versions of packages python3-paramiko recommends:
ii python3-invoke 1.7.0+ds-1

Versions of packages python3-paramiko suggests:
ii python3-gssapi 1.6.12-2

- -- no debconf information

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmKkf/wACgkQA0U5G1Wq
FSFSdRAAhOXmO38RNJ3hhIGijH1uTlUbkuFN0eQto7Ddw/YfQT0ManJnwWJzvyeS
XFJdNuF/xJqMjpmyPFPS2BeL4tlTg4yF/sNQD6h/VqiO5eXV4m1OmOOqjk772mgu
U2hgZyJ31W6ZBvMFeYIKhJ/f6ondEzml/lKAaDumKi13hG3C1IyX3ojyCSlnuvPF
sE5a0olLUaHQxBAkkcjqXCMROv0E9ANFZRDu4+N2LhXeGmG2yO+ejMLgPCBomDSR
tZpAWNfeWBEkDRNNg/HlnVqldCopCy/ozxAsZsJ8yyarPAMJvXmfbcV7qK9De9W5
6uw6ZtvkysTGLdikpjCi2S6uZXFxEczejjZf1M/XE45ZGlb8AqSoHCgwYh7DRO1P
0yKxdAMxqHmGAwmj1FYlaYu99L1IyvJD9KH8WC4l4XvoOFtCfGy9BT5vM27G2wot
lSSYl59mHOvA2rHwTwvrWzXJdIQLPS0b00/3vId8gqK3DJJoIiZl84Jig1FTIuz2
cCBwcJzdBM1foxzoPNIp2vPUel1evRayBptWUSXZZjQuxO0ezLCQnh2Wu/BjDCma
OzhBemytqm0L9km3AyfZ26zLTUjAx7kfIPA/X46BLA6F9ftqapXZXuolTxjkjPEq
UdLjxoYW26HX5vuU6HDeXEy/ONPN4lyJZu2rUxRMliFSdoSPqkU=
=YoNc
-----END PGP SIGNATURE-----

[David Bremner]

I can confirm that using ed25519 keys is a workaround for this
bug. Of course re-keying production servers to get duplicity backups
working may not be easy (or possible) for everyone.