age encryption fails on passing an SSH key

[danial23]

Describe the bug

I want to use age encryption with my ssh keys. I tried setting the AGE_PUBLIC_KEYS_FILE env var to point to a file which contains two comma-separated age recipients with the ssh-ed25519 public key format. Running the backup command results in the following error:

time=2025-02-04T04:41:24.278Z level=INFO msg="Created backup of `/backup` at `/tmp/backup-2025-02-04T04-41-23.tar.gz`."
time=2025-02-04T04:41:24.293Z level=INFO msg="Removed tar file `/tmp/backup-2025-02-04T04-41-23.tar.gz`."
time=2025-02-04T04:41:24.293Z level=ERROR msg="Fatal error running command: malformed recipient \"ssh-ed25519 [REDACTED]\": mixed case" error="main.(*command).runAsCommand: error running script: main.runScript.func4: error running script: main.(*script).encryptArchive: failed to get configured age recipients: main.(*script).getConfiguredAgeRecipients: failed to parse age public key: malformed recipient \"ssh-ed25519 [REDACTED]\": mixed case"

To Reproduce
Steps to reproduce the behavior:

1. Create a file named age_recipients containing two ssh-ed25519 public keys separated by a comma:

ssh-ed25519 [some key],ssh-ed25519 [some key]

2. Launch the docker service with a compose.yml file similar to this:

services:
  ...
  docker-volume-backup:
    image: offen/docker-volume-backup:v2
    container_name: docker-volume-backup
    secrets:
      - DOCKER_VOLUME_BACKUP_AGE_PUBLIC_KEYS
    environment:
      AGE_PUBLIC_KEYS_FILE: /run/secrets/DOCKER_VOLUME_BACKUP_AGE_PUBLIC_KEYS
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      ...
      - ${HOME}/backup:/archive
secrets:
  DOCKER_VOLUME_BACKUP_AGE_PUBLIC_KEYS:
    file: ./age_recipients

3. Run docker exec -it docker-volume-backup sh
4. Type backup and press Enter

Expected behavior

An encrypted archive saved to the ~/backup directory

Version (please complete the following information):

• Image Version: v2.43.1
• Docker Version: 27.5.1
• Docker Compose Version (if applicable): v2.32.4

Additional context

[m90]

Looking at the doc string from age

// ParseRecipients parses a file with one or more public key encodings, one per
// line. Empty lines and lines starting with "#" are ignored.
//
// This is the same syntax as the recipients files accepted by the CLI, except
// the CLI also accepts SSH recipients, which are not recommended for the
// average application.
//
// Currently, all returned values are of type *X25519Recipient, but different
// types might be returned in the future.

it seems as if SSH keys are currently supported only by the age CLI, while the library expects an age key generated by age-keygen, so your setup currently fails because the tool expects an age key.

As I did not add this feature myself and I have never used age before I am not sure exactly how many hoops we'd have to jump through in order to get age encryption to support SSH keys as well. In the meantime you can resort to using an age key or use PGP.

As a start, this limitation needs to be mentioned in the documentation in any case.

Seeing that the comment in the age source code says using SSH keys is "not recommended for the average application", I am slightly unsure whether adding support for this is a good idea. Could you elaborate on your use case in case this is a hard requirement for you?

[m90]

Mentioned this in the documentation in 40b12b9

[danial23]

Could you elaborate on your use case in case this is a hard requirement for you?

It's just a way for me to avoid key management, not a hard requirement. I've been using a single SSH keypair to do everything else on my server like deploy services, decrypt secrets etc.

Thanks.

[m90]

I'll leave this open until I find the time to look into what the age CLI is doing exactly to support this. Maybe it's easy and can be added (I do understand your convenience argument), maybe not.

[m90]

It seems there is a dedicated agessh package: https://github.com/FiloSottile/age/blob/main/agessh/agessh.go that will allow you to parse SSH keys into 'age.Recipient`s, so it shouldn't be all too complicated to support this.

If anyone wants to open a PR that adds the feature, please lmk. Else I might look into it at some point, but cannot give any estimate whatsoever.

[m90]

This is now supported as of v2.43.2