Être bloqué après avoir utilisé un mot de passe erroné est une contrainte forte dans un environnement EXADATA. Cette situation assez pénible, se règle automatiquement après un délai qui par défaut est assez conséquent. Je vous propose par le présent article de comprendre les mécanismes liés à l’authentification sur l’EXADATA et de pouvoir débloquer vous-même la situation.
Il n’est pas question de remettre en cause la complexité du mot de passe à fournir, seul le délai, à mon sens, mérite notre attention.
Si vous vérifiez le contenu du fichier « /var/log/secure », vous pouvez constater les erreurs d’authentification et la présence du module PAM :

[root@p-exa-node1 ~]# cat /var/log/secure
…
Sep 29 07:35:15 p-exa-node1 sshd[116499]: Failed password for invalid user oracle from 10.99.100.10 port 52417 ssh2
Sep 29 07:35:15 p-exa-node1 sshd[116500]: Disconnecting: Too many authentication failures for oracle
Sep 29 07:35:15 p-exa-node1 sshd[116499]: PAM 6 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=p-exa-console-admin
Sep 29 07:35:15 p-exa-node1 sshd[116499]: PAM service(sshd) ignoring max retries; 7 > 3

 
« PAM » est un service utilisé pour le verrouillage des comptes utilisateurs après un certain nombre d’échecs de connexion de type « ssh ». Son utilisation permet de conserver le nombre de tentatives d’accès et les tentatives infructueuses.
Le module PAM utilise une librairie « pam_tally2.so », et celle-ci est utilisée dans le fichier de configuration « /etc/pam.d/ssh ». Si vous ne souhaitez pas utiliser cette protection sur les intrusions, vous pouvez tout simplement supprimer la ligne correspondante à la librairie « pam_tally2 » dans ce fichier de configuration :

[root@p-exa-node1 ~]# cat /etc/pam.d/sshd
#%PAM-1.0
auth       include     system-auth
auth       required     pam_tally2.so deny=5 onerr=fail lock_time=600
account   required     pam_nologin.so
account   include     system-auth
account   required     pam_tally.so
password   include     system-auth
session   optional     pam_keyinit.so force revoke
session   include     system-auth
session   required     pam_loginuid.so
session   required     pam_limits.so

Pour modifier le temps d’attente en cas de mauvaise authentification, nous vous proposons de changer la configuration dans le fichier « /etc/pam.d/sshd ».
La plupart du temps, nous réduisons le délai de 600 secondes (10 minutes) à 10 secondes, et c’est le paramètre « lock_time » qu’il convient de modifier.

[root@p-exa-node1 ~]# vi /etc/pam.d/sshd
…
auth       required     pam_tally2.so deny=5 onerr=fail lock_time=10
…

Enfin, si vous êtes bloqué sur un serveur de database, un serveur de stockage ou bien une VM, vous pouvez vous connecter sur un autre serveur, et par l’intermédiaire des clés « ssh », accéder au serveur dont les accès ont été suspendus. En d’autres termes, il faut rebondir ailleurs pour accéder au serveur.
Une fois connecté au serveur en question, la liste des comptes bloqués s’affiche en utilisant la commande « pam_tally2 » :

[root@p-exa-node1 ~]# pam_tally2
Login           Failures Latest failure     From
root               1   09/09/15 16:09:36 p-exa-console-admin

Pour débloquer un utilisateur, il faut utiliser la commande « pam_tally2 » avec les arguments « -u » pour donner le nom de l’utilisateur et « -r » pour effectuer une réinitialisation :

[root@p-exa-node1 ~]# pam_tally2 -u root -r
Login           Failures Latest failure     From
root               1   09/09/15 16:09:36 p-exa-console-admin

Par la suite, la commande « pam_tally2 » utilisée sans argument nous montre que le blocage de l’utilisateur en question n’est plus actif car il ne retourne aucune ligne :

[root@p-exa-node1 ~]# pam_tally2

Et voilà, j’espère que cet article vous simplifiera la vie et vous permettra de sortir de situations bien pénibles.