-->
Ssh/ idrsa.pub email protected server. ECDSA key fingerprint is SHA256:sIxZeSuiivoEQ00RXAQHxylxuEA8SC5r/YPhL8wfp8s. For example, you might be using one SSH key pair for working on your company's internal projects, but you might be using a different key for accessing a client's servers. On top of that, you might be using a different key pair for accessing your own private server. Managing SSH keys can become cumbersome as soon as you need to use a second key.
This topic covers the Windows-specific configuration for OpenSSH Server (sshd).
- Public Key(idrsa) is kept at Destination Server(Remote Server), the Server you want to access. Step 3- Create a file name authorizedkeys in side.ssh directory and copy the content of idrsa.pub file to authorizedkeys file.
- SSH public-key authentication uses asymmetric cryptographic algorithms to generate two key files – one 'private' and the other 'public'. The private key files are the equivalent of a password, and should stay protected under all circumstances. If someone acquires your private key, they can log in as you to any SSH server you have access to.
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.
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.
Ssh Server Key Generation
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
5. End the session.
6. SSH to your instance.
Method 2: Automatically correct issues causing the error by running the AWSSupport-TroubleshootSSH document
AWSSupport-TroubleshootSSH automation document installs the Amazon EC2Rescue tool on the instance and then checks for and corrects some issues that cause remote connection errors when connecting to a Linux machine through SSH. For more information, see How can I use the AWSSupport-TroubleshootSSH Automation workflow to troubleshoot SSH connection issues?
Method 3: Use user data to fix permissions on the instance
Important!
- This recovery procedure requires you to stop and start your instance. Doing this means that data on instance store volumes is lost. For more information, see Determine the root device type of your instance.
- If your instance is part of an Amazon EC2 Auto Scaling group, then the instance might terminate when stopped. This might also occur on instances launched by services that use AWS Auto Scaling, such as Amazon EMR, AWS CloudFormation, AWS Elastic Beanstalk, and so on. Instance termination in this scenario depends on the instance scale-in protection settings for your Auto Scaling group. If your instance is part of an Auto Scaling group, temporarily remove the instance from the Auto Scaling group before starting the resolution steps.
- Stopping and restarting the instance changes the public IP address of your instance. It's a best practice to use an Elastic IP address instead of a public IP address when routing external traffic to your instance.
- You can't change the SSH key using user data if your instance's root device is an instance store volume. For more information, see Determine the root Device type of your instance.
- Updating your instance's user data applies to all distributions that support cloud-init directives. Cloud-init must be installed and configured for these instructions to be successful. For more information about the cloud-init SSH module, see SSH - Configure SSH and SSH keys.
1. Open the Amazon EC2 console, and then select your instance.
2. Choose Instance State, and then choose Stop instance.
Note: If Stop is disabled, either the instance is already stopped or its root device is an instance store volume.
Set Up Ssh Keys
Ssh Server Key Exchange
3. Choose Actions, choose Instance Settings, and then choose Edit User Data.
4. Copy the following script into the User Data field, and then select Save. Make sure to copy the entire script, and don't add extra spaces.
Ssh Server Key Fingerprint
Note: The following script uses the user name ec2-user. Change ec2-user to the user name for your AMI.