- Products
- Learn
- Local User Groups
- Partners
- More
Firewall Uptime, Reimagined
How AIOps Simplifies Operations and Prevents Outages
Introduction to Lakera:
Securing the AI Frontier!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
In R81 sshd_config is replaced after each reboot. You need to do the following to make your changes permanent and survive reboot
Steps:
vi /etc/ssh/templates/sshd_config.templ (Make your changes)
/bin/sshd_template_xlate < /config/active
service sshd reload
Example:
sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/' /etc/ssh/templates/sshd_config.templ
sed -i 's/PermitRootLogin forced-commands-only/PermitRootLogin yes/' /etc/ssh/templates/sshd_config.templ
/bin/sshd_template_xlate < /config/active
service sshd reload
This is probably a bad idea, but it may be a way to accomplish your goal. You could always make the change in /etc/sshd/sshd_config directly, then set the immutable flag on it (chattr +i /etc/sshd/sshd_config). With the immutable attribute set, even root can't change the file.
That suggests there is some config we can change via clish/WebUI now…will have to look.
OK, you've got me confused. I would say you cannot edit binary file with vi editor 😀
@johnguo wrote:vi /bin/sshd_template_xlate (Make your changes)
But your example works like a charm. 👍
One more thing, this is not only for R81, it seems to be the case for R80.40 JHF T83 (at least the blink image dated Dec 9th used in AWS China).
In the mean time, sk106031 was updated with the new procedure for R81, R80.40 JHF T83 and above:
# vi /etc/ssh/templates/sshd_config.templ
...
# /bin/sshd_template_xlate < /config/activ
# service sshd restart
Unfortunately it never survives reboot on R81.10
What did you try to change in /etc/ssh/templates/sshd_config.templ?
If you tried to change mac/cipher/kex algorithms that way, it is normal that this did not survive reboots. This is mentioned in sk106031:
Note: Starting from R81.10, Configuration of Macs and Ciphers - refer to sk179517
That sk says:
From R81.10: the following commands were added to change the configuration using Clish:
set ssh server cipher VALUE off
set ssh server cipher VALUE on
set ssh server mac VALUE off
set ssh server mac VALUE on
show ssh server cipher enabled
show ssh server cipher supported
show ssh server mac enabled
show ssh server mac supported
followed by a "save config" of course.
Did you try to change something in /etc/ssh/templates/sshd_config.templ, that was not moved to confd/clish in R81.10? That should survive reboot as far as I know. Please enlight us 🙂
Hi Tobias, thanks for the response! I'm actually just trying to enable SSH password authentication per sk109587 following these steps:
cp /etc/ssh/templates/sshd_config.templ{,_BKP}
sed -i 's/PasswordAuthentication .*/PasswordAuthentication yes/' /etc/ssh/templates/sshd_config.templ
sed -i 's/PermitRootLogin .*/PermitRootLogin yes/' /etc/ssh/templates/sshd_config.templ
/usr/bin/sshd_template_xlate < /config/active
service sshd restart
I then test it and get the following error: No supported authentication methods available (server sent: publickey)
When I manually check the sshd_config.templ file, PasswordAuthentication and PermitRootLogin are both set to yes as expected. However, when I manually check the /etc/ssh/sshd_config file, it still shows no for PasswordAuthentication and PermitRootLogin is set to forced-commands-only. When I manually change those to yes and restart sshd it works....until I reboot.
Oh, CloudGuard Network. These behave different regarding defaults and maybe the procedure has changed since that sk was written.
Unfortunately, I do not have a CloudGuard Network gateway at hand at the moment, so I am out here. On open server or appliance, it still works like documented even in R81.10 (have tried that).
If you do not get a solution here from CheckMates you may file a support request through TAC or use the provide feedback button in that sk telling the sk owner, that the documented procedure did not work for you in R81.10.
Have you tried using sk179517?
Hi Amir, I'm not trying to change ciphers, just allow password authentication. I opened a ticket with support yesterday letting them know I tried the steps in sk179050 and unfortunately, the response I got was referencing sk179050 telling me to run the commands in that SK with the addition of save config. Of course that didn't help survive a reboot. 😒
Important to note that SSH Key Exchange (KEX) commands are supported in R81.20 CLISH:
show ssh server kex supported
show ssh server kex enabled
set ssh server kex VALUE on
set ssh server kex VALUE off
I verified with nmap (before and after) that the new CLISH commands do allow for modifying the KEX values.
nmap -p --vv --script=ssh2-enum-algos.nse
Huge improvement, especially for anyone dealing with vulnerability scans that discover SHA1 still being offered by GAIA's SSHD.
This is probably a bad idea, but it may be a way to accomplish your goal. You could always make the change in /etc/sshd/sshd_config directly, then set the immutable flag on it (chattr +i /etc/sshd/sshd_config). With the immutable attribute set, even root can't change the file.
Yeah, I'm hoping that doesn't end up being the solution. I've opened a ticket with support and will let you know the outcome.
That is an interesting idea, @Bob_Zimmerman! Hoping there is a better way, but at least there is backup option!
Hi Bob, just wanted to provide an update. Support suggested your workaround, so I guess will be going with that. Thanks for your help!
From Support: We suspect that there is some failure when pushing the new configuration to the Gaia database:
/usr/bin/sshd_template_xlate < /config/active
Without redeploying the AWS instance, we can edit the /etc/ssh/sshd_config file and make the changes permanent with the chattr +i command. Please update us if this is an suitable workaround.
Hi, good to hear,this workaround solved my issue with some AWS instances
Anybody know if it officially solved in any 81.10 jumbo? atm my CP still have Take 66
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
17 | |
12 | |
6 | |
5 | |
5 | |
4 | |
4 | |
4 | |
4 | |
3 |
Tue 07 Oct 2025 @ 10:00 AM (CEST)
Cloud Architect Series: AI-Powered API Security with CloudGuard WAFThu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Thu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Wed 22 Oct 2025 @ 11:00 AM (EDT)
Firewall Uptime, Reimagined: How AIOps Simplifies Operations and Prevents OutagesAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY