SSH does not seem to use .profile on DSM

joggienl commented 7 months ago

Discord username (optional)

joggienl

Operating System

MacOS

Operating System and Version

14.2

Local Shell Version

ZSH: 5.9

Remote Shell Version

Bash: 4.4.23(1)-release

Warp Version

v0.2023.12.12.08.02.stable_04

I have tried commenting out my system & user rcfiles and warp still will not bootstrap

[X] Yes

Screenshots

I have a ~/.profile on my Synology NAS, running DSM version DSM 7.2.1-69057 Update 3. Using a .profile file is the way to change the user shell when login via ssh and not using the default /bin/sh.

This is the content of ~/.profile

# synology - uses /bin/sh, should reload to /bin/bash
if [  "$SHELL" == "/bin/sh" -a -x /bin/bash ]; then
    export SHELL=/bin/bash
    exec /bin/bash --login
fi

Login via iTerm or regular Terminal.app works as expected, login via Warp ends up with /bin/sh.

You can opt out of this functionality by invoking /usr/bin/ssh directly. Using the method to not use the ssh wrapper from this page works: https://docs.warp.dev/features/ssh#implementation

A screenshot:

Include shell xtrace output

There is no output.

Does this block you from using Warp daily?

No

Is this a Warp specific issue? (i.e. does it happen in Terminal, iTerm, Kitty, etc.)

Yes, this I confirmed this only happens in Warp, not other terminals.

Warp Internal (ignore) - linear-label:e7dfaa84-5fdb-4a00-b754-d8912da923fa

None

Warp Internal (ignore): linear-label:b8107fdf-ba31-488d-b103-d271c89cac3e

None

dannyneira commented 7 months ago

Hi @joggienl Thanks for submitting. Warp may not always respect the sh configuration set in user ~/.profile since Warp doesn't support shells besides bash/zsh/fish, I recommend you try to set /bin/bash as the default shell in your nas instead with chsh -s /bin/bash. This may allow Warp to bootstrap properly on a supported shell in an SSH session.

Please try the above and let me know if this helps with your issue.

To anyone else facing this issue, please add a 👍 to the original post at the top or comment with your details, and subscribe if you'd like to be notified.

joggienl commented 7 months ago

Hi @dannyneira, thanks for your reply!

Apologies that my comment on how to set the default shell on Synology might be confusing a bit. Even though it is running Linux, tools like chsh are not available. That is why using ~/.profile is the recommended way to change user shell. And yes, that is not exactly changing the shell.

Another option on any "normal" system would be to directly update the /etc/passwd file but that does not work as well. It straight up locks you out of the system if you do that. Funny side detail: any user update will restore the /etc/passwd file.

I don't think it is a problem or even bug if Warp is not able to "warpify" but I suppose it should not stop the default behaviour either? I would assume it would let the remote server do it's login thing if it was not able to do so.

Currently, as a user, I am left in the dark what happened because there is no indication something did not work. It took me some time before I noticed that in another terminal (not Warp) I did got bash. So some ideas came to mind. Not sure if they would or could fit but I would like to share them anyway:

Perhaps it could be helpful to pass some option to ssh to disable the default warp behaviour (a more friendly way than typing the complete path to /usr/bin/ssh)
Perhaps a way to block just a hostname for applying the wrapper
Perhaps there could be a message in the terminal that the wrapper was not loaded (i.e. incompatible shell)

Hope this helps clearing up the issue 😅

dannyneira commented 7 months ago

Thanks for clearing that up. We've had another report about similar issues connecting to Synology NASes and applying a supported shell using the method you described. As a possible workaround, you can also try disabling the SSH wrapper by navigating to Settings > Features. Blocks(and other Warp features) will stop working but with it disabling, SSH to the NAS device should work as normal.

I'll bring this up with the team and we'll post any further updates on this thread.

joggienl commented 7 months ago

Thank you @dannyneira! I see the other issue now, It is about the same thing indeed.

Disabling the SSH wrapper works fine although I personally (in this particular case) prefer to just type /usr/bin/ssh instead of ssh which essentially does the same thing but just for that connection. For all my other servers the wrapper works fine, so I did not want to loose functionality. For now I ended up making an alias to save me some typing.

I'll keep an eye on this issue, so also thanks for any future updates!

yvbeek commented 5 months ago

On Synology devices the easiest way to override the shell is to add the export SHELL=... and exec $SHELL commands to your ~/.profile file. You can see @joggienl 's example of that in the description of this issue.

Unfortunately the warp_ssh_helper seems to break this, because it is preventing the ~/.profile file from being executed after you set up the SSH connection.

If I look at this block specifically:

if test "'"${SHELL##*/}" != "bash" -a "${SHELL##*/}" != "zsh"'"; then
 if test ! -e "'$HOME/.hushlogin'"; then
 if test -r /etc/motd; then
 command -p cat /etc/motd
 elif test -r /run/motd; then
 command -p cat /run/motd
 elif test -r /run/motd.dynamic; then
 command -p cat /run/motd.dynamic
 elif test -r /usr/lib/motd; then
 command -p cat /usr/lib/motd
 elif test -r /usr/lib/motd.dynamic; then
 command -p cat /usr/lib/motd.dynamic
 fi
 fi
 if test -r /etc/profile; then
 . /etc/profile
 fi
 exec "'$SHELL'"
fi

You can see that the wrapper runs /etc/profile, but it doesn't run ~/.profile.

Perhaps a fix could be to update the wrapper so that it also executes the ~/.profile if available? Not sure if the Warp integration works 100% correctly in that scenario.

warpdotdev / Warp