Powershell as default shell

Z

zkab

Extraordinary Member
Joined
Jan 18, 2017
Messages
9
I have a Linux Fedora42 workstation and I login from Linux into a Windows11 Pro computer on the same network ... it work OK.
But I want to be logged into Powershell instead of cmd on the Windows computer.
What I did was to add following line:
Subsystem powershell C:/PROGR~1/POWERS~1/7/pwsh.exe -sshs
at the end of C:\ProgramData\ssh\sshd_config and restarted OpenSSH server.
Still I will get cmd when I login.
Appreciate help since my Windows knowledge is limited ...
 
Solution
Good news: your sshd_config is fine, but the ssh command you ran is just using the wrong argument order.
What went wrong
  • ssh -s powershell raivo@beelink tells ssh that the host is “powershell”, so it tries to resolve that name. Hence “Could not resolve hostname powershell”.
  • With OpenSSH, the syntax for invoking a subsystem is:
    ssh -s [user@]host subsystem
What to do
1) Run the command with the correct order:
  • With explicit user:
    ssh -s raivo@beelink powershell
  • Or using -l:
    ssh -s -l raivo beelink powershell
2) Move your Subsystem line above the Match block
In sshd_config, directives after a Match clause are scoped to that match. Keep Subsystem lines before any Match. For example:
Code: 
# override default of no...
Sort by date Sort by votes
You’re on the right track by editing the sshd_config file, but connecting directly to PowerShell as your default shell via OpenSSH in Windows requires a couple of careful steps and some gotchas specific to Windows’ handling of shells and users.
Here’s how you can ensure that ssh logins from your Fedora workstation use PowerShell as the default shell instead of cmd.exe:

1. Ensure PowerShell Subsystem is Correct​

Your line is nearly perfect, but let’s confirm the path and syntax. On a default Windows install, the 64-bit PowerShell 7.x usually resides in:
C:\Program Files\PowerShell\7\pwsh.exe
So your sshd_config should have:
Subsystem powershell C:/Program Files/PowerShell/7/pwsh.exe -sshs
or, using short names (which should also work, as you had):
Subsystem powershell C:/PROGR~1/POWERS~1/7/pwsh.exe -sshs
Make sure there are no typos or extra spaces.

2. Specify the Subsystem When Connecting​

By default, ssh will launch the Windows shell defined in your profile (cmd.exe unless changed). To explicitly get PowerShell, from your Linux machine, you should connect like this:
ssh -s powershell username@windows_hostname_or_ip
The -s powershell part tells ssh to use the “powershell” subsystem, which you defined above.

3. Setting PowerShell as the Default Shell (Optional)​

If you want every user who connects to always get PowerShell (without specifying a subsystem), you can change the user’s default shell in the Windows registry, but this is generally NOT recommended unless you know exactly what you’re changing, because it can impact regular console/logon sessions.
Instead, create a file at:
C:\Users\<yourusername>\.ssh\rc
Put this line in it:
pwsh.exe -sshs
This will run PowerShell on login for your user.
Or, use a Group Policy/local security policy to set the default shell. For advanced (multi-user) systems, see documentation on forced command or setting the shell per-user in the sshd_config.

4. Check sshd Logs​

If you’re still getting cmd, check the Windows Event Viewer for sshd logs, or look at the logs in:
C:\ProgramData\ssh\logs
This might reveal a permission issue or a misconfiguration.

Recap Example:​

  1. Add to C:\ProgramData\ssh\sshd_config:
    Subsystem powershell C:/Program Files/PowerShell/7/pwsh.exe -sshs
  2. Restart the OpenSSH server (services.msc → OpenSSH SSH Server → Restart).
  3. From Linux, connect with:
    ssh -s powershell youruser@yourwindowsip
If you do these steps and still get cmd.exe, please let me know any error messages or logs (or describe exactly what you see after connecting), and we’ll dig deeper!
Let me know how it goes or if you need more step-by-step help.
 
Upvote 0 Downvote
My C:\ProgramData\ssh\sshd_config look like this:

Code: 
# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey __PROGRAMDATA__/ssh/ssh_host_rsa_key
#HostKey __PROGRAMDATA__/ssh/ssh_host_dsa_key
#HostKey __PROGRAMDATA__/ssh/ssh_host_ecdsa_key
#HostKey __PROGRAMDATA__/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile    .ssh/authorized_keys

#AuthorizedPrincipalsFile none

# For this to work you will also need host keys in %programData%/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# GSSAPI options
#GSSAPIAuthentication no

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#PermitUserEnvironment no
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# override default of no subsystems
Subsystem    sftp    sftp-server.exe

# Example of overriding settings on a per-user basis
#Match User anoncvs
#    AllowTcpForwarding no
#    PermitTTY no
#    ForceCommand cvs server

Match Group administrators
       AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

Subsystem powershell C:\Program Files\PowerShell\7\pwsh.exe -sshs

but when I issue following command '>ssh -s powershell raivo@beelink' from Linux I get:

Code: 
ssh: Could not resolve hostname powershell: Name or service not known
 
Upvote 0 Downvote
Good news: your sshd_config is fine, but the ssh command you ran is just using the wrong argument order.
What went wrong
  • ssh -s powershell raivo@beelink tells ssh that the host is “powershell”, so it tries to resolve that name. Hence “Could not resolve hostname powershell”.
  • With OpenSSH, the syntax for invoking a subsystem is:
    ssh -s [user@]host subsystem
What to do
1) Run the command with the correct order:
  • With explicit user:
    ssh -s raivo@beelink powershell
  • Or using -l:
    ssh -s -l raivo beelink powershell
2) Move your Subsystem line above the Match block
In sshd_config, directives after a Match clause are scoped to that match. Keep Subsystem lines before any Match. For example:
Code: 
# override default of no subsystems
Subsystem sftp sftp-server.exe
Subsystem powershell C:/Program Files/PowerShell/7/pwsh.exe -sshs

Match Group administrators
    AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys
3) Restart the service after any change:
  • From an elevated PowerShell on Windows:
    Restart-Service sshd
4) Optional: make PowerShell the default shell for all SSH logins
If you don’t want to pass -s powershell each time, set the global default shell (affects SSH sessions only):
  • Elevated PowerShell:
    New-ItemProperty -Path 'HKLM:\SOFTWARE\OpenSSH' -Name DefaultShell -Value 'C:\Program Files\PowerShell\7\pwsh.exe' -PropertyType String -Force
    Restart-Service sshd
    Then simply:
    ssh raivo@beelink
    and you’ll land in pwsh.
5) Quick sanity checks if it still doesn’t work
  • Validate config syntax:
    "C:\Windows\System32\OpenSSH\sshd.exe" -t
  • Check logs: Event Viewer → Applications and Services Logs → OpenSSH/Operational.
Tip: As a one-off test (without subsystem), you can also try:
ssh -tt raivo@beelink "C:\Program Files\PowerShell\7\pwsh.exe" -NoLogo
If that drops you into an interactive pwsh session, your connectivity is fine and the subsystem/default-shell piece is all that remains.
Give the corrected ssh command a try first; that should immediately fix the “hostname powershell” error.
 
Upvote 0 Downvote
Solution
I used '4) Optional: make PowerShell the default shell for all SSH logins'
Thanks ... now it works the way I wanted.
Just an additional question ... how can I get the PowerShell run as Admin?
 
Upvote 0 Downvote
Great to hear you’ve got PowerShell as the default over SSH.
Short answer about “Run as Administrator”: you can’t self‑elevate an interactive SSH session when UAC is enabled, because there’s no desktop to show the UAC consent prompt. Start-Process -Verb RunAs (or runas.exe) will not elevate over SSH.
You have three practical options:
Option 1 (recommended when you truly need an elevated shell): log in as the built‑in Administrator account
  • Why: The built‑in Administrator (RID 500) isn’t subject to Admin Approval Mode by default, so it gets a full, elevated token at logon.
  • Steps on the Windows box:
    1) Enable the account and set a strong password (or keep it disabled for password; prefer keys):
    net user Administrator /active:yes
    2) Put your public key in this file (your sshd_config already has the Match Group administrators line):
    C:\ProgramData\ssh\administrators_authorized_keys
    Then lock down permissions:
    icacls "C:\ProgramData\ssh\administrators_authorized_keys" /inheritance:r /grant "Administrators:F" /grant "SYSTEM:F"
    3) Restart SSHD:
    Restart-Service sshd
    4) From Fedora, connect:
    ssh -s powershell Administrator@beelink
  • Important:
    • Use key-based auth only for this account.
    • Consider firewalling SSH to your LAN, and/or AllowUsers in sshd_config.
    • When you’re done, you can disable the Administrator account again:
      net user Administrator /active:no
Option 2 (not recommended for general security): disable Admin Approval Mode (or UAC) for all admins
  • This gives every local admin a full token on logon (including SSH), but it lowers security.
  • Local Security Policy → Security Options:
    • User Account Control: Run all administrators in Admin Approval Mode → Disabled
    • Reboot required.
  • Only consider this on isolated test machines.
Option 3 (safer for “do admin things” without an interactive elevated shell): use PowerShell Remoting with a RunAs endpoint
  • Create a WinRM session configuration that runs as a specific admin account (RunAsCredential). Your shell stays non‑elevated, but commands in that session run with elevated rights.
  • High‑level steps on Windows:
    • Enable-PSRemoting -Force
    • Register a session configuration that runs as an admin:
      Register-PSSessionConfiguration -Name ElevatedCore -RunAsCredential (Get-Credential) -PowerShellExecutable "C:\Program Files\PowerShell\7\pwsh.exe" -Force
    • Use HTTPS and proper firewall rules.
  • From Fedora (with PowerShell 7 installed), connect:
    • pwsh
    • Enter-PSSession -ComputerName beelink -UseSSL -Credential youradmin -ConfigurationName ElevatedCore
  • This avoids exposing the built‑in Administrator for SSH and lets you audit/limit what runs.
Quick FAQ
  • Can I “sudo” inside the SSH pwsh? Not on Windows in the same way. You either log on already elevated (built‑in Administrator or disabled Admin Approval Mode), or you execute via a channel that runs as elevated (WinRM endpoint, scheduled task, etc.).
  • Why doesn’t runas.exe help? It doesn’t bypass UAC; elevation still needs consent UI, which isn’t available over SSH.
If you want, tell me which route you prefer (built‑in Administrator over SSH vs a WinRM RunAs endpoint), and I’ll give you step‑by‑step commands tailored to your setup.
 
Upvote 0 Downvote
You must log in or register to reply here.

Similar threads

  • Featured
  • Article Article
Mastering Windows Command-Line Tools: CMD, PowerShell, and Windows Terminal Explained
Replies
0
Views
131
ChatGPT
Cookies are required to use this site. You must accept them to continue using the site. Learn more…