Modifying the
sshd_config file on Solaris requires careful service management to avoid locking yourself out or breaking subsystems like SFTP. The most reliable method to apply changes without disrupting existing sessions is to send a hangup signal to the running daemon rather than performing a full stop and start sequence. This approach ensures that configuration parameters are reloaded while maintaining active connections, provided the syntax in your configuration file is valid.
Understanding the sshd Service in Solaris
Solaris uses the SMF (Service Management Framework) to manage system services, including the Secure Shell daemon. Unlike some Linux distributions that rely solely on init scripts, Solaris tracks the state of
sshd through FMRI (Fault Management Resource Identifier) instances. When you edit the
sshd_config file, typically located at
/etc/ssh/sshd_config, the changes are not immediately active. The daemon must be instructed to read the new configuration file from disk.
It is crucial to distinguish between resetting the service entirely and reloading its configuration. A full reset involves stopping and starting the service, which terminates all current SSH sessions. This can be problematic for administrators managing remote servers where connection loss could lead to data corruption or loss of critical background jobs. Therefore, understanding the difference between a reload and a restart is vital for production environments. For more context on related SSH connectivity issues, you might find
Troubleshooting kex_exchange_identification Error in Linux SSH Connection helpful if you encounter handshake failures after configuration changes.
Validating Configuration Before Applying Changes
Before attempting to restart or reload the SSH service, you must ensure that the modified
sshd_config file does not contain syntax errors. An invalid configuration can cause the SSH daemon to fail to start, leaving you with no remote access to the server. Solaris provides a built-in diagnostic tool for this purpose.
To validate the configuration, execute the following command as root:
# /usr/sbin/sshd -t
This command parses the configuration file and checks for errors. If the file is valid, the command produces no output and returns to the prompt silently. If there are errors, such as unknown directives or mismatched brackets, the command will display specific error messages indicating the line number and nature of the problem. Fix these issues before proceeding to restart the service. Failure to validate first is the most common reason why administrators lose access after editing
sshd_config.
Reloading the SSH Daemon Without Disconnecting Users
The preferred method to apply changes to
sshd_config on Solaris is to send a SIGHUP signal to the running process. This tells the daemon to close its log files and re-read the configuration file, but it keeps existing client connections alive. This is particularly useful when changing non-critical settings like logging levels or banner text.
You can achieve this by finding the Process ID (PID) of the sshd process and sending it the hangup signal. Use the
pkill command with the
-HUP flag:
# pkill -HUP sshd
Alternatively, you can use the SMF tools to manage the service state. While SMF does not have a direct "reload" verb like some other services, sending the signal via
pkill is the standard practice for
sshd on Solaris. After executing this command, verify that the service is still running using
svcs ssh. The status should remain online. Existing users connected to the server will not notice any interruption during this process.
Restarting the Service When Reload Fails
If the reload signal fails to apply changes, or if you have modified critical security parameters that require a fresh session initialization, you may need to restart the service. This action will drop all current SSH connections. Ensure that no critical operations are in progress before proceeding.
Use the SMF commands to stop and then start the SSH service:
# svcadm disable ssh
# svcadm enable ssh
Or, if you prefer a single command that forces a restart regardless of current state:
# svcadm restart ssh
After restarting, verify the service status with
svcs ssh. It should show as
online. Check the logs at
/var/log/syslog or
/var/adm/messages if the service fails to start. Common reasons for failure include incorrect permissions on the
sshd_config file or private keys, which must be owned by root and not writable by others. For insights into resolving permission-related SSH hurdles, consider reviewing
SSH X11 Forwarding Issues: Works for WSL but not Remote Host, which often shares underlying configuration pitfalls.
Managing Subsystems and Authorized Keys
When dealing with subsystems like SFTP, note that they do not require a separate restart if their configuration is handled within
sshd_config. However, changes to user-specific authorized keys or shell restrictions take effect immediately upon the next login attempt, provided the daemon has reloaded its config. Always test changes with a new terminal session rather than relying on an existing one, as the old session may still hold cached credentials or configuration states.
Frequently Asked Questions
What happens if I make a typo in sshd_config?
Typing an invalid directive will cause the validation check (
sshd -t) to fail. If you force a restart without fixing the error, the SSH service will fail to start, locking you out of remote access. Always validate the file before applying changes to prevent this scenario.
Can I reload sshd_config on Solaris 11?
Yes, the process remains the same in Solaris 11. You can use
pkill -HUP sshd to reload the configuration without disconnecting users. The SMF framework continues to manage the service lifecycle, so
svcs ssh remains the correct way to check status.
Why do my existing SSH sessions stay connected after a reload?
Sending a SIGHUP signal only instructs the daemon to re-read its configuration file. It does not terminate established TCP connections. This behavior is intentional to maintain stability for administrators who need to tweak settings without causing downtime for active users.
How do I fix permission errors after restarting sshd?
Ensure that
/etc/ssh/sshd_config and related key files are owned by root and have permissions set to 600 or 644. Incorrect permissions will cause the daemon to refuse to start for security reasons. Use
chmod and
chown to correct ownership and access rights before restarting the service.
Is there a way to apply changes only to new connections?
Yes, reloading the configuration via SIGHUP applies new settings only to newly accepted connections. Existing connections continue to operate under the old configuration until they are closed. This allows for gradual implementation of security policies without immediate disruption.