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.
-
- Expert
- Posts: 149
- Liked: 34 times
- Joined: May 01, 2012 11:56 am
- Full Name: Stuart Green
- Contact:
-
- Chief Product Officer
- Posts: 31802
- Liked: 7298 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: KB1512 User Authentication failed "Adding Linux server"
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.
-
- VP, Product Management
- Posts: 6035
- Liked: 2860 times
- Joined: Jun 05, 2009 12:57 pm
- Full Name: Tom Sightler
- Contact:
Re: KB1512 User Authentication failed "Adding Linux server"
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.
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.
Who is online
Users browsing this forum: Brian.Knoblauch and 62 guests