Updates to SSH: improved default shell and working directory

Hey everyone! We’ve recently made two changes to fly ssh console and fly console to give you a better experience:

The shell is chosen from /etc/passwd

When no command is specified (i.e. fly ssh console without -C and fly console without a console_command defined), both of these by default open a Unix shell. The shell was previously hardwired to /bin/sh, which is very common but not as user-friendly as alternatives like Bash. In fact, you may have found yourself frequently typing out fly ssh console --pty -C /bin/bash (it’s even in our docs!) or running bash as your first command after connecting.

We’ve updated our built-in SSH server to choose the shell from your container image’s /etc/passwd if available, falling back to /bin/sh if not. So, for example, if your app uses a Debian-based image, you’ll get /bin/bash by default when you run fly ssh console!

The working directory is now your image’s WORKDIR

The initial working directory for commands run over SSH was previously /. We just rolled out an update to make it your container image’s WORKDIR instead (if set). It’s the directory that your app is started in, and often the directory with all your code and scripts, so it makes sense to start there. (It also matches docker exec’s behavior.)

fly launch generates Dockerfiles with an appropriate WORKDIR for a number of common frameworks. For example, if you’re running a Rails app, WORKDIR will be set to /rails, where your code was copied.

This also means that if you want to execute scripts with fly ssh console -C, you probably don’t have to type as much. If you have been running /rails/bin/rails, you can just use bin/rails now, like you may already be doing for local development.

You may need to deploy to see these changes

These changes were made by modifying our built-in SSH server and our init process, so only new or updated machines will have them. Practically speaking, once you deploy a new version of your app, you should be good to go.