- Products
- Learn
- Local User Groups
- Partners
-
More
Celebrate the New Year
With CheckMates!
Value of Security
Vendor Self-Awareness
Join Us for CPX 360
23-24 February 2021
Important certificate update to CloudGuard Controller, CME,
and Azure HA Security Gateways
How to Remediate Endpoint & VPN
Issues (in versions E81.10 or earlier)
Mobile Security
Buyer's Guide Out Now
Important! R80 and R80.10
End Of Support around the corner (May 2021)
Hi CheckMates,
I am Rajesh, working as Security Engineer.
Recently we upgraded our CheckPoint appliance from R77.30 to R80.10.
We use EXPECT script in our application to login the CheckPoint device as an admin user and change it to "expert" mode to do further changes in the configurations.
This process of changing into "expert" mode from normal ( CLI ) mode used to work perfectly with previous versions of CheckPoint, but is failing with R80.10.
It get stuck at the Password prompt for "expert" in R80.10 though it used to work with previous versions as I said above.
$ ./cpR80.exp aa.bb.cc.dd admin '*********'
spawn ssh admin@aa.bb.cc.dd
This system is for authorized use only.
admin@aa.bb.cc.dd's password:
Last login: Tue Dec 26 09:57:47 2017 from 10.0.xx.xx
cartier> lock database override
CLICMD0201 Config lock is already turned on.
cartier> expert
Enter expert password:
<<Here this should enter into expert mode, but it is not changed>>
EXPECT script for your reference:
$ cat cpR80.exp
#!/usr/bin/expect
set timeout 60
spawn ssh [lindex $argv 1]@[lindex $argv 0]
expect "yes/no" {
send "yes\r"
expect "*?assword" { send "[lindex $argv 2]\r" }
} "*?assword" { send "[lindex $argv 2]\r" }
expect "*>" { send "lock database override\r" }
expect "*>" { send "expert\r" }
expect "*word:" { send "[lindex $argv 2]\r" }
interact
Can anyone help here on how to troubleshoot this issue or shed some more light if anybody faced the same issue just in case.
Thanks,
Rajesh
Here, normal user password and expert user password are configured as same. So I have used [lindex $argv 2] in both the places to provide the password.
I have seen this with another 3rd party application that uses the expect command. R80.10 take 42. My SE has submitted RFE to fix the issue.
Thanks Neil for your reply.
May I know what do you mean by saying "R80.10 take 42."
And where is the RFE submitted ? Is it with CheckPoint or EXPECT script support team ?
Please share more details if possible.
Take 42 refers to the Jumbo Hotfix level applied to R80.10.
For more info on Jumbo Hotfixes, refer to: Jumbo Hotfix Accumulator FAQ.
I assume in this case, the RFE was submitted with Check Point since an SE was mentioned.
correct RFE was submitted with Check Point.
Thank you both Dameon and Neil.
>>For more info on Jumbo Hotfixes, refer to: Jumbo Hotfix Accumulator FAQ.
https://community.checkpoint.com/people/dwelccfe6e688-522c-305c-adaa-194bd7a7becc, I am not able to find a relative issue/fix in the Support page you provided.
Dameon / Neil, Please point me to the right thread so that I can track / find more details on the issue & fix(if available).
Thanks for your time.
The fact an RFE has been filed suggests there is no immediate plan to provide a fix as the product is operating as designed.
You are welcome to open a request for enhancement yourself: Check Point Software Technologies: Product and Feature Suggestions
I recommend using BASH as the login shell for the account that your Expect scripts log in as, as Hugo van der Kooij suggested.
Rajesh,
Why don't you set the shell to BASH for the accounts? Using Expert in an expect script sounds like a workaround.
Yes. We still can do it. But we have lot of scripts in our application which follow this method of logging into expert mode using expert command.
If we do not hear from CheckPoint about fixing this in near future, we will need to modify all our scripts exceptionally for R80.10.
Thanks for your input. Very much appreciated !!.
combining set user with newpass on the same line worked in my case.
expect -> Prompt
send -> set user <<manacctname>> newpass <<manacctnewpwd>>
fyi. I set get an error : clish[4322]: User xxx logged out due to an error from CLI shell
but the password does change.
Hello Rajesh,
I know this thread is old, but I hit the same problem the other day. There is a bug in the password input with R80.10. When using Expect (or just pasting a password), if the \r comes too quickly after the password, it will fail to return the expected output. The same problem is in the "set user $USERNAME password" area as Neil mentioned.
To work around the issues in Expect script, move the \r after a sleep.
...
expect "*word:" { send -- "[lindex $argv 2]" }
sleep 1
send -- "\r"
interact
...
If anyone know if this got patched please let me know.
Thanks!
Kyle
It hasn't. We are running into this issue now that we are starting to upgrade gear. Causing some pain.
Thanks for the tip on sleep. That works for going into expert mode for me on rancid.
Hmmm. Expect scripts for logins. Never the best way.
I would argue that settings the proper shell and using ssh keys to automate this would be the better way.
managing ssh keys on 1k's of devices that are in flux is not necessarily feasible.
I got hit with this on an R77.30 upgrade to R80.20.
I can login fine but when I run expert, expect seems to want to send the password but it never makes it.
I'm using rancid to manage this for all of our network devices so can't just rewrite it to work with bash.
About CheckMates
Learn Check Point
Advanced Learning
WELCOME TO THE FUTURE OF CYBER SECURITY