Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
johnguo
Employee
Employee
Jump to solution

Modify sshd_config in R81

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

 

 

1 Solution

Accepted Solutions
Bob_Zimmerman
Authority
Authority

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.

View solution in original post

0 Kudos
15 Replies
PhoneBoy
Admin
Admin

That suggests there is some config we can change via clish/WebUI now…will have to look.

Srdjan_B
Collaborator
Collaborator

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).

Tobias_Moritz
Advisor

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

0 Kudos
Karen_Askelson
Contributor
Contributor

Unfortunately it never survives reboot on R81.10

Tobias_Moritz
Advisor

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 🙂

0 Kudos
Karen_Askelson
Contributor
Contributor

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.

0 Kudos
Tobias_Moritz
Advisor

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.

0 Kudos
Amir_Senn
Employee
Employee
0 Kudos
Karen_Askelson
Contributor
Contributor

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.  😒

0 Kudos
Fire_Verse
Contributor

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

https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_Gaia_AdminGuide/Content/Topi...

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.

0 Kudos
Bob_Zimmerman
Authority
Authority

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.

0 Kudos
Karen_Askelson
Contributor
Contributor

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.

0 Kudos
dlusk
Participant

That is an interesting idea, @Bob_Zimmerman! Hoping there is a better way, but at least there is backup option!

0 Kudos
Karen_Askelson
Contributor
Contributor

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.

AleLovaz82
Collaborator

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

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events