Scratch images and ssh

Questions / Help
1

I have a Docker image that I’m running on fly.io that has been built from scratch, meaning it contains the binary and little else.

I want to be able to ssh/sftp in to the machine and update a configuration file in an attached volume.

However, I always get this message:

Error: error connecting to SSH server: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

I can add a base OS like Alpine and then it will work fine, but obviously that has a (slightly) larger footprint.

I’m wondering what my options are at this point.

2

Hi… The last time I tried a really stripped-down build, it turned out to be necessary to include a placebo /etc/passwd, which I think hallpass, the built-in SSH daemon, was using to determine which shell to run.

(And you would also need that /bin/bash or the like in your image, plus any helper utilities.)

Another possibility is to temporarily attach the volume to a more full-featured image. It’s counter-intuitive, but the Machines themselves are considered (mostly) disposable, :leaf_fluttering_in_wind:. So, you would actually destroy the existing Machine, use fly m run --volume to get a temporary one, and then recreate the old Machine afterward.

These days, there’s also the possibility of a multi-container Machine. In your situation, that would mean that you would have a sidecar container which existed solely to be your Bash environment. Last I checked, all such containers had equal access to the persistent volume.

(And, of course, you could boot with and without that sidecar by tweaking fly.toml, as opposed to rebuilding the main image all the time.)

Hope this helps!

4

If you only need to write a config file, you can do this in the files key when you create a machine; see the docs here. I do this, and it works very well. I would be intrigued if this were to work with the update API; I can’t tell from the docs whether it is designed to.

5

yes, it does!

6

Oh, super; thanks. Would you consider a docs update to make that clearer? I wonder if the “Machine config object properties” section would benefit from a single additional sentence saying that it can be used for both.

1 Like
7

All really good suggestions, thank you.

I actually discovered I could update the config from the running program.

But I did try both methods, based on the API suggestion I found that you could also do it from the CLI, and I ran:

fly machine update 784exampled8 --file-local /data/config.yaml=local-config.yaml

But I kept getting an error:

Error: an unhandled error occurred: ENOENT: No such file or directory

I was wondering if it was because the file was on the volume.

In the end I found it easier to detach the volume, create another machine, attach the volume, edit the config file, detach the volume and re-attach it.

That might be too many steps though.

2 Likes
8

If the volume is merely to support the creation/editing of this file, then perhaps you could always supply the file in your create and update calls, and the volume could be removed?

9

That’s an interesting point.

That does make a lot of sense for configuration.

10

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.