2017-05-03 2 views
0

l'observation ci-dessous est pas toujours le cas, mais après un certain temps l'accès au SUT plusieurs fois avec ssh avec l'utilisateur root et mot de passe le code python est en difficulté avec:échec de l'authentification PAM pour la racine pendant python pexpect

Apr 25 05:51:56 SUT sshd[31570]: pam_tally2(sshd:auth): user root (0) tally 83, deny 10 
Apr 25 05:52:16 SUT sshd[31598]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.10.10.13 user=root 
Apr 25 05:52:21 SUT sshd[31568]: error: PAM: Authentication failure for root from 10.10.10.13 
Apr 25 05:52:21 SUT sshd[31568]: Connection closed by 10.10.10.13 [preauth] 

Voici le code python ci-dessous:

COMMAND_PROMPT = '.*:~ #' 
SSH_NEWKEY = '(?i)are you sure you want to continue connecting' 

def scp(source, dest, password): 
    cmd = 'scp ' + source + ' ' + dest 
    try: 
     child = pexpect.spawn('/bin/bash', ['-c', cmd], timeout=None) 
     res = child.expect([pexpect.TIMEOUT, SSH_NEWKEY, COMMAND_PROMPT, '(?i)Password']) 
     if res == 0: 
      print('TIMEOUT Occurred.') 
     if res == 1: 
      child.sendline('yes') 
      child.expect('(?i)Password') 
      child.sendline(password) 
      child.expect([pexpect.EOF], timeout=60) 
     if res == 2: 
      pass 
     if res == 3: 
      child.sendline(password) 
      child.expect([pexpect.EOF], timeout=60) 
    except: 
     print('File not copied!!!') 
     self.logger.error(str(self.child)) 

Lorsque le ssh échoue, c'est l'impression de pexpect:

version: 2.3 ($Revision: 399 $) 
command: /usr/bin/ssh 
args: ['/usr/bin/ssh', '[email protected]'] 
searcher: searcher_re: 
    0: re.compile(".*:~ #") 
buffer (last 100 chars): : 
Account locked due to 757 failed logins 

Password: 
before (last 100 chars): : 
Account locked due to 757 failed logins 

Password: 
after: <class 'pexpect.TIMEOUT'> 
match: None 
match_index: None 
exitstatus: None 
flag_eof: False 
pid: 2284 
child_fd: 5 
closed: False 
timeout: 30 
delimiter: <class 'pexpect.EOF'> 
logfile: None 
logfile_read: None 
logfile_send: None 
maxread: 2000 
ignorecase: False 
searchwindowsize: None 
delaybeforesend: 0 
delayafterclose: 0.1 
delayafterterminate: 0.1 

Tout indice peut-être que pourrait-il être, est-ce quelque chose peut-être manquant ou mal configuré pour l'authentification pam sur mon SUT? Le problème est que lorsque le SUT commence avec ces échecs de pam alors le code python aura toujours le problème et seulement un redémarrage du SUT semble aider :(

L'accès manuel au SUT via ssh root @ ... fonctionne toujours , même si pexpect peut pas !!! Le compte ne semble pas être verrouillé en fonction:.

SUT:~ # passwd -S root 
root P 04/24/2017 -1 -1 -1 -1 

J'ai examiné d'autres questions, mais pas de solution réelle est mentionné ou pourrait travailler avec mon code python

Merci à l'avance

+0

Quelles sont les erreurs que vous pouvez voir sur le code? Quelles conditions sont exécutées? – Jakuje

+0

En fait, il va juste à sauf! Je n'ai pas ajouté de code pour aller chercher le numéro d'erreur ou la condition qui est cassée !!! Je ne sais pas comment le faire d'une manière générale :( – FotisK

+0

J'ai mis à jour avec plus d'informations sur le problème – FotisK

Répondre

0

M y contourner est de modifier à des fins de test les fichiers de configuration pam_tally. Il semble que le SUT reconnaisse l'accès multiple comme une menace et verrouille même le compte root!

En supprimant cette entrée even_deny_root root_unlock_time=5 dans les différents fichiers de configuration pam_tally:

/etc/pam.d/common-account:account required  pam_tally2.so  deny=10 onerr=fail unlock_time=600 even_deny_root root_unlock_time=5 file=/home/test/faillog 
/etc/pam.d/common-auth:auth   required  pam_tally2.so  deny=10 onerr=fail unlock_time=600 even_deny_root root_unlock_time=5 file=/home/test/faillog 

Ces changements seront activés dynamiquement sans redémarrage du service nécessaire!

Remarque: après le redémarrage, ces entrées seront très probablement de retour!