The sshconfig client configuration file has the following format. Both the global /etc/ssh/sshconfig and per-user /ssh/config have the same format. Empty lines and lines starting with '#' are comments. When we are logged into the server we can change Default SSH port by editing sshdconfig file. It is a good practice to have a backup before we make any changes in this file. The following command will create a backup file of sshdconfig file. email protected.

SSH. We know it. We love it. We must use it.

I'm going to take you through eight steps to better help you secure the SSH service on your network. I think we all appreciate the importance of SSH. It allows us to connect to and from Linux devices, Unix servers, network appliances, and sometimes even Windows boxes. I'm not going to try to sell you on how often SSH is used or how important it is. I'm going to provide a solid checklist you can use to ensure SSH services in your environment are locked down.

More Linux resources

1. Backup the config file

First, back up the configuration file before making major changes. This is a common bit of advice, but it's a real one. It's easy, takes only a moment, and protects you in case of a mistake when editing the file. And who hasn't made a mistake in Vim?

See, that's not so bad.

Challenge - Do you consistently back up configuration files before making major edits?

2. Set a banner message

Admittedly, this is as much about legal requirements as anything else, but again, this setting only takes a moment. You can actually provide some pretty good information in banner messages, too. First, we'll write the banner message in the /etc/issue.net file by using Vim. Then we'll open the sshd_config file and tell it to use the content of issue.net as the banner.

[ You might also like: SSH password automation in Linux with sshpass ]

Obviously, you'll want to come up with something specific to your organization. Remove any information that's already in the issue.net file.

Next, tell SSH to use the banner message. Open the sshd_config file in Vim, and find the line that reads Banner. You do remember that you can use the forward-slash character in Vim's Command mode to keyword-search a file, right? For example, /banner

Find the line that reads # no default banner path, and then uncomment the next line (it says Banner).

Save your changes in Vim with :wq and then restart the SSH service:

Note: I'm not going to remind you to restart SSH from this point forward. Any time you make a change to the configuration file, you must restart the service.

Challenge - Is the banner message consistent across all the SSH devices on your network?

3. Prevent empty passwords

This seems like a no-brainer, but empty passwords are clearly a bad idea. You may have other utilities, such as Pluggable Authentication Modules (PAM), regulating your regular passwords, but it's also a good idea to make sure SSH enforces responsible security settings, too.

Open the /etc/ssh/sshd_config file in Vim, and then find the line that reads PermitEmptyPasswords. Uncomment it, and replace the yes value with no.

That's it.

4. Prevent the root user from crossing the network via SSH

The idea here is pretty straightforward. Send standard user credentials across the network instead of root credentials. Once you've established your SSH connection using a standard user account, use su or sudo to elevate your privileges.

Open the SSH configuration file, and then uncomment the PermitRootLogin line. Edit the setting from yes to no.

Challenge - your organization has embraced sudo, right?

5. Whitelist specific user accounts

If you're already preventing the use of the root user account across SSH, why not go a step further and explicitly state which users can connect to the server? Perhaps you have a regular non-root admin account you use or one that's already configured with sudo privileges.

In the SSH configuration file, add the following line (it's not in there by default):

I'd put it near the PermitRootLogin no setting.

By the way, you can actually filter with all of the following settings: AllowUsers, DenyUsers, AllowGroups, DenyGroups. I wrote them in that order on purpose—that's the order in which they are processed. You can discover more information on the man page for sshd_config.

Challenge - be careful about exactly who is authorized.

Note: You can limit connections via iptables, too.

6. No more port 22

Another common change is to configure SSH to listen on a different port than the standard 22/tcp that we've all memorized. There's already an entry in the sshd_config file.

You can comment out the default port setting and add another line, as I've done below:

I suspect many folks use 2222 as the replacement port number, so you may want to standardize on something a little more unique.

You must remember to append the new non-standard port number to your SSH connection attempts from this point on. For example:

Challenge - do you have the same non-standard port number configured for all your SSH destinations? Consistency will make your life much easier.

7. Time's up!

The next tip deals with timing out connections. The ClientAliveInterval manages idle SSH connections. The server sends a message to the client and expects a response. The ClientAliveInterval is the space of time between the messages. The ClientAliveCountMax defines how many times the server will do this before deciding the client isn't really there anymore. At that point, the connection is dropped.

Here is an example configuration that checks every 60 seconds and will do so three times:

Edit these values to something that makes sense for your environment.

Note: If you're using SSH to tunnel for other connections, you may need to ensure that the interval is long enough to properly support whatever other applications are using it.

There's a ServerAliveInterval value that you can configure on the client-side, too. This allows clients to drop connections to non-responsive SSH servers.

8. Here's the key

One of the most common security settings for SSH these days is key-based authentication. Through the years that I've taught Linux, this authentication method has become more and more common. In fact, I wouldn't attempt a Red Hat admin exam without feeling confident in this process. Fortunately, it's not difficult.

Let's do a quick review. Key-based authentication uses asymmetric cryptography. That means there are two keys, different but mathematically related to each other. One is private and never sent across the network. The other is public and may be transferred across the network. Because the keys are related, they can be used to confirm identities—identities such as SSH authentication attempts.

You'll need to generate the key pair on the local SSH client computer and then transfer the public key across the network to the destination SSH server. In other words, the keys will identify you on your admin workstation. Once this configuration is in place, you are no longer challenged for a password when you establish an SSH connection.

The process only requires a few steps.

First, generate the key pair:

The keys are stored in your home directory in a hidden directory named .ssh, and the default key names are id_rsa (private key) and id_rsa.pub (public key).

Next, send the user1 public key across the network to the destination SSH server located at 10.1.0.42:

Finally, test the connection:

Notice that you are not challenged for a password.

Since you have now embraced key-based authentication, you can edit the sshd_config file to prevent any logins based on passwords. Once you configure this setting, only key-based authentication will be accepted.

Edit these two lines in the file:

[ Want to learn more about security? Check out the IT security and compliance checklist. ]

Wrap up

I have listed several common but effective SSH configurations to help you better secure your environment. Remember, with security, no one setting is likely to protect your devices. The goal is layers of security, the combination of which helps to mitigate security threats. I strongly suggest that you carefully organize your keys if you implement key-based authentication. You might also consider using a centralized /etc/ssh/sshd_config file to maintain consistent security configurations on your SSH servers. Don't forget to restart SSH any time you change the configuration file.

This topic covers the Windows-specific configuration for OpenSSH Server (sshd).

Ssh Config File Password

OpenSSH maintains detailed documentation for configuration options online at OpenSSH.com, which is not duplicated in this documentation set.

Configuring the default shell for OpenSSH in Windows

The default command shell provides the experience a user sees when connecting to the server using SSH.The initial default Windows is the Windows Command shell (cmd.exe).Windows also includes PowerShell and Bash, and third party command shells are also available for Windows and may be configured as the default shell for a server.

To set the default command shell, first confirm that the OpenSSH installation folder is on the system path.For Windows, the default installation folder is SystemDrive:WindowsDirectorySystem32openssh.The following commands shows the current path setting, and add the default OpenSSH installation folder to it.

Configuring the default ssh shell is done in the Windows registry by adding the full path to the shell executable to ComputerHKEY_LOCAL_MACHINESOFTWAREOpenSSH in the string value DefaultShell.

As an example, the following Powershell command sets the default shell to be PowerShell.exe:

Windows Configurations in sshd_config

In Windows, sshd reads configuration data from %programdata%sshsshd_config by default, or a different configuration file may be specified by launching sshd.exe with the -f parameter.If the file is absent, sshd generates one with the default configuration when the service is started.

The elements listed below provide Windows-specific configuration possible through entries in sshd_config.There are other configuration settings possible in that are not listed here, as they are covered in detail in the online Win32 OpenSSH documentation.

AllowGroups, AllowUsers, DenyGroups, DenyUsers

Controlling which users and groups can connect to the server is done using the AllowGroups, AllowUsers, DenyGroups and DenyUsers directives.The allow/deny directives are processed in the following order: DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups.All account names must be specified in lower case.See PATTERNS in ssh_config for more information on patterns for wildcards.

When configuring user/group based rules with a domain user or group, use the following format: user?domain*.Windows allows multiple of formats for specifying domain principals, but many conflict with standard Linux patterns.For that reason, * is added to cover FQDNs.Also, this approach uses '?', instead of @, to avoid conflicts with the username@host format.

Work group users/groups and internet-connected accounts are always resolved to their local account name (no domain part, similar to standard Unix names).Domain users and groups are strictly resolved to NameSamCompatible format - domain_short_nameuser_name.All user/group based configuration rules need to adhere to this format.

Examples for domain users and groups

Examples for local users and groups

AuthenticationMethods

For Windows OpenSSH, the only available authentication methods are 'password' and 'publickey'.

AuthorizedKeysFile

The default is '.ssh/authorized_keys .ssh/authorized_keys2'. If the path is not absolute, it is taken relative to user's home directory (or profile image path). Ex. c:usersuser. Note that if the user belongs to the administrator group, %programdata%/ssh/administrators_authorized_keys is used instead.

ChrootDirectory (Support added in v7.7.0.0)

This directive is only supported with sftp sessions. A remote session into cmd.exe wouldn't honor this. To setup a sftp-only chroot server, set ForceCommand to internal-sftp. You may also set up scp with chroot, by implementing a custom shell that would only allow scp and sftp.

HostKey

The defaults are %programdata%/ssh/ssh_host_ecdsa_key, %programdata%/ssh/ssh_host_ed25519_key, %programdata%/ssh/ssh_host_dsa_key, and %programdata%/ssh/ssh_host_rsa_key. If the defaults are not present, sshd automatically generates these on a service start.

Match

Note that pattern rules in this section. User and group names should be in lower case.

PermitRootLogin

Not applicable in Windows. To prevent administrator login, use Administrators with DenyGroups directive.

SyslogFacility

If you need file based logging, use LOCAL0. Logs are generated under %programdata%sshlogs.For any other value, including the default value, AUTH directs logging to ETW. For more info, see Logging Facilities in Windows.

Linux Default Ssh Config File

Not supported

Centos Default Ssh Config

The following configuration options are not available in the OpenSSH version that ships in Windows Server 2019 and Windows 10 1809:

Ssh Default Configuration File

• AcceptEnv
• AllowStreamLocalForwarding
• AuthorizedKeysCommand
• AuthorizedKeysCommandUser
• AuthorizedPrincipalsCommand
• AuthorizedPrincipalsCommandUser
• Compression
• ExposeAuthInfo
• GSSAPIAuthentication
• GSSAPICleanupCredentials
• GSSAPIStrictAcceptorCheck
• HostbasedAcceptedKeyTypes
• HostbasedAuthentication
• HostbasedUsesNameFromPacketOnly
• IgnoreRhosts
• IgnoreUserKnownHosts
• KbdInteractiveAuthentication
• KerberosAuthentication
• KerberosGetAFSToken
• KerberosOrLocalPasswd
• KerberosTicketCleanup
• PermitTunnel
• PermitUserEnvironment
• PermitUserRC
• PidFile
• PrintLastLog
• RDomain
• StreamLocalBindMask
• StreamLocalBindUnlink
• StrictModes
• X11DisplayOffset
• X11Forwarding
• X11UseLocalhost
• XAuthLocation