Hi all,
First time poster here. Apologies if I breach any protocols unintentionally.
We have a number of ASAs running "Cisco Adaptive Security Appliance Software Version 9.8(2)" which were failing to back up with rancid version 3.5. I upgraded to 3.7, but had the same problem.
I have worked out, and tested, a solution, and obviously would like to pass it upstream, so that others may benefit.
It seems that v9.8(2) changes the login banner to include information about recent failed login attempts, and this confounds the expect script, because the login regex matches the new banner line, causing expect to attempt to send the login credentials again, when the device is expecting a valid command (such as "enable").
The new banner looks like this:
"""
Logins over the last 63 days: 407. Last login: 01:43:21 UTC Jun 7 2018 from 10.0.34.25
Failed logins since the last login: 0. Last failed login: 23:53:58 UTC May 30 2018 from 194.73.85.254
Type help or '?' for a list of available commands.
"""
The middle line, starting "Failed logins..." is new. Debug output (sanitised) from "clogin -d" shows this:
"""
expect: does " 00:44:39 UTC Jun 7 2018 from ##########\r\nFailed logins since the last login: 0. Last failed login: 23:53:58 UTC May 30 2018 from ################\r\n" (spawn_id exp6) match regular expression "(denied|Sorry)"? (No Gate, RE only) gate=yes re=no
"Login failed"? no
"% (Bad passwords|Authentication failed)"? (No Gate, RE only) gate=yes re=no
"Press any key to continue"? no
"Enter Selection: "? Gate "Enter Selection: "? gate=no
"Last login:"? Gate "Last login:"? gate=no
"Press the <tab> key [^\r\n]+[\r\n]+"? Gate "Press the <tab> key *"? gate=no
"@[^\r\n]+ ([Pp]assword|passwd|Enter password for [^ :]+):"? (No Gate, RE only) gate=yes re=no
"Enter passphrase.*: "? Gate "Enter passphrase*: "? gate=no
"([Uu]sername|Login|login|user name|User):"? (No Gate, RE only) gate=yes re=yes
send: sending "BACKUPUSER\r" to { exp6 }
expect: continuing expect
"""
You can see that this is recognising the "Failed logins..." line as a match for the login prompt, and thus, sending BACKUPUSER, the name of the ssh user being used to back up the device, in response. But the device is expecting a command, so the script bails out.
My proposed change is to add some lines to clogin to ignore the "Failed logins" line, in the "login" proc:
-re "Last failed login:" {
exp_continue
}
-re "Failed logins since the last login::" {
exp_continue
}
Just above the "Last login:" prompt handler:
-re "Last login:" {
exp_continue
}
If this seems sensible, can you please direct me to the contribution procedure and I will send a diff and/or whatever you require.
Apologies for the comapany boiler-plate disclaimer that will get appended to this mail - I have no control over this, sorry.
Regards,
Andy D'Arcy Jewell
Linux/FOSS Operations
CSI LTD
Email: andydj@csiltd.co.uk<https://webmail.csiltd.co.uk/owa/redir.aspx?C=HU8AM4nK5Eer2bME-xi1qLoREAxQntMIF4AlMlgTZaouBREWgl-Lq3-aQlwsKWRBa8ZxAmBuwH8.&URL=mailto%3acally.hickman%40csiltd.co.uk>
Tel: 07711 734555
[cid:image001.png@01D1B726.545CC060]
First time poster here. Apologies if I breach any protocols unintentionally.
We have a number of ASAs running "Cisco Adaptive Security Appliance Software Version 9.8(2)" which were failing to back up with rancid version 3.5. I upgraded to 3.7, but had the same problem.
I have worked out, and tested, a solution, and obviously would like to pass it upstream, so that others may benefit.
It seems that v9.8(2) changes the login banner to include information about recent failed login attempts, and this confounds the expect script, because the login regex matches the new banner line, causing expect to attempt to send the login credentials again, when the device is expecting a valid command (such as "enable").
The new banner looks like this:
"""
Logins over the last 63 days: 407. Last login: 01:43:21 UTC Jun 7 2018 from 10.0.34.25
Failed logins since the last login: 0. Last failed login: 23:53:58 UTC May 30 2018 from 194.73.85.254
Type help or '?' for a list of available commands.
"""
The middle line, starting "Failed logins..." is new. Debug output (sanitised) from "clogin -d" shows this:
"""
expect: does " 00:44:39 UTC Jun 7 2018 from ##########\r\nFailed logins since the last login: 0. Last failed login: 23:53:58 UTC May 30 2018 from ################\r\n" (spawn_id exp6) match regular expression "(denied|Sorry)"? (No Gate, RE only) gate=yes re=no
"Login failed"? no
"% (Bad passwords|Authentication failed)"? (No Gate, RE only) gate=yes re=no
"Press any key to continue"? no
"Enter Selection: "? Gate "Enter Selection: "? gate=no
"Last login:"? Gate "Last login:"? gate=no
"Press the <tab> key [^\r\n]+[\r\n]+"? Gate "Press the <tab> key *"? gate=no
"@[^\r\n]+ ([Pp]assword|passwd|Enter password for [^ :]+):"? (No Gate, RE only) gate=yes re=no
"Enter passphrase.*: "? Gate "Enter passphrase*: "? gate=no
"([Uu]sername|Login|login|user name|User):"? (No Gate, RE only) gate=yes re=yes
send: sending "BACKUPUSER\r" to { exp6 }
expect: continuing expect
"""
You can see that this is recognising the "Failed logins..." line as a match for the login prompt, and thus, sending BACKUPUSER, the name of the ssh user being used to back up the device, in response. But the device is expecting a command, so the script bails out.
My proposed change is to add some lines to clogin to ignore the "Failed logins" line, in the "login" proc:
-re "Last failed login:" {
exp_continue
}
-re "Failed logins since the last login::" {
exp_continue
}
Just above the "Last login:" prompt handler:
-re "Last login:" {
exp_continue
}
If this seems sensible, can you please direct me to the contribution procedure and I will send a diff and/or whatever you require.
Apologies for the comapany boiler-plate disclaimer that will get appended to this mail - I have no control over this, sorry.
Regards,
Andy D'Arcy Jewell
Linux/FOSS Operations
CSI LTD
Email: andydj@csiltd.co.uk<https://webmail.csiltd.co.uk/owa/redir.aspx?C=HU8AM4nK5Eer2bME-xi1qLoREAxQntMIF4AlMlgTZaouBREWgl-Lq3-aQlwsKWRBa8ZxAmBuwH8.&URL=mailto%3acally.hickman%40csiltd.co.uk>
Tel: 07711 734555
[cid:image001.png@01D1B726.545CC060]
