[SECURITY] Alternative ways of sharing a connection string

[webknjaz]

While I also did something similar to access to other CIs, I'd like to point out that printing out such things to public logs is insecure, especially because some secrets can be exposed to that env.

I think that this action should have an option to send creds over email without exposing them publicly.

[mxschmitt]

Definitely, what do you recommend? Travis Ci has it also public afaik.

[webknjaz]

I'd just accept email as an input and send the creds there.

[mxschmitt]

I'd just accept email as an input and send the creds there.

But we won't have any SMTP server etc. so they would all be probably declined or moved directly to spam.

[webknjaz]

Maybe put it to https://privnote.com/ then with a user-specified password as an input? Well, could also encrypt with user-given GPG key and put it right into the log. Maybe with a helper command prompting them how to decrypt the thing.
Oh, and there's also https://keybase.io which may also be helpful...

[leo60228]

https://stackoverflow.com/a/46841303/3078446 seems relevant.

[leo60228]

const password = process.argv[2];
const data = process.argv[3];

const crypto = require('crypto');

const salt = crypto.randomBytes(16);
const key = crypto.scryptSync(password, salt, 32);
const iv = crypto.randomBytes(16);

const cipher = crypto.createCipheriv('AES-256-CBC', key, iv);

const aesbuf1 = cipher.update(data, 'utf8');
const aesbuf2 = cipher.final();

const encrypted = Buffer.concat([salt, iv, aesbuf1, aesbuf2]);

console.log(encrypted.toString('base64'));

and

const password = process.argv[2];
const data = Buffer.from(process.argv[3], 'base64');

const crypto = require('crypto');

const salt = data.subarray(0, 16);
const key = crypto.scryptSync(password, salt, 32);
const iv = data.subarray(16, 32);

const decipher = crypto.createDecipheriv('AES-256-CBC', key, iv);

const aesbuf = data.subarray(32);
let decrypted = decipher.update(aesbuf, null, 'utf8');
decrypted += decipher.final('utf8');

console.log(decrypted);

are functional (but definitely not cryptographically reviewed) scripts to do encryption using the Node standard library.

[webknjaz]

@leo60228 those snippets use AES which is symetric encryption. It's safer to use asymentric algorithms and sign the data with a public key of the person that is supposed to read the message. In this case, only the owner of the corresponding private key can decrypt it. So basically, if that gets leaked, the attacker will be able to only encrypt messages but not to read them.

[sbc100]

With CircleCI they somehow manage to install the public SSH key of the logged-in users so only the currently logged into github users (or someone with their key) can connect.

I guess that is easier since the "enable SSH" is an even triggered via the web interface. Its really a shame this isn't just a native feature of github actions (Re-run with ssh access), since normally you only want to enable ssh for individual runs that are failing for some reason.

[FedericoCeratto]

https://tmate.io/

Only allow SSH clients with specific public keys to connect to the session. To do so, create an authorized_keys file containing public keys that are allowed to connect. In this example, we'll reuse the one sshd uses, namely ~/.ssh/authorized_keys. Then, specify the authorized keys file via the tmate CLI using -a as such: tmate -a ~/.ssh/authorized_keys

[leo60228]

See https://github.com/leo60228.keys as well.

[leo60228]

This seems to be the best way of handling this:

1. Make a GET request to https://api.github.com/repos/{owner}/{repo}/collaborators.
2. For all users with permissions.admin, make a request to {user.url}/keys (ex. https://api.github.com/users/leo60228/keys.
3. Concatenate every key field of every entry in each user's array into a temporary file.
4. Pass -a file to tmate.

[leo60228]

From my understanding, https://github.com URLs aren't intended for use in scripts.

[webknjaz]

sweet

[cmfcmf]

• Concatenate every key field of every entry in each user's array into a temporary file.

For reference, this is how to concatenate the keys of a single user:

curl -s https://api.github.com/users/cmfcmf/keys | jq '.[].key' --raw-output

[FedericoCeratto]

I have two more secure alternatives:

SSH over Tor:

mkdir ~/.ssh 
echo "<REPLACE_SSH_PUBKEY>" > ~/.ssh/authorized_keys 
chmod 600 ~/.ssh/authorized_keys 
chmod 770 ~/.ssh 
chmod 770 ~/ 
apt-get install -y --no-install-recommends tor 
echo "HiddenServiceDir /var/lib/tor/ssh/" >> /etc/tor/torrc 
echo "HiddenServicePort 22 127.0.0.1:22" >> /etc/tor/torrc 
systemctl reload tor 
echo "Connect using:" 
sleep 10 
echo "ssh -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null runner@$(cat /var/lib/tor/ssh/hostname)" 

SSH over IPv6. Be aware that this exposes all running services to IPv6!

apt-get install --no-install-recommends -y miredo 
mkdir ~/.ssh 
echo "<REPLACE_SSH_PUBKEY>" > ~/.ssh/authorized_keys 
chmod 600 ~/.ssh/authorized_keys 
chmod 770 ~/.ssh 
chmod 770 ~/ 
echo "Connect using:" 
echo "  ssh -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null runner@$(ip address show dev teredo scope global | awk '/inet6/ {print $2}' | cut -d'/' -f1)" 

[dscho]

A couple of these suggestions seem really useful to me. At the same time, I don't think that the Action itself needs to be changed, but a Pull Request to add a hint to the README.md file would probably be useful. Maybe suggesting something like this:

- uses: DamianReeves/write-file-action
  with:
    path: ${{ env.home }}/.ssh/authorized_keys
    contents: ssh-rsa AAAAB[...]
    write-mode: append

[mvdbeek]

For the record, @dscho's approach works, but needed a few extra tweaks in my experience:

      - uses: DamianReeves/write-file-action@v1.0
        with:
          path: /home/runner/.ssh/authorized_keys
          contents: ssh-rsa AAAAB[...]
          write-mode: append
      - uses: DamianReeves/write-file-action@v1.0
        with:
          path: /home/runner/.tmate.conf
          contents: 'set tmate-authorized-keys "/home/runner/.ssh/authorized_keys"'
          write-mode: append
      - name: Setup tmate session
        uses: mxschmitt/action-tmate@v3

and then make sure to use a recent OS. On ubuntu-18.04 for instance you get tmate 2.2.1, which doesn't support set tmate-authorized-keys. Works fine on ubuntu-20.04.

[eine]

What about using a public key in a secret (which is exposed as an envvar)? That would allow using a key with a much limited scope, while using asymmetric encryption.

[dscho]

The best idea would probably be to add a flag, say, limit-access-to-actor which uses this GitHub API call to retrieve the stored public SSH keys of the user who triggered the workflow.

[dscho]

The best idea would probably be to add a flag, say, limit-access-to-actor which uses this GitHub API call to retrieve the stored public SSH keys of the user who triggered the workflow.

#39 implements this idea.

[dscho]

@mxschmitt I think this ticket may be closed now?

[mxschmitt]

Yup, thank you so much for implementing that!