How to Install and Configure Telnet Client and SSH Server on Windows Server 2025

How to Install and Configure Telnet Client and SSH Server on Windows Server 2025

Remote command-line access to Windows Server 2025 is no longer limited to Remote Desktop Protocol or WinRM-based PowerShell remoting. Microsoft ships a fully-featured OpenSSH Server as an optional Windows capability, transforming Windows Server into a first-class SSH target that Linux, macOS, and other Windows administrators can connect to using standard SSH clients. Alongside this, the legacy Telnet client — while insecure for production use over untrusted networks — remains available as an optional feature and is still occasionally needed for quick port-reachability tests and troubleshooting legacy systems. This guide covers the complete installation and configuration of both components on Windows Server 2025: adding the Telnet client for diagnostic use, deploying OpenSSH Server, hardening the sshd_config file, configuring certificate-based authentication, setting the default shell, and verifying cross-platform SSH access from Linux clients.

Prerequisites

• Windows Server 2025 (Standard or Datacenter) with Desktop Experience or Server Core.
• Local Administrator privileges.
• Internet access to the Windows Update delivery network, or a WSUS/SCCM repository with the OpenSSH capability packages, for online capability installation.
• Windows Defender Firewall management rights to add inbound rules for TCP port 22.
• A Linux or macOS workstation (or Windows 10/11 with built-in OpenSSH client) for testing SSH connectivity.

Step 1: Install the Telnet Client Feature

The Telnet client is a Windows Optional Feature (not a Windows Capability) and can be installed via PowerShell using the DISM-based Enable-WindowsOptionalFeature cmdlet or through Server Manager. Note that Telnet sends all data — including usernames and passwords — in plaintext and must never be used for remote administration over untrusted networks. Its legitimate use in modern environments is limited to quickly checking whether a specific TCP port is reachable from the server.

# Install Telnet Client via PowerShell (DISM method)
Enable-WindowsOptionalFeature -Online -FeatureName TelnetClient -NoRestart

# Alternative: use Add-WindowsCapability (works on both Server and client SKUs)
# Note: Telnet Client on Server editions is an OptionalFeature, not a Capability
# Use the ServerManager module on Server 2025
Install-WindowsFeature -Name Telnet-Client

# Verify the installation
Get-WindowsFeature -Name Telnet-Client

Once installed, open a Command Prompt or PowerShell window and test TCP port reachability:

# Test if TCP port 443 is reachable on a target host
# Type Ctrl+] then 'quit' to exit the Telnet session
telnet www.example.com 443

# PowerShell alternative for port testing (does not require Telnet)
Test-NetConnection -ComputerName www.example.com -Port 443

# More detailed TCP port test
Test-NetConnection -ComputerName sql01.corp.local -Port 1433 -InformationLevel Detailed

Step 2: Install OpenSSH Server on Windows Server 2025

OpenSSH Server is delivered as a Windows Capability on Windows Server 2025, meaning it is available through Windows Update without downloading third-party software. There are two components: the client (which may already be present) and the server.

# Check which OpenSSH components are currently available and their state
Get-WindowsCapability -Online | Where-Object Name -like "*OpenSSH*"

# Install the OpenSSH Client (if not already installed)
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

# Install the OpenSSH Server
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

# Verify both capabilities are now installed
Get-WindowsCapability -Online | Where-Object Name -like "*OpenSSH*" |
    Select-Object Name, State

If the server has no internet access, download the capability package from another machine or use a DISM offline package source:

# Install from a local source (Windows Update offline package)
Add-WindowsCapability -Online `
    -Name OpenSSH.Server~~~~0.0.1.0 `
    -Source "D:SourcesSxS"

Step 3: Start and Configure the SSH Daemon Service

After installation, the SSH daemon (sshd) service exists but is not started or set to automatic startup by default. Configure it to start automatically and begin it immediately:

# Start the sshd service
Start-Service sshd

# Set sshd to start automatically at boot
Set-Service -Name sshd -StartupType Automatic

# Verify the service is running
Get-Service sshd | Select-Object Name, Status, StartType

# Also start and autostart the SSH Agent service (for key management)
Start-Service ssh-agent
Set-Service -Name ssh-agent -StartupType Automatic

On first start, the OpenSSH Server automatically generates its host keys in C:ProgramDatassh and creates a default sshd_config file in the same directory. The host keys are the server’s cryptographic identity — back up these files if you need SSH clients to recognise the server after a rebuild without triggering a host key mismatch warning.

Step 4: Configure the Windows Firewall for SSH Access

The OpenSSH Server installer automatically creates an inbound firewall rule named OpenSSH SSH Server (sshd) for TCP port 22. Verify this rule exists and is enabled:

# Verify the SSH firewall rule exists and is enabled
Get-NetFirewallRule -Name "*ssh*" | Select-Object Name, DisplayName, Enabled, Direction, Action

# If the rule is missing, create it manually
New-NetFirewallRule `
    -Name "OpenSSH-Server-In-TCP" `
    -DisplayName "OpenSSH SSH Server (sshd)" `
    -Enabled True `
    -Direction Inbound `
    -Protocol TCP `
    -Action Allow `
    -LocalPort 22

# Restrict SSH access to a specific source subnet (recommended for production)
New-NetFirewallRule `
    -Name "OpenSSH-Server-Admin-Subnet" `
    -DisplayName "OpenSSH SSH Server - Admin Network Only" `
    -Enabled True `
    -Direction Inbound `
    -Protocol TCP `
    -Action Allow `
    -LocalPort 22 `
    -RemoteAddress "10.10.0.0/24"

Step 5: Harden the sshd_config File

The SSH server configuration file is located at C:ProgramDatasshsshd_config. This file controls authentication methods, allowed users, port, and dozens of other security-relevant settings. Open it with a text editor running as Administrator, or edit it with PowerShell:

# View the current sshd_config
Get-Content "C:ProgramDatasshsshd_config"

# Common security hardening — set recommended values
$ConfigPath = "C:ProgramDatasshsshd_config"
$Config = Get-Content $ConfigPath

# Disable password authentication (require key-based auth only)
$Config = $Config -replace "^#?PasswordAuthentication.*", "PasswordAuthentication no"

# Disable empty passwords
$Config = $Config -replace "^#?PermitEmptyPasswords.*", "PermitEmptyPasswords no"

# Disable root/Administrator login (use a regular admin account with sudo-equivalent)
$Config = $Config -replace "^#?PermitRootLogin.*", "PermitRootLogin no"

# Set maximum authentication attempts
$Config = $Config -replace "^#?MaxAuthTries.*", "MaxAuthTries 3"

# Restrict to specific users or groups (use Windows group names)
# Add AllowUsers or AllowGroups lines
$Config += "`nAllowGroups Administrators `"Domain Admins`""

# Disable agent forwarding if not needed
$Config = $Config -replace "^#?AllowAgentForwarding.*", "AllowAgentForwarding no"

# Write the modified config back
$Config | Set-Content $ConfigPath -Encoding UTF8

# Restart sshd to apply changes
Restart-Service sshd

Key settings to review in sshd_config for a production server:

• Port 22 — consider changing to a non-standard port to reduce automated scanning noise (not a security control, only noise reduction).
• PasswordAuthentication no — enforce key-based authentication for all users.
• PubkeyAuthentication yes — ensure this is enabled (it is the default).
• AuthorizedKeysFile — specifies where public keys for users are stored.
• Subsystem sftp — controls the SFTP subsystem; comment out if SFTP is not required.

Step 6: Configure Key-Based Authentication (authorized_keys)

Password-based SSH authentication should be replaced with public key authentication in all production environments. Each user who needs SSH access requires their public key placed in an authorized_keys file.

For standard (non-administrator) users, the authorized_keys file is located at:

C:Users<username>.sshauthorized_keys

For members of the local Administrators or Domain Admins group, the default OpenSSH configuration on Windows uses a centralised administrators-specific file instead:

C:ProgramDatasshadministrators_authorized_keys

# Create the .ssh directory for a standard user if it doesn't exist
$User = "svcaccount"
$SSHDir = "C:Users$User.ssh"
New-Item -ItemType Directory -Path $SSHDir -Force

# Write a public key to authorized_keys (replace with the actual public key string)
$PublicKey = "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... user@linuxhost"
$AuthKeysPath = "$SSHDirauthorized_keys"
Add-Content -Path $AuthKeysPath -Value $PublicKey

# Set correct permissions — authorized_keys must not be world-readable
$Acl = Get-Acl $AuthKeysPath
$Acl.SetAccessRuleProtection($true, $false)
$Rule = New-Object System.Security.AccessControl.FileSystemAccessRule(
    $User, "FullControl", "Allow"
)
$Acl.AddAccessRule($Rule)
Set-Acl -Path $AuthKeysPath -AclObject $Acl

# For administrator accounts, add public keys to the centralised file
$AdminKeysPath = "C:ProgramDatasshadministrators_authorized_keys"
Add-Content -Path $AdminKeysPath -Value $PublicKey

# Set correct permissions on administrators_authorized_keys
icacls $AdminKeysPath /inheritance:r /grant "Administrators:F" /grant "SYSTEM:F"

Step 7: Change the Default Shell to PowerShell

By default, SSH sessions on Windows Server 2025 open cmd.exe. To change the default shell to PowerShell (recommended for administrative SSH access), set the DefaultShell registry value:

# Set PowerShell 5.1 as the default SSH shell
New-ItemProperty `
    -Path "HKLM:SOFTWAREOpenSSH" `
    -Name DefaultShell `
    -Value "C:WindowsSystem32WindowsPowerShellv1.0powershell.exe" `
    -PropertyType String `
    -Force

# Or use PowerShell 7 if installed
New-ItemProperty `
    -Path "HKLM:SOFTWAREOpenSSH" `
    -Name DefaultShell `
    -Value "C:Program FilesPowerShell7pwsh.exe" `
    -PropertyType String `
    -Force

# Verify
Get-ItemProperty -Path "HKLM:SOFTWAREOpenSSH" -Name DefaultShell

After changing the default shell, restart sshd and test a new SSH session to confirm PowerShell launches correctly.

Step 8: Connect via SSH from Linux to Windows Server 2025

Once the OpenSSH Server is configured and running, any standard SSH client can connect. From a Linux or macOS host:

# SSH commands run from a Linux/macOS client:

# Connect using password authentication (if still enabled)
# ssh [email protected]

# Connect using a private key
# ssh -i ~/.ssh/id_ed25519 [email protected]

# Connect using a domain account (use backslash-escaped domain name)
# ssh CORP\[email protected]

# Copy a file to the Windows server using SCP
# scp /local/path/file.tar.gz [email protected]:"C:/Temp/file.tar.gz"

# Use SFTP for interactive file transfer
# sftp [email protected]

Test SSH connectivity from another Windows machine using the built-in OpenSSH client:

# From a Windows 10/11 or Windows Server 2025 management workstation
ssh [email protected]

# SSH with a specific key file
ssh -i "$env:USERPROFILE.sshid_ed25519" [email protected]

# Run a single remote command without opening an interactive session
ssh [email protected] "Get-Service | Where-Object Status -eq Stopped"

# Create an SSH tunnel (port forward) — useful for accessing internal services
ssh -L 8080:internalapp:80 [email protected]

Conclusion

Windows Server 2025 with OpenSSH Server installed is a fully capable SSH target that fits naturally into cross-platform administration workflows. By enforcing key-based authentication, restricting the firewall rule to administrative subnets, hardening the sshd_config, and setting PowerShell as the default shell, you create an SSH endpoint that is both secure and productive for administrators accustomed to Linux-style remote access. The Telnet client, while limited to diagnostic use, fills a practical gap for quick port-reachability checks without needing third-party tools. Together, these two features round out the command-line remote access toolkit available on every Windows Server 2025 deployment out of the box.