Choosing the right shell for PowerShell (pwsh) on Linux isn’t just about preference; it’s about stability and predictability. This guide breaks down the common pitfalls and provides three battle-tested solutions for integrating pwsh into your Linux workflow without causing late-night production fires.

SSH, PowerShell, and the Linux Shell: A DevOps Love-Hate Triangle

I still remember the 3 AM page. A critical deployment pipeline for our `prod-reporting-cluster` was failing with the most cryptic error imaginable. The script, which worked flawlessly on a dozen other servers, was falling over on this one. After an hour of frantic debugging, we found the culprit. A well-meaning junior engineer, trying to be efficient, had logged into the server, typed pwsh to get into a PowerShell session, and then ran the master deployment script. The problem? Our script had a tiny, but critical, dependency on a Bash environment variable set in /etc/profile. Inside his nested `pwsh` session, that variable didn’t exist. The whole system ground to a halt because of a shell-within-a-shell problem. We’ve all been there, and it’s why understanding this interaction is so critical.

What’s Actually Happening Here? The Shell vs. The Application

Before we jump into fixes, let’s get one thing straight. When you SSH into a Linux box, you are greeted by your login shell. For 99% of servers, this is Bash, Zsh, or maybe Dash. This shell is responsible for setting up your environment, reading profile scripts (like .bashrc or .zshrc), and giving you a command prompt.

PowerShell (pwsh) on Linux is not a login shell by default; it’s an application you run from within your login shell. Think of it like running python or node. When you type pwsh, you are starting a new process inside your existing Bash session. This new process has its own profile, its own variables, and its own way of thinking. The disconnect between the “outer” shell (Bash) and the “inner” application (pwsh) is where the chaos begins.

So, how do we make them play nice? Here are the three main approaches I’ve seen in the wild.

Option 1: The Quick Fix – The SSH One-Liner

Let’s say you just want to SSH into a box and land directly in a PowerShell prompt to run a quick command. You don’t want to log in, type `pwsh`, and then run your command. You can force SSH to execute `pwsh` immediately upon connection.

The trick is to pass the command directly to the `ssh` client. The -t flag is crucial here, as it forces the allocation of a pseudo-terminal, which makes the remote `pwsh` session interactive and feel like a native shell.

How to do it:

# SSH directly into a pwsh session on a remote server
ssh -t darian@prod-db-01 'pwsh'

This is great for one-off tasks or for aliasing. You could add alias ssh-pwsh="ssh -t darian@prod-db-01 'pwsh'" to your local .bashrc for convenience. It’s a solid, “in the trenches” solution for quick jobs. But it’s not a permanent change to the server’s environment.

Option 2: The Professional’s Choice – Keep ’em Separated

This is, by far, the most common and stable configuration you’ll find in any serious production environment. You leave the default login shell as Bash (or Zsh) and simply launch PowerShell when you need it. This is the “no surprises” approach.

Your login shell (Bash) handles:

• SSH authentication and session setup.
• System-wide environment variables from /etc/profile.
• User-specific environment from ~/.bashrc and ~/.bash_profile.

Your PowerShell session handles:

• PowerShell-specific logic.
• Its own profile scripts (you can edit it by typing code $PROFILE inside pwsh).
• Executing your .ps1 scripts.

This method respects the boundary between the operating system’s shell and the PowerShell runtime. You log in, you get a predictable Bash prompt, and you elevate into `pwsh` when your task requires it. No 3 AM surprises. It’s boring, and in infrastructure, boring is beautiful.

Option 3: The ‘Nuclear’ Option – Changing Your Default Shell

This directly answers the question: “Can I set `pwsh` as my default login shell?”. The answer is yes, you can, using the chsh (change shell) command. But just because you can, doesn’t mean you should.

By changing your user’s default shell in /etc/passwd to point to the `pwsh` binary, every time you log in, you will be dropped directly into a PowerShell prompt. Sounds great, right?

A Word of Warning: I strongly advise against doing this on any production server or shared machine. Many system-level scripts, tools, and even basic things like SFTP subsystems expect a POSIX-compliant shell (like Bash) to be available as the login shell. Changing it to `pwsh` can lead to bizarre, hard-to-diagnose issues with user profiles, terminal rendering, and automated tooling.

If you’re determined to try this on your own personal dev VM or a dedicated workstation, here’s how.

How to do it (at your own risk):

First, find the path to your pwsh installation:

which pwsh
# Output might be: /usr/bin/pwsh

Next, add this path to the list of approved shells in /etc/shells:

# You'll need sudo for this
echo "/usr/bin/pwsh" | sudo tee -a /etc/shells

Finally, change your user’s shell:

chsh -s /usr/bin/pwsh

You’ll need to log out and log back in for the change to take effect. Be prepared for things to feel a little… off. If you get locked out, you may need an admin (or a root console) to change it back for you.

Comparison at a Glance

Approach	Use Case	Pros	Cons
1. SSH One-Liner	Quick, remote one-off commands.	Fast, simple, no server changes needed.	Not permanent, can be clunky for complex tasks.
2. Keep ’em Separated	Recommended for all production use.	Stable, predictable, industry standard.	Requires one extra step (typing `pwsh`).
3. Change Default (chsh)	Personal dev machines, experimentation.	Seamlessly drops you into PowerShell.	High risk of breaking things. Not recommended.

My Final Take

Look, I get the appeal of living 100% in PowerShell. I love it. But on a Linux system, Bash is the native language. Trying to force pwsh into the role of a login shell is like insisting on speaking Spanish in Tokyo. You might get by, but you’re going to cause confusion and run into trouble.

Stick with Option 2. Keep Bash as your login shell, and treat PowerShell as the powerful, specialized tool it is. Your systems (and your on-call sanity) will thank you for it.

---

🤖 Frequently Asked Questions