The SSH protocol uses encryption to secure the connection between a client and a server. All user authentication, commands, output, and file transfers are encrypted to protect against attacks in the network. For details of how the SSH protocol works, see the protocol page. To understand the SSH File Transfer Protocol, see the SFTP page.
- The Georgia SoftWorks SSH Server is based upon the robust and reliable Universal Terminal Server and provides secure remote access to your Windows host including Secure Remote Logon, Secure Data Exchange and Secure Access to your application on a Non-secure network! Free SSH Server Trial.
- An SSH server is a software program which uses the secure shell protocol to accept connections from remote computers. SFTP / SCP file transfers and remote terminal connections are popular use cases for an SSH server.
Applies to Windows Server 2019, Windows 10
OpenSSH is a connectivity tool for remote login that uses the SSH protocol. It encrypts all traffic between client and server to eliminate eavesdropping, connection hijacking, and other attacks.
OpenSSH can be used to connect Window 10 clients to Windows Server 2019. OpenSSH Client is available to install on Windows 10 build 1809 and later, while OpenSSH Server is available to install on Windows Server 2019 and later.
![Server Server](/uploads/1/1/4/0/114030877/183691568.jpg)
Important
If you downloaded OpenSSH from the GitHub repo at PowerShell/openssh-portable, follow the instructions listed there, not the ones in this article.
Install OpenSSH using Windows Settings
Secure Ssh Port
Both OpenSSH components can be installed using Windows Settings. OpenSSH Server is installed on Windows Server and OpenSSH Client is installed on Windows 10 devices.
To install the OpenSSH components:
- Open Settings, select Apps > Apps & Features, then select Optional Features.
- Scan the list to see if the OpenSSH is already installed. If not, at the top of the page, select Add a feature, then:
- On Windows 10, find OpenSSH Client, then click Install
- On Windows Server 2019, find OpenSSH Server, then click Install
Once setup completes, return to Apps > Apps & Features and Optional Features and you should see OpenSSH listed.
Note
Installing OpenSSH Server will create and enable a firewall rule named
OpenSSH-Server-In-TCP
. This allows inbound SSH traffic on port 22. If this rule is not enabled and this port is not open, connections will be refused or reset.Install OpenSSH using PowerShell
To install OpenSSH using PowerShell, run PowerShell as an Administrator.To make sure that OpenSSH is available, run the following cmdlet:
This should return the following output:
Then, install the server or client components as needed:
Both of these should return the following output:
Start and configure SSH Server
To start and configure OpenSSH server for initial use, open PowerShell as an administrator, then run the following commands to start the
SSHD service
:Connect to SSH Server
Once installed, you can connect to OpenSSH Server from a Windows 10 device with the SSH client installed using PowerShell as follows. Be sure to run PowerShell as an administrator:
Once connected, you get a message similar to the following:
Selecting yes adds that server to the list of known ssh hosts on your Windows client.
You are prompted for the password at this point. As a security precaution, your password will not be displayed as you type.
Once connected, you will see the Windows command shell prompt:
Uninstall OpenSSH using Windows Settings
To uninstall OpenSSH using Windows Settings:
- Open Settings, then go to Apps > Apps & Features.
- Go to Optional Features.
- In the list, select OpenSSH Client or OpenSSH Server.
- Select Uninstall.
Uninstall OpenSSH using PowerShell
To uninstall the OpenSSH components using PowerShell, use the following commands:
You may need to restart Windows afterwards if the service was in use at the time it was uninstalled.
The Secure Shell is a critical tool in the administrator's arsenal. Here are eight ways you can better secure SSH, and some suggestions for basic SSH centralization.
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?![Server Server](/uploads/1/1/4/0/114030877/574504632.jpeg)
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.
Secure Ssh Server
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:
Secure Ssh Server Debian
Edit these values to something that makes sense for your environment.
Secure Ssh Client
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.
Free Ssh Server
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.
Ssh Secure Shell
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.