Mosh doesn't read the right shell profiles (I think)

[Peeja]

I've never understood for sure which files (.bashrc, .bash_profile, etc.) get which bits of shell config. I know what causes each to be sourced (interactive shell, login shell, etc), I'm just not sure I understand what settings ought to be run when. So I may have mine set up wrong.

I have my PATH set up in my .bash_profile. My theory is that this is correct because it's exported from here for subshells, and every shell should inherit its environment from a login shell.

However, when I run mosh me@mybox, I find that only the .bashrc runs, so there's no PATH set, and it can't find mosh-server.

Am I missing something?

[keithw]

Hello Peeja,

ssh doesn't remotely execute commands under an interactive shell, so to the best of my knowledge neither .bashrc nor .bash_profile is getting read.

The easiest solution here is to use a --server= option to give the full path to the mosh-server on the remote machine. You can make a shell alias to save typing.

[Peeja]

The .bashrc does appear to be read; it'll echo to the screen if tell it to. I believe the reason is that it's spinning up a bash to parse the sh -c ... command given to ssh.

It seems a little weird that I should have to know the full path to the mosh-server on a remote machine, doesn't it? I don't need to know where ssh is installed.

[kmcallister]

It seems a little weird that I should have to know the full path to the mosh-server on a remote machine, doesn't it? I don't need to know where ssh is installed.

That's because the SSH daemon is already running (as root) and listening on a well-known port. By contrast the mosh wrapper script needs to start a mosh-server process for you on the remote machine. This mosh-server runs as your user and lives only as long as your Mosh session.

This is an important architectural decision. It delegates a lot of the security-critical complexity (authentication and public-key crypto) to the existing trusted SSH infrastructure. It also makes Mosh usable without admin privileges on either end.

Actually, sometimes SSH isn't running on that well-known port 22. In that case you do need to tell ssh where to find sshd (by port), which is sort of like telling mosh where to find mosh-server (by path).

[Peeja]

Right, I understand what's going on technically, it just seems like an odd design choice—not bootstrapping over SSH, but requiring the the client to know the disk location of the mosh-server. It's not quite like running on a well-known port. In UNIX, the user on the system generally doesn't care what directory a command lives in, let alone someone connecting from a foreign system. That's what the PATH is for. The system administrator can run servers on well-known ports or other ports of choice pretty easily. It's asking more to get my mosh-server in the right "well-known path".

Here's my exact case. I'm connecting between two OS X machines, jerome and timmy. Both have Mosh installed through Homebrew. Thus, on the foreign machine, timmy.local, mosh-server is installed at /usr/local/bin/mosh. In a login shell, that's in the path. Through mosh's SSH invocation, though:

Jerome:~$ mosh timmy.local --server='echo $PATH'
Password:
/usr/bin:/bin:/usr/sbin:/sbin 10.0.1.7
Connection to timmy.local closed.
/usr/local/bin/mosh: Did not find mosh server startup message.

So if I install with Homebrew, I either have to manually symlink into, say, /usr/bin (which I'll need root/admin privileges for), or invoke mosh with --server=/usr/local/bin/mosh-server. Neither of those seems very appealing.

[kmcallister]

So if I install with Homebrew, I either have to manually symlink into, say, /usr/bin (which I'll need root/admin privileges for), or invoke mosh with --server=/usr/local/bin/mosh-server. Neither of those seems very appealing.

Or you can set PATH in your .bashrc, as you noted in your original post.

I have my PATH set up in my .bash_profile. My theory is that this is correct because it's exported from here for subshells, and every shell should inherit its environment from a login shell.

This is the problem; it's not the case that every shell is a child of a login shell. When you remotely execute a command (i.e. ssh localhost 'echo $PATH'), that command shell is not a child of any login shell. .bashrc is read but .bash_profile is not, as you already noted. If you want remote commands to work correctly, you need to set PATH in .bashrc.

Personally, my .bash_profile is just

source ~/.bashrc

so I get the same environment whether or not bash is a login shell.

it just seems like an odd design choice... requiring the the client to know the disk location of the mosh-server

It's not a design choice, and that's not what we require. :) It's just what happens when you execute commands remotely over ssh, as mosh does. The client only needs to know the location of mosh-server if it's not in a standard path like /usr/bin or a path set in the user's shell rc.

We could definitely improve the documentation and error messages surrounding this issue, though.

[Peeja]

Okay, so if I'm reading you right, I was incorrect in thinking that the .bashrc shouldn't set PATH. If that's true, then that makes sense to me. I've got it working that way now.

Thanks for taking the time to dig in with me.

[scentoni]

I was having a similar problem, so I tried setting PATH in my .bashrc file. This seems to work in ssh:

$ ssh 192.168.69.130 'mosh'
Usage: /opt/csw/bin/mosh [options] [--] [user@]host [command...]
...

yet

$ mosh 192.168.69.130
bash: mosh-server: command not found
Connection to 192.168.69.130 closed.

Can you explain this? I am able to connect using mosh 192.168.69.130 --server=/opt/csw/bin/mosh-server.

[andersk]

@scentoni, that may be #465.