Host-based backup of VMware vSphere VMs.
Post Reply
stuartmacgreen
Expert
Posts: 149
Liked: 34 times
Joined: May 01, 2012 11:56 am
Full Name: Stuart Green
Contact:

KB1512 User Authentication failed "Adding Linux server"

Post by stuartmacgreen »

Hit the symptoms in this KB http://www.veeam.com/KB1512

SSHD_CONFIG file on my systems is set to this with the comment as seen:

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no

So the article states I need to set the value to yes above to make SSH Connection work. This is not in doubt. But...
What is the impact.?
The KB article could be a bit more technical as to the explanation of the Cause.

"The configuration of your SSH server does not allow using tunnelled clear text passwords."

There is a lot of confusion on internet as to what this setting does.
Is it sent clear text over SSH. Or is it still encrypted but only clear once it has come out of the tunnel?

Thoughts anyone.
Gostev
Chief Product Officer
Posts: 31559
Liked: 6722 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: KB1512 User Authentication failed "Adding Linux server"

Post by Gostev »

SSH communication is always encrypted, as the name implies (Secure Shell). If you try and deploy SSH server manually on a Linux box, you will see public and private encryption keys generated during setup.
tsightler
VP, Product Management
Posts: 6012
Liked: 2843 times
Joined: Jun 05, 2009 12:57 pm
Full Name: Tom Sightler
Contact:

Re: KB1512 User Authentication failed "Adding Linux server"

Post by tsightler » 1 person likes this post

SSH supports multiple authentication methods, with the most common types being simple, interactive password authentication and public key based authentication. When "PasswordAuthentication" is set to "no" this disables the ability to use the interactive password authentication method, allowing only public key authentication. Many people consider using password only authentication to be unsafe because of the ability for it to be "brute forced" simply by trying passwords many, many times.

If you implement other means of protecting against brute force this is less of an issue. For example, my systems only allow 5 attempts with an incorrect password before banning a given IP address for 21 days, and 10 attempts before disabling the account for an hour. Many, many systems that are exposed to the internet use SSH with password authentication enabled.

Even though this method is sometimes referred to as "plaintext password" authentication, the password itself is still sent inside the encrypted transport layer, otherwise SSH wouldn't be very secure. You can read about the details of the SSH password authentication method in RFC 4252 starting on page 9.

Note that I'm not saying that key based authentication isn't safer than password, but in reality password authentication in SSH is at least as safe as password authentication for every other system which uses passwords (likely your Windows systems, online bank, Gmail, etc) assuming it is implemented in a reasonable way and the passwords themselves meet basic complexity guidelines.
Post Reply

Who is online

Users browsing this forum: Bing [Bot], mikeely and 82 guests