7:19 p.m.
--------------------------------------------------------------------------------
Fedora Update Notification
FEDORA-2022-ddd33f1a78
2022-01-08 01:18:41.488563
--------------------------------------------------------------------------------
Name : python-paramiko
Product : Fedora 35
Version : 2.9.1
Release : 1.fc35
URL : https://github.com/paramiko/paramiko
Summary : SSH2 protocol library for python
Description :
Paramiko (a combination of the Esperanto words for "paranoid" and
"friend") is
a module for python 2.3 or greater that implements the SSH2 protocol for secure
(encrypted and authenticated) connections to remote machines. Unlike SSL (aka
TLS), the SSH2 protocol does not require hierarchical certificates signed by a
powerful central authority. You may know SSH2 as the protocol that replaced
telnet and rsh for secure access to remote shells, but the protocol also
includes the ability to open arbitrary channels to remote services across an
encrypted tunnel (this is how sftp works, for example).
--------------------------------------------------------------------------------
Update Information:
This update adds support for SHA-2 variants of RSA key verification algorithms
(as described in RFC 8332) as well as limited SSH extension negotiation (RFC
8308).
--------------------------------------------------------------------------------
ChangeLog:
* Sat Dec 25 2021 Paul Howarth <paul(a)city-fan.org> - 2.9.1-1
- Update to 2.9.1
- Server-side support for 'rsa-sha2-256' and 'ssh-rsa' wasn't fully
operable
after 2.9.0's release (signatures for RSA pubkeys were always run through
'rsa-sha2-512' instead) (GH#1935)
* Fri Dec 24 2021 Paul Howarth <paul(a)city-fan.org> - 2.9.0-1
- Update to 2.9.0
- Add support for SHA-2 variants of RSA key verification algorithms (as
described in RFC 8332) as well as limited SSH extension negotiation (RFC
8308) (GH#1326, GH#1643, GH#1644, GH#1925)
How SSH servers/clients decide when and how to use this functionality can be
complicated; Paramiko's support is as follows:
- Client verification of server host key during key exchange will now prefer
rsa-sha2-512, rsa-sha2-256, and legacy ssh-rsa algorithms, in that order,
instead of just ssh-rsa
- Note that the preference order of other algorithm families such as
ed25519 and ecdsa has not changed; for example, those two groups are still
preferred over RSA
- Server mode will now offer all 3 RSA algorithms for host key verification
during key exchange, similar to client mode, if it has been configured
with an RSA host key
- Client mode key exchange now sends the ext-info-c flag signaling support
for MSG_EXT_INFO, and support for parsing the latter (specifically, its
server-sig-algs flag) has been added
- Client mode, when performing public key authentication with an RSA key or
cert, will act as follows:
- In all cases, the list of algorithms to consider is based on the new
preferred_pubkeys list and disabled_algorithms; this list, like with
host keys, prefers SHA2-512, SHA2-256 and SHA1, in that order
- When the server does not send server-sig-algs, Paramiko will attempt
the first algorithm in the above list; clients connecting to legacy
servers should thus use disabled_algorithms to turn off SHA2
- When the server does send server-sig-algs, the first algorithm
supported by both ends is used, or if there is none, it falls back to
the previous behavior
- SSH agent support grew the ability to specify algorithm flags when
requesting private key signatures; this is now used to forward SHA2
algorithms when appropriate
- Server mode is now capable of pubkey auth involving SHA-2 signatures from
clients, provided one's server implementation actually provides for doing
so; this includes basic support for sending MSG_EXT_INFO (containing
server-sig-algs only) to clients advertising ext-info-c in their key
exchange list
In order to implement the above, the following API additions were made:
- 'PKey.sign_ssh_data <paramiko.pkey.PKey>': Grew an extra, optional
'algorithm' keyword argument (defaulting to 'None' for most
subclasses,
and to "ssh-rsa" for '~paramiko.rsakey.RSAKey')
- A new '~paramiko.ssh_exception.SSHException' subclass was added,
'~paramiko.ssh_exception.IncompatiblePeer', and is raised in all spots
where key exchange aborts due to algorithmic incompatibility; like all
other exceptions in that module, it inherits from 'SSHException', and as
nothing else was changed about the raising (i.e. the attributes and
message text are the same) this change is backwards compatible
- '~paramiko.transport.Transport' grew a '_preferred_pubkeys'
attribute and
matching 'preferred_pubkeys' property to match the other, kex-focused,
such members; this allows client pubkey authentication to honor the
'disabled_algorithms' feature
* Mon Nov 29 2021 Paul Howarth <paul(a)city-fan.org> - 2.8.1-1
- Update to 2.8.1
- Fix listdir failure when server uses a locale (GH#985, GH#992); now on
Python 2.7 SFTPAttributes will decode abbreviated month names correctly
rather than raise 'UnicodeDecodeError'
- Deleting items from '~paramiko.hostkeys.HostKeys' would incorrectly raise
'KeyError' even for valid keys, due to a logic bug (GH#1024)
- Update RSA and ECDSA key decoding subroutines to correctly catch exception
types thrown by modern versions of Cryptography (specifically 'TypeError'
and its internal 'UnsupportedAlgorithm') (GH#1257, GH#1266); these
exception classes will now become '~paramiko.ssh_exception.SSHException'
instances instead of bubbling up
- Update '~paramiko.pkey.PKey' and subclasses to compare ('__eq__') via
direct field/attribute comparison instead of hashing (while retaining the
existing behavior of '__hash__' via a slight refactor) (GH#908)
Warning:
This fixes a security flaw! If you are running Paramiko on 32-bit systems
with low entropy (such as any 32-bit Python 2, or a 32-bit Python 3 that is
running with 'PYTHONHASHSEED=0') it is possible for an attacker to craft a
new keypair from an exfiltrated public key, which Paramiko would consider
equal to the original key.
This could enable attacks such as, but not limited to, the following:
- Paramiko server processes would incorrectly authenticate the attacker
(using their generated private key) as if they were the victim. We see
this as the most plausible attack using this flaw.
- Paramiko client processes would incorrectly validate a connected server
(when host key verification is enabled) while subjected to a
man-in-the-middle attack. This impacts more users than the server-side
version, but also carries higher requirements for the attacker, namely
successful DNS poisoning or other MITM techniques.
* Mon Oct 11 2021 Paul Howarth <paul(a)city-fan.org> - 2.8.0-1
- Update to 2.8.0
- Administrivia overhaul, including but not limited to:
- Migrate CI to CircleCI
- Primary dev branch is now 'main' (renamed)
- Many README edits for clarity, modernization etc.; including a bunch more
(and consistent) status badges and unification with main project site
index
- PyPI page much more fleshed out (long_description is now filled in with
the README; sidebar links expanded; etc.)
- flake8, pytest configs split out of setup.cfg into their own files
- Invoke/invocations (used by maintainers/contributors) upgraded to modern
versions
- Newer server-side key exchange algorithms not intended to use SHA1
(diffie-hellman-group14-sha256, diffie-hellman-group16-sha512) were
incorrectly using SHA1 after all, due to a bug causing them to ignore the
'hash_algo' class attribute; this has been corrected (GH#1452, GH#1882)
- Add a 'prefetch' keyword argument to
'SFTPClient.get'/'SFTPClient.getfo' so
that users who need to skip SFTP prefetching are able to conditionally turn
it off (GH#1846)
--------------------------------------------------------------------------------
References:
[ 1 ] Bug #1775693 - paramiko lacks support for rsa-sha2-256, leads to
AuthenticationException
https://bugzilla.redhat.com/show_bug.cgi?id=1775693
--------------------------------------------------------------------------------
This update can be installed with the "dnf" update program. Use
su -c 'dnf upgrade --advisory FEDORA-2022-ddd33f1a78' at the command
line. For more information, refer to the dnf documentation available at
http://dnf.readthedocs.io/en/latest/command_ref.html#upgrade-command-label
All packages are signed with the Fedora Project GPG key. More details on the
GPG keys used by the Fedora Project can be found at
https://fedoraproject.org/keys
--------------------------------------------------------------------------------