Powershell: Immediate disconnect when sshing to host with /snap/bin/pwsh set as default shell

[jonstelly]

I'm not sure if this is a snap-specific issue, but if so, I see discussion here about only providing powershell core for non-lts systems as a snap: https://github.com/PowerShell/PowerShell/issues/7310

Steps to reproduce

• Configure /snap/bin/pwsh as default shell for active directory users in /etc/sssd/sssd.conf.
  
  
  
  • default_shell = /snap/bin/pwsh
  
  
• Attempt to ssh from one machine to another

ssh -v target

Expected behavior

To get a powershell prompt on the remote machine

Actual behavior

ssh session spits out some snap information and immediately disconnects

Troubleshooting steps / workarounds

I tried just specifying -t, ssh -t laptop but that has the same behavior.

If I specify 'pwsh' as a command for ssh like ssh -t laptop pwsh then I do get a powershell prompt (ssh -t laptop /snap/bin/pwsh also works). But it would be really nice not to have to specify pwsh.

/home/jon> ssh -t laptop pwsh
PowerShell 6.2.1
Copyright (c) Microsoft Corporation. All rights reserved.

https://aka.ms/pscore6-docs
Type 'help' to get help.

/home/jon> hostname
laptop

Environment data

Ubuntu 19.04, Active Directory authentication enabled per this doc
Powershell installed via this Powershell Snap

$PSVersionTable

Name                           Value
----                           -----
PSVersion                      6.2.1
PSEdition                      Core
GitCommitId                    6.2.1
OS                             Linux 5.0.0-16-generic #17-Ubuntu SMP Wed May 15 10:52:21 UTC 2019
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

SSH Verbose Logging

/home/jon> ssh -v laptop
OpenSSH_7.9p1 Ubuntu-10, OpenSSL 1.1.1b  26 Feb 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to laptop [2600:.....] port 22.
debug1: connect to address 2600:..... port 22: No route to host
debug1: Connecting to laptop [192......] port 22.
debug1: Connection established.
debug1: identity file /home/jon/.ssh/id_rsa type 0
debug1: identity file /home/jon/.ssh/id_rsa-cert type -1
debug1: identity file /home/jon/.ssh/id_dsa type -1
debug1: identity file /home/jon/.ssh/id_dsa-cert type -1
debug1: identity file /home/jon/.ssh/id_ecdsa type -1
debug1: identity file /home/jon/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/jon/.ssh/id_ed25519 type -1
debug1: identity file /home/jon/.ssh/id_ed25519-cert type -1
debug1: identity file /home/jon/.ssh/id_xmss type -1
debug1: identity file /home/jon/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9p1 Ubuntu-10
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9p1 Ubuntu-10
debug1: match: OpenSSH_7.9p1 Ubuntu-10 pat OpenSSH* compat 0x04000000
debug1: Authenticating to laptop:22 as 'jon'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:.....
debug1: Host 'laptop' is known and matches the ECDSA host key.
debug1: Found key in /home/jon/.ssh/known_hosts:7
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: Will attempt key: /home/jon/.ssh/id_rsa RSA SHA256:..... agent
debug1: Will attempt key: /home/jon/.ssh/id_dsa 
debug1: Will attempt key: /home/jon/.ssh/id_ecdsa 
debug1: Will attempt key: /home/jon/.ssh/id_ed25519 
debug1: Will attempt key: /home/jon/.ssh/id_xmss 
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/jon/.ssh/id_rsa RSA SHA256:..... agent
debug1: Server accepts key: /home/jon/.ssh/id_rsa RSA SHA256:..... agent
debug1: Authentication succeeded (publickey).
Authenticated to laptop ([192......]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug1: Remote: /home/jon/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /home/jon/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
Welcome to Ubuntu 19.04 (GNU/Linux 5.0.0-16-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

 * Ubuntu's Kubernetes 1.14 distributions can bypass Docker and use containerd
   directly, see https://bit.ly/ubuntu-containerd or try it now with

     snap install microk8s --classic

0 updates can be installed immediately.
0 of these updates are security updates.

Last login: Thu Jun  6 10:05:45 2019 from 192.168.10.102
The snap command lets you install, configure, refresh and remove snaps.
Snaps are packages that work across many different Linux distributions,
enabling secure delivery and operation of the latest apps and utilities.

Usage: snap <command> [<options>...]

Commands can be classified as follows:

         Basics: find, info, install, list, remove
        ...more: refresh, revert, switch, disable, enable
        History: changes, tasks, abort, watch
        Daemons: services, start, stop, restart, logs
       Commands: alias, aliases, unalias, prefer
  Configuration: get, set, wait
        Account: login, logout, whoami
    Permissions: connections, interface, connect, disconnect
      Snapshots: saved, save, check-snapshot, restore, forget
          Other: version, warnings, okay, ack, known
    Development: run, pack, try, download, prepare-image

For more information about a command, run 'snap help <command>'.
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0
For a short summary of all commands, run 'snap help --all'.
debug1: channel 0: free: client-session, nchannels 1
Connection to laptop closed.
Transferred: sent 3060, received 4584 bytes, in 0.2 seconds
Bytes per second: sent 14002.7, received 20976.6
debug1: Exit status 0
/home/jon>

[jonstelly]

The easiest workaround was to set bash as my default shell then launch powershell from ~/.bashrc:

/snap/bin/pwsh -i

But it would still be nice if I could skip bash and use pwsh as my default shell. Now I've got to exit out of two levels of shells and it's just a bit clunky.

To add to the initial report, SSHing with pwsh as the default shell fails, so does trying to log in from one of the other consoles (ctrl+alt+f1 etc...) when pwsh is the default shell, but launching one of the gui terminal apps works fine.

I don't know a lot of the internals of Linux but I know that ssh and logging in at a console result in a login shell but the gui terminal wouldn't be a login shell. Is it possible that one of the files that gets run during a login like /etc/profile or ~/.profile is causing an error and causing pwsh to crash/exit?

[thlac]

I also ran into this today, so I investigated it a bit, and figured that maybe it was a parsing error that it printed the snap output, but as it turn out /snap/bin/pwsh is symlinked to /snap/bin/powershell which is symlinked to /usr/bin/snap.

So my conclusion is that it is somehow related to how symlinks are processed either by the process calling /snap/bin/powershell or snap itself. But I don't know enough about Linux or snap to comment on that.

Knowing the above it was fairly easy to work around it myself by finding the proper path to the executable, which happens to be /snap/powershell/current/opt/powershell/pwsh . I am not sure if that's really a stable option to run it with all of snap's redirection trickery, but it worked when I tested it out just now.

[jonstelly]

Good find and that makes sense. I've changed my setup once more to run tmux which then launches powershell. It feels a bit 'wrong' having my default shell as /bin/bash which fires up tmux (if it's not already running) which fires up powershell, but it works reliably, even across SSHing to another host (with the same config).

If I get some time I may look at using your solution, but one of the drawbacks of having pwsh as the default shell is that the ~/.bashrc stuff doesn't get run, so things like the grep --color=auto alias wouldn't get set up.

Here's my new config in case anyone wants a similar setup with tmux and pwsh:

~/.bashrc (at the end)

if command -v tmux &> /dev/null && [ -n "$PS1" ] && [[ ! "$TERM" =~ screen ]] && [[ ! "$TERM" =~ tmux ]] && [ -z "$TMUX" ]; then
  exec tmux
else
  pwsh -i
  exit
fi

~/.tmux.conf

set-option -g default-command /snap/bin/pwsh

[SteveL-MSFT]

Seems like it might be snap specific, would be good to know if PS7 (non-Snap) has the same issue. cc @TravisEz13