Openssh 7.7

This is a tutorial on How to Configure OpenSSH on CentOS 7. Secure Shell or SSH is a protocol which allows users to connect to a remote system using a client-server architecture. The login session is encrypted and very secure. Today we are going to show you how to configure and use OpenSSH on a Linux VPS using CentOS 7 as an operating system. Configuring OpenSSH on CentOS 7 is a fairly easy task if you carefully follow the tutorial below.
CentOS 7 provides,opensshopenssh-server and openssh-clients packages. The openssh package requires openssl-libs to be installed on the system since it provides some very important cryptographic libraries.

OpenSSH is a free version of SSH (Secure SHell), a program for logging into and executing commands on a remote machine. This package contains the secure shell daemon (sshd). The sshd daemon allows SSH clients to securely connect to your SSH server.

This is a pre-release (non-production ready) UPDATE -We have updated ssh-shellhost.exe binary (fix for #1222) in V7.7.2.0 payload on 8/4/2018. This release includes. Support for auto updating knownhosts via ssh and ssh-keygen. OpenSSH < 7.7 - User Enumeration (2) 2018-12-04T00:00:00. ID EDB-ID:45939 Type exploitdb Reporter Exploit-DB Modified 2018-12-04T00:00:00.

If you order a CentOS VPS Hosting with us you will have all these packages installed on your server. If not, you will need to install them manually.

For that purpose you can use the following command:

Once the packages are installed you are ready to connect to the server via SSH. The default configuration file for the sshd daemon is /etc/ssh/sshd_config and most of the settings for the daemon are defined in this file. Before making any changes, it is recommended to make a copy of the original configuration file so if you experience some problem you can revert the changes back the default.

To view and edit the configuration file you can use a text editor of your choice. We are going to use nano because of its simplicity.

The first thing you might like to change is the listening port number. By default, the SSH daemon listens on port 22 and for security reasons you can change the number to something else. Change the line:

You can use a port number of your choice which is not used by some other service on your CentOS VPS. Once you make the changes you can save and close the file. In order for the changes to take effect, you should restart the SSH daemon.

To improve security even further, it is recommended to use key-based authentication. Key-based authentication will allow you to connect to your server via SSH without using the password of your system user. Instead, you will need to use SSH keys. For more information about how to log in via SSH without password using SSH keys we recommend you to read our dedicated tutorial.

The SSH protocol allows other operations like copying files between two remote hosts to be completed in an encrypted and secure way. For that reason, you can use,scp a remote file copy program, and sftp which is an interactive file transfer program very similar to FTP. For more information on how to use scp and sftp you can read the user manual which is available at http://www.openssh.com/manual.html. We will cover this topic in some of our next Linux based tutorials.

Of course, you don’t have to know how to configure and use OpenSSH on CentOS 7 if you use one of our CentOS 7 VPS hosting services, in which case you can simply ask our expert Linux admins to help you with the OpenSSH configuration and setup on CentOS 7. They are available 24×7 and will take care of your request immediately.

PS. If you liked this post on how to configure OpenSSH on CentOS 7, please share it with your friends on the social networks using the buttons on the left or simply leave a reply below. Thanks.

OpenSSH 7.8 is out. It includes a fix for the usernameenumeration vulnerability; additionally, the default format for theprivate key file has changed, support for running ssh setuid roothas been removed, a couple of new signature algorithms have been added, andmore.

From:	Damien Miller <djm-AT-openbsd.org>
To:	lwn-AT-lwn.net
Subject:	Announce: OpenSSH 7.8 released
Date:	Thu, 23 Aug 2018 18:46:01 -0600 (MDT)
Message-ID:	<e0a2ea1caf6c3409@openbsd.org>

(Log in to post comments)

Private key encryption change

Posted Aug 24, 2018 21:35 UTC (Fri) by tialaramex (subscriber, #21167) [Link]

For the key format change (which anybody reading LWN should probably go fix now, takes like two minutes) It seems fairly reasonable to credit:

https://latacora.singles/2018/08/03/the-default-openssh.html

I'm not clear on whether it's Latacora policy not to credit individuals on that blog, or in fact Latacora is primarily a single person, or what.

But it seems like the overwhelming responses to it were:

1. Well, but I don't really see how this is worse than plaintext? Oh, I see. Well, I guess that's not great news.
2. Why the heck doesn't OpenSSH do this by default for, say, the last several years?
3. OK, I buy your explanation for why some people won't want this, but, again, _default_? Why have a default that supports crazy people but makes everybody else's security worse?

All of which screams 'Change the default' or preferably 'Go back in time, and change the default weeks ago' but time machines are not available to the OpenSSH team.

Private key encryption change

Posted Aug 25, 2018 4:49 UTC (Sat) by k8to (subscriber, #15413) [Link]

Remembering where you parked the time machine is always a bother. A future copy of yourself might have taken it first.

Private key encryption change

Posted Aug 26, 2018 1:44 UTC (Sun) by gus3 (subscriber, #61103) [Link]

But that future copy of me left another copy of the machine somewhere else.

Which simplifies the solution domain, but renders the problem domain much more complex. Kind of like grep and Perl.

Private key encryption change

Posted Aug 25, 2018 13:04 UTC (Sat) by ScienceMan (subscriber, #122508) [Link]

Just a short note to endorse the above in its entirety. For me it took a few more minutes to read the documentation and the post, try out 'ssh-keygen -p -o -f KEYFILE' on an example RSA test key to verify that it did as advertised let me leave the legacy RSA public key untouched while upgrading the private key to the openssh new default format, verify in a test setting that I could use this with any key agent I needed to fire up, and thus resolve to upgrade all of my legacy keys using this procedure.

People reading this who need to keep their existing RSA public keys working until they can look into other methods while avoiding having nasty hackable private keys laying around should do this right away. Read the documentation if you want to find out what this is doing, and compare the public and private keys before and after the procedure if you want peace of mind that you have in fact done a Good Thing (TM). You might as well upgrade your password to something longer and less guessable along the way.

Private key encryption change

Posted Aug 27, 2018 10:44 UTC (Mon) by gdt (subscriber, #6284) [Link]

You might as well upgrade your password to something longer and less guessable along the way.

Can I suggest that passwords are no longer fit for purpose. Even 40-odd bits of randomness for a 'poor' password pushes human limits (eg: IRYgxNV) and 80-odd bits easily exceeds those limits (eg: X7g6zCi2xqKbKzV9). I'm not that comfortable with security recommendations which require beyond-human performance to meet, especially if those recommendations then implicitly criticise people for being human.

Could I suggest that we begin to recommend hardware tokens for authentication? And where services don't support tokens themselves that we suggest a password manager and that access to it be secured by a hardware token?

I've got hopes for U2F FIDO2 as a primary source of authentication which displaces passwords. We'll see.

Private key encryption change

Posted Aug 27, 2018 10:53 UTC (Mon) by cagrazia (subscriber, #124754) [Link]

> Even 40-odd bits of randomness for a 'poor' password pushes human limits (eg: IRYgxNV) and 80-odd bits easily exceeds those limits (eg: X7g6zCi2xqKbKzV9)

Relevant XKCD: https://xkcd.com/936/

Private key encryption change

Posted Aug 27, 2018 11:06 UTC (Mon) by gdt (subscriber, #6284) [Link]

I would suggest the ability to choose 'four random common words' is also beyond human capability. There's no shortage of psychology papers suggesting that human can't make a random choice from 1000-or-so items, yet the xkcd algorithm relies upon such an ability for its strength.

Private key encryption change

Openssh 7.7 - User Enumeration

Posted Aug 27, 2018 12:06 UTC (Mon) by karkhaz (✭ supporter ✭, #99844) [Link]

I don't think this is much of an issue, as it can easily be accomplished in software. There are plenty of password managers and online passphrase generators that offer this option.

Private key encryption change

Posted Aug 27, 2018 18:07 UTC (Mon) by micka (subscriber, #38720) [Link]

You use something like diceware to create the password. With real dice. But that's an implementation detail.

Private key encryption change

Posted Aug 27, 2018 17:19 UTC (Mon) by brouhaha (subscriber, #1698) [Link]

After seeing that, I changed all of my passwords to 'correct horse battery staple', since that phrase has about 44 bits of entropy.

Private key encryption change

Posted Aug 27, 2018 20:42 UTC (Mon) by epa (subscriber, #39769) [Link]

I think that comic's point is more to argue about inane 'password strength' rules that require at least one digit, at least one punctuation character, and so on. It's common to just pick a password and then add the digit 1 and possibly ! to the end to satisfy the requirements. (Some follow a predictable obfuscation scheme replacing all letter I with 1 and all E with 3, car-numberplate-style). If 'best practice' requires you to change your password every thirty days, you just rotate the digit at the end...

Private key encryption change

Posted Aug 27, 2018 18:40 UTC (Mon) by brunowolff (guest, #71160) [Link]

> Even 40-odd bits of randomness for a 'poor' password pushes human limits (eg: IRYgxNV) and 80-odd bits easily exceeds those limits (eg: X7g6zCi2xqKbKzV9).
That has not been my experience. I've found for a password that I use (i.e. type) multiple times a day, I can remember a password with 130+ bits of entropy (e.g. Q'Z@b,WQk!#x?i#gZVv) and even remember it after short breaks (e.g. a week) from using it.

Private key encryption change

Posted Aug 28, 2018 12:46 UTC (Tue) by ledow (guest, #11753) [Link]

Can you remember two passwords of half the strength required?

Congratulations you can remember a single password of the strength required.

Human memory is not yet the limiter. But if it was then a password manager would be in order, protected by something the human has / knows. Not dumbing down to the humans.

Private key encryption change

Posted Aug 28, 2018 8:31 UTC (Tue) by joib (subscriber, #8541) [Link]

As a heads-up, using the new-style encrypted private keys breaks gnome-keyring (at least the version in Ubuntu 16.04, don't know if it has been fixed since). So if you get error messages when trying to ssh to some host like

sign_and_send_pubkey: signing failed: agent refused operation
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

then it means the problem is that gnome-keyring doesn't understand the private key. One solution is to disable gnome-keyring and instead use ssh-agent.

Private key encryption change

Openssh 7.7

Posted Aug 28, 2018 10:45 UTC (Tue) by tialaramex (subscriber, #21167) [Link]

Current gnome-keyring (3.28 onwards at least) doesn't provide its own SSH agent, it just runs the one from OpenSSH and feeds certain keys into that agent

Private key encryption change

Posted Aug 28, 2018 19:12 UTC (Tue) by joib (subscriber, #8541) [Link]

Openssh 7.7 Install

Oh, great, that should(?) fix other long-standing issues with gnome-keyring as well, such as lack of support for ECDSA or Ed25519 keys.

Openssh 7.7 - User Enumeration (2)

FWIW, it seems the relevant bug report is https://bugzilla.gnome.org/show_bug.cgi?id=775981

OpenSSH 7.8 released

Posted Aug 27, 2018 16:03 UTC (Mon) by frostsnow (subscriber, #114957) [Link]

Openssh 7.7 8.1

Related: Use the '-a #' option to increase the number of rounds in your KDF.