The Secure Shell extension works with non-Google HTTP-to-SSH proxies via proxy hooks, and third-party application nassh-relay can use those hooks to enable the Secure Shell extension to establish an SSH connection over XMLHttpRequest or WebSocket transport. This is the start page for the SSH (Secure Shell) protocol, software, and related information. SSH is a software package that enables secure system administration and file transfers over insecure networks. It is used in nearly every data center and in every large enterprise. This page was created by the inventor of SSH, Tatu Ylonen (twitter: @tjssh). He wrote ssh-1.x and ssh-2.x, and still works on related topics. This SSH connection is set up with an option that enables TCP port forwarding from a port on the external server to an SSH port on a server in the internal network. Setting up this SSH back-tunnel requires a single one-line command on the inside, and it can easily be automated.
-->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.
Ssh Shell Account
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.
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
Secure Shell (SSH) allows you to remotely administer and configure your Windows IoT Core device
Using the Windows 10 OpenSSH client
Important
The Windows OpenSSH client requires that your SSH client host OS is Windows 10 version 1803(17134). Also, the Windows 10 IoT Core device must be running RS5 Windows Insider Preview release 17723 or greater.
The OpenSSH Client was added to Windows 10 in 1803 (build 17134) as an optional feature. To install the client, you can search for Manage Optional Features in Windows 10 settings. If the OpenSSH Client is not listed in the list of installed features, then choose Add a feature.
Next select OpenSSH Client in the list and click Install.
To login with a username and password use the following command:
Where host is either the IP address of the Windows IoT Core device or the device name.
The first time you connect you see a message like the following:
Type yes and press enter.
If you need to login as DefaultAccount rather than as administrator, you will need to generate a key and use the key to login. From the desktop that you intend to connect to your IoT Device from, open a PowerShell window and change to your personal data folder (e.g cd ~)
Register the key with ssh-agent (optional, for single sign-on experience). Note that ssh-add must be performed from a folder that is ACL'd to you as the signed-in user (BuiltinAdministrators and the NT_AUTHORITYSystem user are also ok). By default cd ~ from PowerShell should be sufficient as shown below.
Tip
If you receive a message that the ssh-agent service is disabled you can enable it with sc.exe config ssh-agent start=auto
To enable single sign, append the public key to the Windows IoT Core device authorized_keys file. Or if you only have one key you copy the public key file to the remote authorized_keys file.
Ssh Shell Mac
If the key is not registered with ssh-agent, it must be specified on the command line to login:
If the private key is registered with ssh-agent, then you only need to specify DefaultAccount@host:
The first time you connect you see a message like the following:
Type yes and press enter.
You should now be connected as DefaultAccount
To use single sign-on with the administrator account, append your public key to c:dataProgramDatasshadministrators_authorized_keys on the Windows IoT Core device.
You will also need to set the ACL for administrators_authorized_keys to match the ACL of ssh_host_dsa_key in the same directory.
To set the ACL using PowerShell
Note
If you see a REMOTE HOST IDENTIFICATION CHANGED message after making changes to the Windows 10 IoT Core device, then edit C:Users<username>.sshknown_hosts and remove the host that has changed.
See also: Win32-OpenSSH
Using PuTTY
Download an SSH client
In order to connect to your device using SSH, you'll first need to download an SSH client, such as PuTTY.
Connect to your device
In order to connect to your device, you need to first get the IP address of the device. After booting your Windows IoT Core device, an IP address will be shown on the screen attached to the device:
Now launch PuTTY and enter the IP address in the
Host Nametext box and make sure theSSHradio button is selected. Then clickOpen.If you're connecting to your device for the first time from your computer, you may see the following security alert. Just click
Yesto continue.If the connection was successful, you should see
login as:on the screen, prompting you to login.
EnterAdministratorand press enter. Then enter the default passwordp@ssw0rdas the password and press enter.If you were able to login successfully, you should see something like this:
Update account password
It is highly recommended that you update the default password for the Administrator account.
To do this, enter the following command in the PuTTY console, replacing [new password] with a strong password:
Configure your Windows IoT Core device
To be able to deploy applications from Visual Studio 2017, you will need to make sure the Visual Studio Remote Debugger is running on your Windows IoT Core device. The remote debugger should launch automatically at machine boot time. To double check, use the tlist command to list all the running processes from PowerShell. There should be two instances of msvsmon.exe running on the device.
It is possible for the Visual Studio Remote Debugger to time out after long periods of inactivity. If Visual Studio cannot connect to your Windows IoT Core device, try rebooting the device.
If you want, you can also rename your device. To change the 'computer name', use the
setcomputernameutility:
You will need to reboot the device for the change to take effect. You can use the shutdown command as follows:
Commonly used utilities
See the Command Line Utils page for a list of commands and utilities you can use with SSH.