infra/codestorage/hg-ssh

Paddy 2015-10-15 Parent:121585c71fd7

5:bf7b66df555f Go to Latest

infra/codestorage/hg-ssh/create_user.sh

This time with bonus host key pinning. You know what's _super obnoxious_? Getting a MITM warning just because a Docker container restarted. So, basically, every time you set up an SSH server, it generated its own public/private keypair. And the first time you connect, you'd get that public key from it, and store it locally. Then if you tried connecting later, and a different public key was used, OpenSSH would vomit an error in your face and stop the connection, because it thought you were running into a man-in-the-middle attack. Which is generally a Good Thing. But when we apply this to Docker, it becomes problematic. I'm not subject to a MITM attack, my container just restarted, you silly machine. The correct way around this problem was to reuse the public/private key pair as part of the image. So I put the public keys in the image itself, and used Kubernetes secrets to mount the private keys at /data/ssh/, and then a script to copy them all over into the /etc/ssh directory, where they'd override the generated ones. This means that every instance of this container has the same public/private key combo, meaning no more warning. That solves the problem in a reasonably secure (I think) way when the image is only used by us, but if anyone else wants to use the image, suddenly they need to edit it. They need to change the public keys, because they don't have our private keys.

History
1 #!/bin/bash
3 USERNAME=$1
4 IDS=$2
6 adduser --disabled-password --gecos "" -u $IDS $USERNAME
7 mkdir -p /home/$USERNAME/.ssh && touch /home/$USERNAME/.ssh/authorized_keys
8 chmod 0700 /home/$USERNAME/.ssh && chmod 0600 /home/$USERNAME/.ssh/authorized_keys
9 chown -R $USERNAME:$USERNAME /home/$USERNAME/.ssh
10 usermod -g 2000 $USERNAME
12 ln -s /mounted/repos /home/$USERNAME/repos