Our outfit uses a similar setup on our development servers. If our developers need to run commands to control the server instance, they can use our 'assume' command --- which is simply a wrapper around ssh. Production servers are off limits to developers, unless we need to debug something serious.
Every developer that is authorized to login to the server instance's account has an entry in that server's authorized_keys(See the AUTHORIZED_KEYS FILE FORMAT section for details) file, but each authorized key has a flag that sets an environment variable unique to their username:
environment="SSHUSER=jason" ssh-rsa (BASE64-ENCODED-KEY) jason@localhost
In that server instance's .bashrc, I have a little snip of code:
USERHOME=$(eval "echo ~$SSHUSER")
if [ -f "$USERHOME/.client_bashrc" ]; then
. "$USERHOME/.client_bashrc"
fi
Our developers can keep a .client_bashrc file (seperate from their .bashrc) with world-readable permissions in their home directory. Separating their .bashrc from .client_bashrc helps with security, since they can keep private definitions and environment variables in .bashrc. They can optionally put a line of code in their personal bashrc to simply include .client_bashrc, and keep aliases and definitions there that make working with the system easier. (This all assumes the user's home directory is accessible from the dev server.)
Warner makes a good point in his comment that this shared-username setup is against security best practices. Our system evolved from an account on a shared host years ago. We are only just now coming around to limiting the power of developer accounts, and moving to a system where developer actions are placed in an audit log.
Any encryption mechanism will add an overhead to your connection, have in mind that overheads for some encryption are enormous.
OpenVPN by average will add a 40% to 50% overhead to your connection, on top of that ssh will also add a 40% overhead average.
All this can very easily explain why your connection over openvpn+ssh is so slow, you can do some things to make the connection lighter but it'll sacrifice a bit of security.
- Use crypto signatures of 1024 bytes top (don't go 2048 or 4096 unless you really need to)
- Use SSH1 or SSH2 with RSA instead of DSA (a bit less overhead)
- Use SSH compression by default
All this will help make the tunnel lighter and faster, also if you have direct SSH access try using SSH tunnels to your application instead of OpenVPN, will remove one encryption layer and will also help speed wise.
I've replied to your question because I find it interesting but have in mind that if you don't accept your answers (the 17% accept rate indicates that), the community will be a lot less willing to help you out, this site is all about community and that accept rate is showing you as a not community player, which will hinder your results in the future.
Just take it as my 2ยข, no criticisim!
Best Answer
Try Mosh.