OpenSSH version 9.0 mainly fixes bugs like a memory leak in scp(1) parameter processing and some rare bugs in sshd(8). In addition to these fundamental fixes to the original OpenBSD implementation, the ported variants of sshd(8) have also been improved: the developers have added the handy function to sftp(1) and sftp-server(8), files via
cp (copy data) to copy server side.
Protection against attacks with quantum computers
To protect against potential future quantum computer attacks, OpenSSH developers are already implementing a key exchange method called Streamlined NTRU Prime. NTRU is an open source public key cryptosystem that uses lattice-based cryptography to encrypt and decrypt data. It consists of two algorithms: NTRUEncrypt, which is used for encryption, and NTRUSign, which is used for digital signatures. Unlike other common public key cryptosystems, it is resistant to attacks using the Shor algorithm.
The OpenSSH team defines itself once again as a pioneer in computer security. As one of the first widely used free projects, they now use a secure cryptographic process for quantum computers as standard. Deploying early is by no means a sign of paranoia, but it makes sense: it’s meant to protect against the so-called “capture now, decrypt later” problem, i.e. against the fact that you have to start now to protect in the long run. . relevant data from attacks with quantum computers.
Encrypting user data using a symmetric method like AES with 256 or almost any number of bits is not the real problem in quantum computer attacks. It is “only” to decipher the exchange of the pair of random keys generated for this purpose, which until now has been carried out with a conventional Diffie-Hellman key exchange based on elliptic curves (X25519 ECDH).
This method is considered to be susceptible to quantum cryptographic attacks, even if the current (known) performance, i.e. the number of quibits, of the first quantum computer is far from sufficient. There are many estimates of how many qubits it takes to crack asymmetric encryption in a timely manner, probably in the range of several thousand qubits. Where is the current research? Google showed off its Sycamore processor with 54 qubits last year.
The OpenSSH developers, as part of the OpenBSD community, are aware that new implementations may contain bugs. Instead of just using a new algorithm, the OpenSSH developers are combining NTRU with the X25519 ECD, which has been the standard until now. This is supposed to form a kind of safety net, because the old protection still applies even in the case of unknown security breaches or secret service backdoors.
SFTP instead of scp/rcp
In OpenSSH 8.9/8.9p1, which was released almost two months ago, it was already announced that the scp(1) implementation would no longer use the deprecated and sometimes cumbersome scp/rcp protocol, but instead use SFTP. In particular, handling wildcards and relative paths caused headaches for many administrators due to the necessary use of brackets in quotes. Everything should be easier with SFTP instead of scp/rcp, but users will have to adapt existing scripts. If you can’t or don’t want to do that, you still have the parameter as a last resort
-O. Tells scp(1) to use “legacy scp/rcp”.
Two teams always work on OpenSSH: the actual development is tailored to OpenBSD, therefore following its principles and producing code that is as simple and secure as possible. The second team then adds the necessary code to adapt it to GNU/Linux, Windows, macOS, and other systems. This variant can always be recognized by the suffix p as portable to the version number. The current OpenSSH 9.0 code can from the project page to be downloaded OpenBSD 7.1, due out in May, will of course include the native implementation of OpenSSH 9.0.
Introvert. Beer guru. Communicator. Travel fanatic. Web advocate. Certified alcohol geek. Tv buff. Subtly charming internet aficionado.
Does Cloud Gaming Have a Bright Future? Google and Microsoft´s Latest Moves
Top Games Inc. Enjoys a Record Start to 2023
6 Benefits of Playing the Bitcoin Dice Game