OpenSSH 8.2 released
Posted Feb 15, 2020 11:43 UTC (Sat) by Sesse- OpenSSH 8.2 was released on 2020-02-14.
- FIDO U2F OpenSSH version 8.2 added support for FIDO U2F hardware authenticators. FIDO devices are supported by the public key types “ecdsa-sk” and “ed25519-sk', along with corresponding certificate types.
OpenSSH 8.2 released. OpenSSH 8.2 is out. This release removes support for the ssh-rsa key algorithm, which may disrupt connectivity to older servers; see the announcement for a way to check whether a given server can handle newer, more secure algorithms. Also new in this release is support for FIDO/U2F hardware tokens.
(subscriber, #53779)Parent article: OpenSSH 8.2 releasedDeprecation of older key exchange types is all fun and games, but not when you have older switches you want to SSH to (and that are no longer getting new OS releases). What's the real alternative? Surely SHA-1 can't be so broken that telnet is better :-)
(“-oKexAlgorithms=+diffie-hellman-group1-sha1 -c 3des-cbc” frequently helps, but not in all cases.)
(Log in to post comments) OpenSSH 8.2 released
Posted Feb 15, 2020 12:51 UTC (Sat) by pizza (subscriber, #46) [Link]
...Surely a $50K barrier to entry (rsa-sha1) is better than forcing us to use a mechanism whose barrier to entry is $0 (ie telnet)(See also: https with SSL3/TLS1.0/TLS1.1 vs plain http)
OpenSSH 8.2 released
Posted Feb 15, 2020 14:22 UTC (Sat) by qyliss (guest, #131684) [Link]
SSL3/TLS1.0/TLS1.1 leave users of modern protocols open to downgrade attacks. Using those means making everybody liable to downgrade attacks, unlike plain HTTP. They’re not just being disabled out of spite.OpenSSH 8.2 released
Posted Feb 15, 2020 17:53 UTC (Sat) by pizza (subscriber, #46) [Link]
Yep, and by all means, remove support for them on the _server_ side of things so they require up-to-date clients to speak.But on the client side, there's a very long tail of crap we need to communicate with that will *never* see updates to TLS 1.2 or beyond. and it is highly delusional to pretend that there is no cost to replacing them.
By all means, have the clients COMPLAIN VERY LOUDLY or require special command line switches or whatever to speak with this older gear.
(The software for configuring the RAID controllers in two of my servers maxes out at TLS1.0, as does the https support in all of the network switches I have deployed. Granted, this stuff is all on private networks, but I don't want to have to keep around a VM with ancient software on it to administer things..)
Accessing no-longer-secure systems
Posted Feb 15, 2020 22:14 UTC (Sat) by tialaramex (subscriber, #21167) [Link]
Probably the most practical / least disruptive approach is to have a proxy whose purpose is to manage this differential for you.The proxy would present as a modern service (modern protocols and key support) but behind the scenes simply connect to the real backend using older insecure protocols and keys.
This way the insecurity is limited to those who consciously choose to use the proxy that doesn't deliver security. I guess this could either be an appliance one purchases (with lets hope a longer support lifetime than the devices you've had problems with) or software.
Accessing no-longer-secure systems
Posted Feb 15, 2020 23:56 UTC (Sat) by pizza (subscriber, #46) [Link]
No, the most practical / least disruptive approach is to disable https altogether, and go back to plain http with plaintext credentials.Openssh 8.2 Cve
Mission accomplished, I guess.
OpenSSH 8.2 released
Posted Feb 16, 2020 3:49 UTC (Sun) by mirabilos (subscriber, #84359) [Link]
Full ACK.I’ll also be running into this (AIUI it’s about server keys, not about user keys) and very annoyed.
OpenSSH 8.2 released
Posted Mar 3, 2020 0:53 UTC (Tue) by rodgerd (guest, #58896) [Link]
OpenSSH 8.2 released
Posted Feb 15, 2020 13:42 UTC (Sat) by dumain (subscriber, #82016) [Link]
The alternative to OpenSSH 8.2 isn't Telnet but a second,older, copy of ssh under a different name.Keeping an extra copy of ssh around might require a bit of work but is better to require people to do extra work to be insecure than requiring extra work to be secure. If you want to you can even rename the older ssh binary to telnet.
OpenSSH 8.2 released
Posted Feb 16, 2020 6:25 UTC (Sun) by djm (subscriber, #11651) [Link]
OpenSSH 8.2 released
Posted Feb 16, 2020 9:57 UTC (Sun) by Sesse (subscriber, #53779) [Link]
OpenSSH 8.2 released
Posted Feb 16, 2020 19:15 UTC (Sun) by josh (subscriber, #17465) [Link]
OpenSSH 8.2 released
Posted Feb 16, 2020 19:18 UTC (Sun) by Sesse (subscriber, #53779) [Link]
OpenSSH 8.2 released
Posted Feb 20, 2020 8:08 UTC (Thu) by smurf (subscriber, #17840) [Link]
Yes. I've got a managed switch (in a secure internal network!) that sports a 768bit RSA host key. There also are a bunch out there that want to use DSA keys. Ugh, but can't be helped.Seriously, that level of backwards incompatibility is disappointing. Keeping an older release isn't always feasible either; these may have security bugs or compiler incompatibilities that require significant efort to work around.
Keep the old (client) code behind an '-o insecure-old-server=true' flag which refuses to talk to new servers (so it can't be the default) but don't remove it entirely. PLEASE.
OpenSSH 8.2 released
Posted Feb 20, 2020 14:32 UTC (Thu) by smoogen (subscriber, #97) [Link]
Embedded hardware inside of very expensive capex (say the melter on a steel-mill which is a $10 million minimum replacement or some textile mill or plastic extruder or in a hospital a giant MRI device) usually will be in service for 20 to 40 years. Even when the hardware is serviceble, it is assumed that it will need to interact with other parts which have not been upgraded.. so you keep whatever was done at the time of building for at least 20 years. That means all the hardware you finally got upgraded to have ssh in the last 20 years (versus telnet before) is locked with whatever SSL and SSH algorithms from when the base model was manufactured. So an industrial IT department is locked with needing multiple copies of browsers and tools to deal with these 'forced' upgrades..And after a while, management looks at the costs and dictates to do what @pizza said was the lowest common denominator: turn off ssh/ssl and move back to http and telnet.
OpenSSH 8.2 released
Posted Feb 22, 2020 8:58 UTC (Sat) by niner (subscriber, #26151) [Link]
OpenSSH 8.2 released
Posted Feb 22, 2020 16:11 UTC (Sat) by smoogen (subscriber, #97) [Link]
The issue usually is that would require redesigning other hardware and networks and dealing with budgets that the sysadmin who is stuck trying to fix the perambulator on the wizbang does not have access to. By the time it does get fixed it will be 4-5 years from now and probably 1 or 2 reorgs. Usually the small device you are looking at is going to be under 'operational expenses' while the big hardware is 'capital expenses' and they come from different approval organizations.If the sysadmin is lucky they can just keep a directory or VM of 'old' software which they fire up to deal with certain things. Otherwise they end up with having to keep a central noc machine running Potato or Woody which talks to all that hardware til finally some sort of filter does happen.
OpenSSH 8.2 released
Posted Mar 3, 2020 0:55 UTC (Tue) by rodgerd (guest, #58896) [Link]
OpenSSH 8.2 released
Posted Mar 3, 2020 3:32 UTC (Tue) by pizza (subscriber, #46) [Link]
Openssh 8.2 Rpm
Introduction
OpenSSH is a powerful collection of tools for the remote control of, and transfer of data between, networked computers. You will also learn about some of the configuration settings possible with the OpenSSH server application and how to change them on your Ubuntu system.
OpenSSH is a freely available version of the Secure Shell (SSH) protocol family of tools for remotely controlling, or transferring files between, computers. Traditional tools used to accomplish these functions, such as telnet or rcp, are insecure and transmit the user’s password in cleartext when used. OpenSSH provides a server daemon and client tools to facilitate secure, encrypted remote control and file transfer operations, effectively replacing the legacy tools.
The OpenSSH server component, sshd, listens continuously for client connections from any of the client tools. When a connection request occurs, sshd sets up the correct connection depending on the type of client tool connecting. For example, if the remote computer is connecting with the ssh client application, the OpenSSH server sets up a remote control session after authentication. If a remote user connects to an OpenSSH server with scp, the OpenSSH server daemon initiates a secure copy of files between the server and client after authentication. OpenSSH can use many authentication methods, including plain password, public key, and Kerberos tickets.
Installation
Installation of the OpenSSH client and server applications is simple. To install the OpenSSH client applications on your Ubuntu system, use this command at a terminal prompt:
To install the OpenSSH server application, and related support files, use this command at a terminal prompt:
Configuration
You may configure the default behavior of the OpenSSH server application, sshd, by editing the file /etc/ssh/sshd_config. For information about the configuration directives used in this file, you may view the appropriate manual page with the following command, issued at a terminal prompt:
There are many directives in the sshd configuration file controlling such things as communication settings, and authentication modes. The following are examples of configuration directives that can be changed by editing the /etc/ssh/sshd_config file.
Tip
Prior to editing the configuration file, you should make a copy of the original file and protect it from writing so you will have the original settings as a reference and to reuse as necessary.
Copy the /etc/ssh/sshd_config file and protect it from writing with the following commands, issued at a terminal prompt:
Furthermore since losing an ssh server might mean losing your way to reach a server, check the configuration after changing it and before restarting the server:
The following are examples of configuration directives you may change:
- To set your OpenSSH to listen on TCP port 2222 instead of the default TCP port 22, change the Port directive as such:
Port 2222
- To make your OpenSSH server display the contents of the
/etc/issue.netfile as a pre-login banner, simply add or modify this line in the/etc/ssh/sshd_configfile:
Banner /etc/issue.net
After making changes to the /etc/ssh/sshd_config file, save the file, and restart the sshd server application to effect the changes using the following command at a terminal prompt:
Warning
Many other configuration directives for sshd are available to change the server application’s behavior to fit your needs. Be advised, however, if your only method of access to a server is ssh, and you make a mistake in configuring sshd via the /etc/ssh/sshd_config file, you may find you are locked out of the server upon restarting it. Additionally, if an incorrect configuration directive is supplied, the sshd server may refuse to start, so be extra careful when editing this file on a remote server.
SSH Keys
Openssh8.5
SSH allow authentication between two hosts without the need of a password. SSH key authentication uses a private key and a public key.
To generate the keys, from a terminal prompt enter:
This will generate the keys using the RSA Algorithm. At the time of this writing, the generated keys will have 3072 bits. You can modify the number of bits by using the -b option. For example, to generate keys with 4096 bits, you can do:
During the process you will be prompted for a password. Simply hit Enter when prompted to create the key.
By default the public key is saved in the file ~/.ssh/id_rsa.pub, while ~/.ssh/id_rsa is the private key. Now copy the id_rsa.pub file to the remote host and append it to ~/.ssh/authorized_keys by entering:
Finally, double check the permissions on the authorized_keys file, only the authenticated user should have read and write permissions. If the permissions are not correct change them by:
You should now be able to SSH to the host without being prompted for a password.
Import keys from public keyservers
These days many users have already ssh keys registered with services like launchpad or github. Those can be easily imported with:
The prefix lp: is implied and means fetching from launchpad, the alternative gh: will make the tool fetch from github instead.
Two factor authentication with U2F/FIDO
OpenSSH 8.2 added support for U2F/FIDO hardware authentication devices. These devices are used to provide an extra layer of security on top of the existing key-based authentication, as the hardware token needs to be present to finish the authentication.
It’s very simple to use and setup. The only extra step is generate a new keypair that can be used with the hardware device. For that, there are two key types that can be used: ecdsa-sk and ed25519-sk. The former has broader hardware support, while the latter might need a more recent device.
Once the keypair is generated, it can be used as you would normally use any other type of key in openssh. The only requirement is that in order to use the private key, the U2F device has to be present on the host.
For example, plug the U2F device in and generate a keypair to use with it:
Now just transfer the public part to the server to ~/.ssh/authorized_keys and you are ready to go:
References
Openssh 8.2p1 Exploit
Ubuntu Wiki SSH page.
Openssh 8.2 Exploit
Last updated 8 months ago. Help improve this document in the forum.