-->

The SSH server actually reads several configuration files. The sshdconfig file specifies the locations of one or more host key files (mandatory) and the location of authorizedkeys files for users. It may also refer to a number of other files. Common configuration options for individual use. There are 2 configuration files for ssh: /etc/ssh/sshconfig which is the configuration for the client SSH, and /etc/ssh/sshdconfig which the configuration for the server SSH. Config.ssh.insertkey (boolean) - By default or if set to true, Vagrant will automatically insert a keypair to use for SSH, replacing Vagrant's default insecure key inside the machine if detected. If you already use private keys for authentication to your guest, or are relying on the default. Sshdconfig — OpenSSH daemon configuration file. Sshd(8) reads configuration data from /etc/ssh/sshdconfig (or the file specified with -f on the command line). The file contains keyword-argument pairs, one per line. For each keyword, the first obtained value will be used.

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

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.

Not supported

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

• 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

If you are even a tad bit familiar with SSH, you know that you can use it to connect to remote Linux systems.

Using SSH to connect to remote system is simple. All you need to do is to use a command like this:

This connects to the default SSH port 22. You may specify the port as well if you want.

Now this is all plain and simple if you just have one server. Even if you don’t remember the server’s IP address, you can perform a reverse search to the history using the famous terminal keyboard shortcut Ctrl+R and find the SSH command you used in the past.

But things get complicated when you have several servers to manage. I have around ten servers that I connect to from time to time. Some are production servers and some are test servers.

Now keeping a track of these servers is not easy. Even if I can find the SSH commands from the history, it is difficult to guess which IP belongs to which server.

Of course, I can open my dashboards on Linode, UpCloud, DigitalOcean and Google Cloud to get the IP or keep a list on my local system.

A better and easier way is to use SSH config file.

Using SSH config file for easily connecting to remote servers

The SSH config file allows you to create different profiles for different host configurations. There is no limit to such profiles and you may add as many as possible.

So, if you connect to multiple remote systems via SSH, creating SSH profiles will be a good move to save your time.

Let me show you how to use it.

Step 1: Create the SSH config file

When you install SSH, you’ll have a ~/.ssh directory created automatically. This direct contains your public key, private key a known_hosts file. Your config is also stored here.

At least on Ubuntu, the SSH config file is not created by default. You can easily create this file using the touch command like this:

Step 2: Add an SSH profile in the config file

Now that you have the SSH config file, you can edit it using Vim or Nano. Let me show you an example of the syntax which you should follow.

Let’s say you connect to a server with IP 275.128.172.46. Your username is Alice and the server is used for hosting your website. To harden SSH security, you use port 1500 instead of the default SSH port 22.

Restore Default Ssh Config

You can add all this information in the following manner in your ~/.ssh/config file:

Just save the information in the file. No need to restart any service.

Now, instead of writing a long command like this:

You can just use this command (tab completion works as well):

When you run the above command, ssh looks for a Host named website in the ~/.ssh/config. If it finds a host with that name, it gets all the information related and used it for making an SSH connection.

You might wonder about a few things, so I’ll mention it here:

• There is no space or tab indention restriction while entering the host information. Space or tab indention are used for making the config file easily understandable.
• The Hostname can be the IP address of the server or a hostname that can be resolved on your network.
• All the parameters like hostname, user and port are optional. However, I personally advise keeping at least hostname because that’s what you need (and you forget) most of the time.
• If your SSH config file is wrongly configured, it will result in an error when you try to use it for SSH connection.
• You cannot save passwords in SSH config. I advise adding your public SSH key to the server for easy access.

Step 3: Adding multiple profiles in SSH config file

The previous step gave you an idea about how to add an SSH profile. Let’s take it to the next step by adding multiple profiles in it.

Here’s what the SSH config file looks like now:

This time, I have added four different SSH profiles in it.

Did you notice the Host * entry at the end of the file? You can use this entry to for adding a parameter common to all profiles if that parameter hasn’t been mentioned for the profile explicitly.

So if I try to use the main-server SSH profile, it will automatically take root user.

ssh main-server = ssh root@275.128.172.49

Order of the SSH configuration

The ssh configuration follows the following order:

• command-line options
• user’s configuration file (~/.ssh/config)
• system-wide configuration file (/etc/ssh/ssh_config)

This means that the priority is given to the command you enter and then it looks into ~/.ssh/config and then in /etc/ssh/ssh_config.

So, if you want to override a profile, you can do that using the -o option of the ssh command.

For example, if I use this command:

It will take user bob instead of the user alice as defined in the ~/.ssh/config (in the previous step).

There’s a lot more to SSH config

To be honest, there is so much more to SSH config file that cannot be covered in a single article. You can use name/IP matching, subnets and what not.

Default Ssh Config File Ubuntu

The scope of this article was to introduce you to SSH config and help you create SSH profiles for easily connecting to various remote Linux systems.

You can always refer to the man page of ssh_config to know more about the parameters you can use while creating your SSH config file.

I hope this SSH tip was helpful to you. If you already use SSH config file and have a some nifty tip with you, do share it with the rest of us in the comment section.

Become a Member for FREE

Join the conversation.