Using transmission-remote inside the container with hashed passwords?

[IBNobody]

I'm trying to run transmission-remote from within the docker container to get and update the peer port (port forwarding). I can do this, but I found that I need to supply my unhashed transmission password.

transmission-remote 9091 --auth username:password -l

I tried doing what the PIA Port Forwarding Update script does, but the issue is that transmission-credentials.txt stores the hashed password.

TRANSMISSION_PASSWD_FILE=/config/transmission-credentials.txt

transmission_username=$(head -1 ${TRANSMISSION_PASSWD_FILE})
transmission_passwd=$(tail -1 ${TRANSMISSION_PASSWD_FILE})

Is there any way I can log into transmission-remote from within the docker if I don't want to supply the unhshed password?

[edgd1er]

I can't see why password is hashed... May be there something I didn't see. but the point is TRANSMISSION_RPC_PASSWORD env should be set with the wanted password.

docker-transmission-openvpn/openvpn/start.sh

Lines 221 to 227 in 42eb2ee

	if [[ -f /run/secrets/rpc_creds ]]; then
	export TRANSMISSION_RPC_USERNAME=$(head -1 /run/secrets/rpc_creds)
	export TRANSMISSION_RPC_PASSWORD=$(tail -1 /run/secrets/rpc_creds)
	fi
	echo "${TRANSMISSION_RPC_USERNAME}" > /config/transmission-credentials.txt
	echo "${TRANSMISSION_RPC_PASSWORD}" >> /config/transmission-credentials.txt

[IBNobody]

@edgd1er I will have to dig through the docs, but back when I set the docker up, it was advised that I could change my docker env variables to be the hashed versions of the password. That way, looking at the docker config wouldn't leak the plaintext password.

So in my docker run script, I have...

-e "TRANSMISSION_RPC_PASSWORD=<hashed>" \

...with ` being the hashed password.

I worry that this is a case of not being able to have my security cake and eat it too.

Edit: It's a feature of Transmission, and I can't seem to find it in the docs of this container. But it was there once. (I'm a longtime user).

You create the container using TRANSMISSION_RPC_PASSWORD with an unhashed password, then look at wherever Transmission stores the hashed password, and finally use that as your TRANSMISSION_RPC_PASSWORD entry. BUT the downside here is that I need the unhashed value... And I don't know of a secure way of getting it and sending it to transmission-remote.

[edgd1er]

@IBNobody , https://github.com/transmission/transmission/blob/main/docs/rpc-spec.md#233-authentication shows how to use hashed password.

The value of this HTTP header is expected to be [Basic <b64 credentials>](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization#basic), where is equal to a base64 encoded string of the username and password (respectively), separated by a colon.

I'm afraid the project does not handle the hashed password at the moment. A pull request could add a feature like:
if no password but username then it' s a hashed password, is it as it is.

[IBNobody]

I wonder if I could just base64 encode the username in that case...

But if that doesn't work, I'll have to think of something else.

[IBNobody]

The answer is: You cannot use hashed/salted passwords to access transmission-remote.

I can't have my cake and eat it too.

From the Transmission Docs...

rpc-password: String. You can enter this in as plaintext when Transmission is not running, and then Transmission will salt the value on startup and re-save the salted version as a security measure. Note: Transmission treats passwords starting with the character { as salted, so when you first create your password, the plaintext password you enter must not begin with {.

This is what is happening.

When I first created the container, I set my rpc-password to something. Transmission-daemon took that, salted it, prepended it with a {, and stuck it in its configuration file. I then took the salted value (including the {) and used it as my TRANSMISSION_RPC_PASSWORD setting for the container.

Subsequent container rebuilds (docker rm, docker run) saw the TRANSMISSION_RPC_PASSWORD with the salted value and did nothing with it except pass it along to Transmission-daemon. Transmission-daemon said, "I know this is a salted password!" and uses it as the RPC password.

Because the password is now salted, I cannot use the salted password in lieu of a real password when trying to access the transmission-remote. That would be dumb, because ANYONE with the salted password could log into my transmission-remote just like they could if they had the original password.

This container does support a docker secret, specifically named rpc_creds.

docker-transmission-openvpn/docs/faq.md

Line 39 in fad0ad1

Docker secrets are also supported for the rpc credentials. To use a secret, remove both the `TRANSMISSION_RPC_USERNAME` and `TRANSMISSION_RPC_PASSWORD` environment variables and add a secret named `rpc_creds`. The secret file must contain two lines, the first line is the username and the second line is the password. Then just add it as a secret to docker, and it will be picked up automatically. This is why the name of the secret is important.

However, this is not a true solution. Besides the fact that I don't have my docker set up as a swarm, which is needed for docker secrets, this secret method is not secure in and of itself.

docker-transmission-openvpn/openvpn/start.sh

Lines 221 to 224 in fad0ad1

	if [[ -f /run/secrets/rpc_creds ]]; then
	export TRANSMISSION_RPC_USERNAME=$(head -1 /run/secrets/rpc_creds)
	export TRANSMISSION_RPC_PASSWORD=$(tail -1 /run/secrets/rpc_creds)
	fi

I could exfiltrate the secret here by just looking at the env variables running in the container. It's harder than, say, passing them in as docker run env variables, but it's still not secure.