VM = Virtual Machine.

I can create Key-Based Authentication for SSH for user root on VM1.
Then I copy the key to VM2 using ssh-copy-id.
When I ssh from VM1 to VM2, it would login without requiring password.

Now if I have VM3, and since there is no public/private keys between VM1 and VM3, ssh will allow use of regular password. I can use some kind of password guessing script and it will succeed easily.

So SSH is obviously not meant for preventing login attacks.
It is for encryption of communication.

So how to prevent login attack when we want to use SSH?
Thank you.

You've answered the main option above in your title: Use keys and turn off password authentication.

You're using Ubuntu possibly so you are going through PAM as well and can tie that to some weird or second authentication method. Some dongles like a Nitrokey or an older model of Yubikey would meet either task.

Or there are options for one-time passwords like OTPW or OPIE.

You can also do some rudimentary rate limiting in iptables. Or supplement that with SSHguard or fail2ban.

Of those, keys are the fastest and easiest to deploy, at least on Ubuntu. Just avoid DSA keys, it is considered insufficient these days and deprecated since OpenSSH 7.0. Ed25519 is probably your best option for future proofing, but RSA may be needed for backwards compatibility with dongles or various software.

2 members found this post helpful.

Thanks.
Also found this:
"Enable SSH Key Logon and Disable Password (Password-Less) Logon in CentOS"

https://www.liberiangeek.net/2014/07...-logon-centos/

That one is ok except that it leaves out a passphrase for the private key and does remote root login. Except in special edge cases, root login should be turned off in /etc/ssh/sshd_config,

Or set to require keys.

You can use an agent to deal with keys with passphrases. That's a good way. Most distros launch an agent for you and it is ready to use. Ubuntu has some Gnome thing that gets in the way and causes the remote server to sometimes choke if you have more than a handful of keys. But there are several ways to mitigate that if you run into that problem.

1 members found this post helpful.

Thank you.
What is this choking problem called?
Would you give some mitigation solutions?

I don't know that it has a name. The Gnome keyring, if I remember correctly, reads in all the keys it finds and keeps them in memory. But it does not match the keys with the correct server so it tries them in some kind of order that may not guess the right key before the remote server decides it there have been too many bad tries. When the server has gotten too many incorrect keys, it gives up.

One way is to turn off the keyring. That will cause other difficulties if you are used to using it.

Another way, if I recall correctly, is to use IdentitiesOnly in ~/.ssh/config.

A third is on the server set MaxAuthTries to something higher. The default is 6. There is some risk in that, but you can put it under a Match block to limit exposure since it may not be so great to increase that number.

You'll only run into the problem when you have seven or more keys in your agent. A home user might not be in that situation often.

I have two specific suggestions:

(1) If you use SSH "on the front line," use certificate-based security only, and disable "password login" as an alternative. Above all else, you must ensure that a llogin: prompt can never be presented to the outside world. But the weakness of this scheme is that it is rather easy to slip another authorized_keys entry in without being noticed.

(2) As I discuss in my blog-post, How to Build a Dwarvish Door With OpenVPN, SSH should not be "on the front line." IMHO, it should lurk behind a strictly certificate-based OpenVPN server (i.e. listening only to the virtual IP-addresses used by a connected OpenVPN user ...), which uses tls-auth security.

Such a server is quite-literally invisible to the outside world. Unless a supplicant can present evidence of possessing the proper tls-auth digital certificate, the OpenVPN server will not even reply. It will silently drop the packet. Those who possess two authentic, non-revoked certificates will pass through the magic door effortlessly within a matter of a few seconds. All others have no hope of entering ... or even discovering ... that same door.

Then, within that secure perimeter, you deploy certificate-based SSH security as your second strong line of defense.

With these defenses in place, the number of "unauthorized access attempts" becomes very easy to count: "the answer is zero."

VPN is (IMHO) also "generally superior" (saying that, of course, "with a great big sweep of my hand") because everything bound for the secure destination (or, as the case may be, everything ...) goes through that tunnel, automagically. Applications don't have to do anything special. You don't have to worry about traffic passing through the Wooly Wiley Webbie "in the clear." It won't.

The configuration file sshd_config doesn't have to point to a file that is writable by the users nor in a directory writable by the users. Setting AuthorizedKeysFile to something custom can fix that, but it will also mean that any time the certificates or keys are updated the sysadmin must intervene, usually manually.

1 members found this post helpful.

That is an excellent and helpful point. "Faved."