Posts Tagged git

Improving my OpenVPN Ansible Playbook

I had a working OpenVPN configuration. But it wasn’t the best it could be. The manpage for OpenVPN 2.3 ( was used to find particularly interesting options.

For most of the changes I had to find examples and more information through Googling, though is of particular note for popping up very often.

Improving TLS Security

  1. Added auth SHA256 so MACs on the individual packets are done with SHA256 instead of SHA1.

  2. Added tls-version-min 1.2 to drop SSL3 + TLS v1.0 support. This breaks older clients (2.3.2+), but those updated versions have been out for a while.

  3. Restricted the tls-ciphers allowed to a subset of Mozilla’s modern cipher list + DHE for older clients. ECDSA support is included for when ECDSA keys can be used. I’m uncertain of the usefulness of the ECDHE ciphers, as both my client and server support it, but the RSA cipher that’s 3rd in the list is still used. Continuing to investigate this.

The last 2 changes are gated by the openvpn_use_modern_tls variable, which defaults to true.

  1. New keys are 2048 bit by default, downgraded from 4096 bit. This is based on Mozilla’s SSL guidance, combined with the expectation of being able to use ECDSA keys in a later revision of this playbook.

  2. As part of the move to 2048 bit keys, the 4096 bit DH parameters are no longer distributed. It was originally distributed since generating it took ~75 minutes, but the new 2048 bit parameters take considerably less time.

Adding Cert Validations

OpenVPN has at least two kinds of certification validation available: (Extended) Key Usage checks, and certificate content validation.


Previously only the client was verifying that the server cert had the correct usage, now the verification is bi-directional.
OpenVPN, more about EKU checks: 1 & 2

Certificate content

Added the ability to verify the common name that is part of each certificate. This required changing the common names that each certificate is generated with, which means that the ability to wipe out the existing keys was added as well.

The server verifies client names by looking at the common name prefix using verify-x509-name ... name-prefix, while the client checks the exact name provided by the server.

Again, both these changes are gated by a variable (openvpn_verify_cn). Because this requires rather large client changes, it is off by default.

Wiping out & reinstalling

Added the ability to wipe out & reinstall OpenVPN. Currently it leaves firewall rules behind, but other than that everything is removed.

Use ansible-playbook -v openvpn.yml --extra-vars="openvpn_uninstall=true" --tags uninstall to just run the uninstall portion.

Connect over IPv6

Previously, you had to explicitly use udp6 or tcp6 to use IPv6. OpenVPN isn’t dual stacked if you use plain udp/tcp, which results in being unable to connect to the OpenVPN server if it has an AAAA record, on your device has a functional IPv6 connection, since the client will choose which stack to use if you just use plain udp/tcp.

Since this playbook is only on Linux, which supports IPv4 connections on IPv6 sockets, the server config is now IPv6 by default (, by means of using {{openvpn_proto}}6.

Hat tip to T-Mobile for revealing this problem with my setup.


  1. Add revoked cert check

  2. Generate ellptic curve keys instead of RSA keys However, as noted above, ECDHE ciphers don’t appear to be supported, so I’m not sure of OpenVPN will support EC keys.

  3. Add IPv6 within tunnel support (Possibly waiting for OpenVPN 2.4.0, since major changes are happening there)

This SO question seems to be my exact situation.

Both this SO question and another source are possibly related as well.

Tried splitting the assigned /64 subnet with:

ip -6 addr del 2607:5600:ae:ae::42/64 dev venet0
ip -6 addr add 2607:5600:ae:ae::42/65 dev venet0
  1. Investigate using openssl ca instead of openssl x509next version of easyrsa uses ca

, ,

No Comments

Pushing an existing repo to github

Because I’ve had to do it a number of times, and had to look it up each time:

  1. Create the repo on github
  2. On the desktop/laptop/whatever, in Git Bash, change to the folder with the repo
  3. Run:

git remote add origin [email protected]:username/repo.git, then
git branch --set-upstream master origin/master and finally
git pull

And done.


No Comments


The bulk of this was written on Nov 16th before I finished CS137 at UW. Most of this stuff still stands.


(Also, why I’m glad I’m using Git, why I love Stack overflow, and frak yes Valgrind) Read the rest of this entry »

, , ,

No Comments

My Git for CS137 setup

I’ve been using Git and GitHub for all of my CS137 assignments, in part to keep the files in sync between my desktop and laptop, as well as the UW server that I use for testing. The keeping everything in source control is a bonus, but one that comes in handy, especially branching when I discover that actually my code can be rewritten in a better way.

The primary impetus for this post is that I’ve been creating a branch for each assignment, but I still have yet to get the branching push/pull commands down pat, so I always end up searching Google for the appropriate commands. After 6 branches (and counting), I’ve gotten tired of that, so I shall centralise it in one place:

Pushing a new branch: git push origin new_branch

Pulling a new branch: or git pull && git checkout --track origin/new_branch or git checkout new_branch

Read the rest of this entry »

, ,

No Comments

ssh-agent messiness & solving it

I’ve known about ssh-agent for a while, but as I was practically permanently using PuTTY (on Windows), I only bothered with learning about Pageant.

But Git uses ssh to connect to github, and I was getting tired of typing in my password with every push. I got annoyed with InteliJ for making me type in my password in with every push, and this was no different. Because git uses bash as its’ command line on both Windows and Linux, I decided to get started with using ssh-agent.

The first time I ran ssh-agent expecting it to work automagically. Instead it dumped what looked like two environment variables to the screen and quit. Not too helpful, but I manually copied, formatted & pasted the variables, and got it working.

But doing that manually, while awesome when pushing from one system and pulling on another, was also annoying with having to do it every time I logged in. So I looked into automating it. I knew of eval and backticks in bash. So I tried `ssh-agent`.

$ `ssh-agent`
sh.exe": SSH_AUTH_SOCK=/tmp/ssh-myYvgp1404/agent.1404;: No such file or directory

Hmm. No joy. Ok, let’s try eval ssh-agent. Maybe that’ll make a difference?

$ eval ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-zIQZKN6080/agent.6080; export SSH_AUTH_SOCK;
echo Agent pid 1092;

Nope, back to manually editing it. Hmm. Google search time.

Which led me to a uni helpdesk page. Which told me that I had to use both eval and backticks. Huh. How ingenious.

$ eval `ssh-agent`
Agent pid 4288


So I gleefully ran it on the uni’s servers. And then discovered I had to run it in every bash shell. Hmm. Sounds kind of unoptimal. Fixed my original problem, which was having to type in my password each and every time I pushed or pulled from github. And using eval and backticks meant it was easier than copy & pasting the output. But I didn’t like having to run ssh-add and ssh-agent in every new session, or that ssh-agent wouldn’t auto-terminate when I closed bash. (Which led to a surprise when I ran ps u and saw at least 8 ssh-agent processes running with my username.)

So I just ran it in a screen session. And just have to use that one window everytime. Fairly straightforward.

The alternative was add to the commands to my .bashrc. But the uni servers seem to do something to bash such that it doesn’t execute a user’s bashrc when they login, only after they run bash. So running it in screen works just as well, since I’d need to run a command anyway.

As an alternative alternative, I also found a script that should work for keeping track of ssh-agent and can be run from .bashrc, so I’ll be looking into that too.

, , ,

No Comments

Getting a Python dev environment setup on Windows

I’ll be doing a fair amount of work in Python in the next few months, so I decided to sit down and get a good dev environment going. First on my laptop (32 bit is easier to deal with), then on my desktop.

So I’ll be doing 3 things:

  1. Getting Git setup
  2. Getting Git working with GitHub
  3. Getting Python and pip installed

First of all, started off with Git. Downloaded from, and installed it following GitHub’s Windows setup guide. (As a side note, I’m not dealing with GitHub’s native app because when I last used it, you couldn’t select individual blocks of code to be committed. I know Git philosophy is to commit often, but I just commit when I’ve got something working, and I’d have touched a few different files and done more than one thing.)

They’ve improved the installer since I last used it, so it was deceptively simple. No more messing around with config files, whee!

Second thing was integration with Github. SSH keys allow password-less authentication (I hate InteliJ’s Github integration because it uses the HTTPS repo, which requires me to enter my github password). Once again, easiest thing to do was to follow Github’s guide on generating ssh keys. Another side note: It’s ssh -T [email protected]. I was trying ssh -T and was wondering why it was failing. =|

And onto the third and final thing, which is also the most difficult: Getting Python up and running with pip installed & working. I’ll split this into two parts: getting Python, and getting pip working.

Getting Python is trivial – I downloaded it from I chose 2.7.3, but could have gone with 3.2.3. (In fact, probably should have, but modules are still coded to 2.7 compatibility, so that’s what I’ll use.)

Getting pip on is a bit more complicated – you have to install easy_install, then use that to install pip. So, I used the lovely directions at StackOverflow for inspiration:

  1. Grab setuptools from – make sure the version you get matches the version of Python installed – in my case, 2.7
  2. Install setuptools. You can follow the defaults, just make sure you install to the correct directory – where you installed Python. This should be auto-detected though.
  3. Open Powershell (I’m running Win 7; if you aren’t, you should be. And if you can’t run W7, open up command prompt instead.)
  4. In the shell, change to the directory where you installed Python, and then to the Scripts directory in that folder – ie. cd C:\Python27\Scripts
  5. Type ./easy_install pip – this works because setuptools added an executable called easy_install.exe to the Scripts/ folder
  6. Pip is now installed. If you want to install something with Pip (i.e. ), open up Powershell again if it’s not already open, change to that directory, and run ./pip install requests

For bonus points, and to get Python to run without having to prepend the directory where Python is installed to every command you run with Python, append the Python directory to your environment PATH variable.

How do you do this? On Win 7, type “Path” into the search bar in the start menu. It should get you something like this:

Select the “Edit system environment variables” option. Not the one with “Your account”.

That will take you to this screen. See the button close to the bottom labeled “Environment Variables”? That’s the one you want to click. And when you do that, you’ll get this:

I’ve skipped a bit, but you want to scroll though the box on the bottom to find the Path variable. When you’ve found it, either double click on it, and single click to select it, and press Edit.

When the screen comes up, hit “End” on your keyboard to jump to the end of the line, then add a semi-colon (which is the ; symbol, if you don’t know), and paste the directory where you installed Python. Or type it. Copy & Pasting directly from an Explorer window is less error prone, so that’s what I do.

Because it’s a system variable, it’ll only take global effect when you restart your computer. If you just want to use Python in Powershell though, just open a new Powershell instance. You can verify that Python’s present in your Path by typing $env:Path and looking at the end of the line that gets printed.


, , ,

1 Comment