SFTP Configuration Once all prerequisites of installation are done, we'll step over to configuration phase. For best practice, we need to create a group and user so that we can manage all user that shall get SFTP access. But first, let's create an additional folder called data. The next thing you’ll need to do on your server is to configure the disabled ssh-agent service to automatically start and also configure the sshd service to automatically start. To do this, run the following PowerShell commands: Set-Service -Name ssh-agent -StartupType ‘Automatic’ Set-Service -Name sshd -StartupType ‘Automatic’.
If you're anything like me, you probably log in and out of a half dozen remote servers (or these days, local virtual machines) on a daily basis. And if you're even more like me, you have trouble remembering all of the various usernames, remote addresses and command line options for things like specifying a non-standard connection port or forwarding local ports to the remote machine.
Shell Aliases
Let's say that you have a remote server named dev.example.com, which has not been set up with public/private keys for password-less logins. The username to the remote account is fooey, and to reduce the number of scripted login attempts, you've decided to change the default SSH port to 2200 from the normal default of 22. This means that a typical command would look like:
$ ssh fooey@dev.example.com -p 22000
Ssh Sftp Command
password: *************
Not too bad.
We can make things simpler and more secure by using a public/private key pair; I highly recommend using ssh-copy-id for moving your public keys around. It will save you quite a few folder/file permission headaches.
$ ssh fooey@dev.example.com -p 22000
# Assuming your keys are properly setup…
Now this doesn't seem all that bad. To cut down on the verbosity you could create a simple alias in your shell as well:
$ alias dev='ssh fooey@dev.example.com -p 22000'
$ dev # To connect
This works surprisingly well: Every new server you need to connect to, just add an alias to your .bashrc (or .zshrc if you hang with the cool kids), and voilà.
~/.ssh/config
However, there's a much more elegant and flexible solution to this problem. Enter the SSH config file:
# contents of $HOME/.ssh/config
Host dev
HostName dev.example.com
Port 22000
User fooey
This means that I can simply $ ssh dev, and the options will be read from the configuration file. Easy peasy. Let's see what else we can do with just a few simple configuration directives.
Personally, I use quite a few public/private keypairs for the various servers and services that I use, to ensure that in the event of having one of my keys compromised the damage is as restricted as possible. For example, I have a key that I use uniquely for my Github account. Let's set it up so that that particular private key is used for all my github-related operations:
Host dev
HostName dev.example.com
Port 22000
User fooey
Host github.com
IdentityFile ~/.ssh/github.key
The use of IdentityFile allows me to specify exactly which private key I wish to use for authentification with the given host. You can, of course, simply specify this as a command line option for 'normal' connections:
$ ssh -i ~/.ssh/blah.key username@host.com
but the use of a config file with IdentityFile is pretty much your only option if you want to specify which identity to use for any git commands. This also opens up the very interesting concept of further segmenting your github keys on something like a per-project or per-organization basis:
Host github-project1
User git
HostName github.com
IdentityFile ~/.ssh/github.project1.key
Host github-org
User git
HostName github.com
IdentityFile ~/.ssh/github.org.key
Host github.com
User git
IdentityFile ~/.ssh/github.key
Which means that if I want to clone a repository using my organization credentials, I would use the following:
$ git clone git@github-org:orgname/some_repository.git
Going further
As any security-conscious developer would do, I set up firewalls on all of my servers and make them as restrictive as possible; in many cases, this means that the only ports that I leave open are 80/443 (for webservers), and port 22 for SSH (or whatever I might have remapped it to for obfuscation purposes). On the surface, this seems to prevent me from using things like a desktop MySQL GUI client, which expect port 3306 to be open and accessible on the remote server in question. The informed reader will note, however, that a simple local port forward can save you:
$ ssh -f -N -L 9906:127.0.0.1:3306 coolio@database.example.com
# -f puts ssh in background
# -N makes it not execute a remote command
This will forward all local port 9906 traffic to port 3306 on the remote database.example.com server, letting me point my desktop GUI to localhost (127.0.0.1:9906) and have it behave exactly as if I had exposed port 3306 on the remote server and connected directly to it.
Now I don't know about you, but remembering that sequence of flags and options for SSH can be a complete pain. Luckily, our config file can help alleviate that:
Host tunnel
HostName database.example.com
IdentityFile ~/.ssh/coolio.example.key
LocalForward 9906 127.0.0.1:3306
User coolio
Which means I can simply do:
$ ssh -f -N tunnel
And my local port forwarding will be enabled using all of the configuration directives I set up for the tunnel host. Slick.
Homework
There are quite a few configuration options that you can specify in ~/.ssh/config, and I highly suggest consulting the online documentation or the ssh_config man page. Some interesting/useful things that you can do include: change the default number of connection attempts, specify local environment variables to be passed to the remote server upon connection, and even the use of * and ? wildcards for matching hosts.
I hope that some of this is useful to a few of you. Leave a note in the comments if you have any cool tricks for the SSH config file; I'm always on the lookout for fun hacks.
-->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.
| Command shell | Command to use |
|---|---|
| Command | path |
| PowerShell | $env:path |
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.
Sftp Ssh Config
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)
Ssh Sftp Client
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