Solved Should the file /etc/ssh/sshd_config be edited directly?

  • Thread starter Thread starter Deleted member 66267
  • Start date Start date
D

Deleted member 66267

Guest
I need to enable password authorization. Just don't know if it should be edited directly or if shouldn't where to put the config other than the file. Thanks.
 
Ordoban said:
Yes, this file is ment to be edited directly. Keep in mind you have to restart sshd to take effect.
Click to expand...
I would avoid editing it. If you change it, it needs to be merged upon updates. This is not a problem per-se, but it’s something you need to be aware of, and it might cause problems if you’re not careful.

As I mentioned above – if you just want to change one or two settings, it’s better to keep the file in its original state, and instead add an appropriate sshd_flags line to the /etc/rc.conf file (which never requires merging because it contains just the overrides for /etc/defaults/rc.conf).
 
olli@ said:
If you want to change just one or two settings, it’s probably best to put a line like
  sshd_flags="-o key1=value1 -o key2=value2"
in /etc/rc.conf. Command line flags override the settings in the configuration file.
Click to expand...
When you do sysrc sshd_flags+=" -o keyN=valueN" you may also want to add a comment in your sshd_config(5) to always check sysrc sshd_flags. Else it's easy to forget about extra command line flags & wonder why some settings refuse to apply ;) Happened to me occasionally...
 
I want to enable password authorization. The default is no. Which sshd_flags I should set? This is what I want to know.
 
failure said:
I want to enable password authorization. The default is no.
Click to expand...
Password authentication is enabled by default? While PasswordAuthentication is indeed set to no, UsePAM is enabled. Which means you can use passwords or public/private keys to login.

Code: 
     UsePAM  Enables the Pluggable Authentication Module interface.  If set to
             yes this will enable PAM authentication using
             ChallengeResponseAuthentication and PasswordAuthentication in
             addition to PAM account and session module processing for all
             authentication types.

             Because PAM challenge-response authentication usually serves an
             equivalent role to password authentication, you should disable
             either PasswordAuthentication or ChallengeResponseAuthentication.

             If UsePAM is enabled, you will not be able to run sshd(8) as a
             non-root user.  The default is yes.
 
failure said:
I want to enable password authorization. The default is no. Which sshd_flags I should set? This is what I want to know.
Click to expand...
You mean PasswordAuthentication, right? (Note that authorization and authentication are different things.)
Are you sure that you want to enable it? Normally, password authentication is done via PAM (which is enabled by default), so the PasswordAuthentication flag should be kept at the default (i.e. off).
If you really want to change that setting (and you’re aware of the consequences), you can do that by adding the following line to /etc/rc.conf:
  sshd_flags="-o PasswordAuthentication=yes"
and then restart the sshd service.
 
Yeah, all of you are right. I don't need to enable PasswordAuthentication to be able to login with password. Some Linux distros default to key file only and don't accept any kind of password, so I have to turn on PasswordAuthentication as some online tutorial sites told me. This knowledge I bring from Linux can't apply to FreeBSD. I was wrong.
 
sshd(8)
Code: 
     -o option
             Can be used to give options in the format used in the
             configuration file.  This is useful for specifying options for
             which there is no separate command-line flag.  For full details
             of the options, and their values, see sshd_config(5).
 
Hi,

Found solution at http://www.unibia.com/unibianet/freebsd/ssh-server-configuration-management-freebsd

Code: 
mkdir -p /usr/local/etc/ssh/sshd_config.d/
cat << EOF >/usr/local/etc/ssh/sshd_config
Include /etc/ssh/sshd_config
Include /usr/local/etc/ssh/sshd_config.d/*.conf
EOF
sysrc sshd_flags="-f /usr/local/etc/ssh/sshd_config"
service sshd restart

Include option in sshd_config is aviable in new versions of OpenSSH.

For older versions just use:
1) mkdir /usr/local/etc/ssh
2) cp /etc/ssh/sshd_config /usr/local/etc/ssh
3) sysrc sshd_flags="-f /usr/local/etc/ssh/sshd_config"
4) add config changes /usr/local/etc/ssh/sshd_config

I know that I can use sshd_flags="-o option=value" but it do not know how to add March User|Group rules in rc.conf
 
olli@ said:
If you want to change just one or two settings, it’s probably best to put a line like
  sshd_flags="-o key1=value1 -o key2=value2"
in /etc/rc.conf. Command line flags override the settings in the configuration file.
Click to expand...

olli@ said:
I would avoid editing it. If you change it, it needs to be merged upon updates.
Click to expand...

While I understand your reasoning and this might be the best solution, I dislike putting configuration settings in several different places. I would thus prefer putting everything in /etc/ssh/sshd_config. While it is true that this can problems when upgrading (of course you take backups), manually inspecting your customizations every upgrade also allow for a review and some retrospection (is this the correct word?). Perhaps changes you made in the past are no longer needed and can now be removed again.
 
/usr/local/etc is for configuration of third party software; sshd is a service of the base OS, so it's configuration belongs in /etc.
Also, sshd_config has been in /etc/ssh/ since the dawn of time, so moving it somewhere else is guaranteed to cause headaches and confusion. /etc/ssh/sshd_config.local might be a "more correct" approach, yet still prone to cause confusion.
Other than that, moving the config off the root dataset or partition might cause problems in single-user mode or other cases where only the root dataset/partition gets mounted. Or in short: You might lock yourself out of that host if sshd is unable to load its config.

Also: as SirDice pointed out PasswordAuthentication is not needed as UsePAM is enabled by default.
 
Does base SSH support the concept of "include config files from this subdirectory"? I know that happens on Linux systems, not sure if it was a "linux-ism" or something that could be taken advantage of here.
 
mer said:
Does base SSH support the concept of "include config files from this subdirectory"? I know that happens on Linux systems, not sure if it was a "linux-ism" or something that could be taken advantage of here.
Click to expand...
That's actually what I do since I read these comments(#15 and #17) in this thread, and it seems to work for me:
seanthingee

Solved Post in thread 'freebsd-update: files have been modified locally'

I'm also having this issue. What about using sshd_flags like this:

Create a /etc/ssh/sshd_config.custom (or better in something like /usr/local/etc/sshd?) with an include directive like so:
Code: 
Include sshd_config
# Custom stuff below...

Then do:
Code: 
sshd_flags="-f /etc/ssh/sshd_config.customized"
  • Thanks
  • Like
 
gotnull that's a good solution; now if only the config in base had that include directive already, then we only argue about the correctness of putting things in /etc/ssh/sshd_config.d But I look at that being similar to /etc/defaults/rc.conf and /etc/rc.conf
 
Always keep in mind that ingesting configuration from multiple locations (especially locations writeable by any user) also increases the attack surface. For a high-profile service like sshd this is definitely not desirable, so the default configuration should be kept as basic and (reasonably) secure as possible.
 
sko said:
Always keep in mind that ingesting configuration from multiple locations (especially locations writeable by any user) also increases the attack surface. For a high-profile service like sshd this is definitely not desirable, so the default configuration should be kept as basic and (reasonably) secure as possible.
Click to expand...
I don't disagree with this, but given one must already be root to write to /etc/ssh (at least for stock configuration) I think this would be an understandable configuration.
 
mer said:
gotnull that's a good solution; now if only the config in base had that include directive already, then we only argue about the correctness of putting things in /etc/ssh/sshd_config.d But I look at that being similar to /etc/defaults/rc.conf and /etc/rc.conf
Click to expand...
That's right /etc/ssh/sshd_config.d would be fine indeed.
It reminds me the way I used to configure security/sudo, IIRC sudoers.conf has something like include sudoers.d
and then you put your own config in that dir. I like the method and the fact that is ready if you want.
 
  • Like
Reactions: mer
You must log in or register to reply here.
Back
Top