Freebsd upgrade will change the ssh configuration file

A

Alucn

Code: 
The following changes, which occurred between FreeBSD 13.0-RELEASE and
FreeBSD 13.1-RELEASE have been merged into /etc/ssh/sshd_config:
--- current version
+++ new version
@@ -1,6 +1,6 @@
-#    $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $
+#    $OpenBSD: sshd_config,v 1.104 2021/07/02 05:11:21 dtucker Exp $
 #    $FreeBSD$
 
 # This is the sshd server system-wide configuration file.  See
 # sshd_config(5) for more information.
 
@@ -60,11 +60,15 @@
 # Change to yes to enable built-in password authentication.
 PasswordAuthentication no
 #PermitEmptyPasswords no
 
 # Change to no to disable PAM authentication
+<<<<<<< current version
 ChallengeResponseAuthentication no
+=======
+#KbdInteractiveAuthentication yes
+>>>>>>> 13.1-RELEASE
 
 # Kerberos options
 #KerberosAuthentication no
 #KerberosOrLocalPasswd yes
 #KerberosTicketCleanup yes
@@ -74,18 +78,23 @@
 #GSSAPIAuthentication no
 #GSSAPICleanupCredentials yes
 
 # Set this to 'no' to disable PAM authentication, account processing,
 # and session processing. If this is enabled, PAM authentication will
-# be allowed through the ChallengeResponseAuthentication and
+# be allowed through the KbdInteractiveAuthentication and
 # PasswordAuthentication.  Depending on your PAM configuration,
-# PAM authentication via ChallengeResponseAuthentication may bypass
+# PAM authentication via KbdInteractiveAuthentication may bypass
 # the setting of "PermitRootLogin without-password".
 # If you just want the PAM account and session checks to run without
 # PAM authentication, then enable this but set PasswordAuthentication
+<<<<<<< current version
 # and ChallengeResponseAuthentication to 'no'.
 UsePAM yes
+=======
+# and KbdInteractiveAuthentication to 'no'.
+#UsePAM yes
+>>>>>>> 13.1-RELEASE
 
 #AllowAgentForwarding yes
 #AllowTcpForwarding yes
 #GatewayPorts no
 #X11Forwarding yes
@@ -103,11 +112,11 @@
 #PidFile /var/run/sshd.pid
 #MaxStartups 10:30:100
 #PermitTunnel no
 #ChrootDirectory none
 #UseBlacklist no
-#VersionAddendum FreeBSD-20200214
+#VersionAddendum FreeBSD-20211221
 
 # no default banner path
 #Banner none
 
 # override default of no subsystems
Does this look reasonable (y/n)? n

When upgrading here, only Y can be selected. If N is selected, upgrading will be exited
After Y is selected, the configuration file is broken and SSH cannot connect.
Code: 
#    $OpenBSD: sshd_config,v 1.104 2021/07/02 05:11:21 dtucker Exp $
#    $FreeBSD$

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

# Note that some of FreeBSD's defaults differ from OpenBSD's, and
# FreeBSD has a few additional options.

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile    .ssh/authorized_keys

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# Change to yes to enable built-in password authentication.
PasswordAuthentication no
#PermitEmptyPasswords no

# Change to no to disable PAM authentication
<<<<<<< current version
ChallengeResponseAuthentication no
=======
#KbdInteractiveAuthentication yes
>>>>>>> 13.1-RELEASE

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'no' to disable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the KbdInteractiveAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via KbdInteractiveAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
<<<<<<< current version
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes
=======
# and KbdInteractiveAuthentication to 'no'.
#UsePAM yes
>>>>>>> 13.1-RELEASE

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#UseBlacklist no
#VersionAddendum FreeBSD-20211221

# no default banner path
#Banner none

# override default of no subsystems
Subsystem    sftp    /usr/libexec/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#    X11Forwarding no
#    AllowTcpForwarding no
#    PermitTTY no
#    ForceCommand cvs server
Ciphers 3des-cbc,aes128-cbc,aes192-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr,[EMAIL]aes128-gcm@openssh.com[/EMAIL],[EMAIL]aes256-gcm@openssh.com[/EMAIL],[EMAIL]chacha20-poly1305@openssh.com[/EMAIL]
 
I've upgraded a bunch of servers from 13.0 to 13.1 and got the choice to edit the changes every time.

But yes, if you let the changes go through unedited then the configuration file will be broken and sshd will fail to start.

You'll have to connect via BMC or get physical access and fix the config file.

EDIT: just to say I did learn this the hard way - didn't pay enough attention to the upgrade process for an earlier version upgrade years ago and ended up with a broken sshd configuration. Now I know to watch out for this file in particular.
 
Alucn said:
...
Does this look reasonable (y/n)? n
...
When upgrading here, only Y can be selected. If N is selected, upgrading will be exited
...
Click to expand...
Well, does it look reasonable to you? If yes, go ahead. If no, then merge the ssh config file by hand, and restart the upgrade.

If you can't decide whether it looks reasonable, then it seems you don't understand how to configure ssh. In that case, you should probably not configure it, nor upgrade a configuration you don't understand. You can always read the man page for ssh config in another window if you are not sure.
 
You must log in or register to reply here.
Back
Top