A way to configure remote access for ease of development and resilience to rooted remote clients.

gistfile1.md

An SSH configuration that protects against rooted remote clients but doesn't repeatedly require you to type a password

One problem we all now realize about the SSH authorized keys system is that from the server administrator's perspective, there's no way to know how the corresponding private keys are kept. Maybe they are unencrypted. Maybe they are guarded with weak passphrases. Maybe they are stored on comprimised machines.

At the same time, developers need remote access, whether they are telecommuting or fixing an emergency bug in the middle of the night. And remote access should not mean typing your password (or an OTP) for every remote shell that's required.

Here is a system that you can hack together to solve these problems in tandem.

Network Setup

Set up machines in your network like:

[ outside internet] --- [ login0.myco.net ] --- [ login1.myco.net ] --- [ your internal network ]

login0 is a stripped down machine with only port 22 open, running an ssh that demands something like OPIE authentication (which is now going extinct) or Google Two-Factor Auth PAM module. I actually am not a huge fan of the latter since it has to accommodate clock jitter and therefore allows up to 3 PINs at any given time. OPIE seemed like a safer bet to me, with warts and all. But alas...

login1 runs SSH with PublicKey authentication on, and from there, you can SSH to anywhere in your internal network as normal. Maybe some trusted IPs can SSH directly to login1, but random IPs must go through login0. You can set up firewall rules to allow this behavior (optional).

login0 and login1 should be the only two machines that can be SSH'ed to from the outside network.

How To Access

When a remote developer wants to get some work done, they first open an SSH tunnel:

home-machine$ ssh -L2222:login1.myco.net:22 login0.myco.net

So doing will prompt them for an OTP/Google-Auth-Token/whatever is configured on login0. But this is the only time in the session that they're required to type out a password. Then, to SSH to other machines, open up another local shell, and do:

home-machine$ ssh -p 2222 -A localhost

And then from there they can bounce around as they wish, using SSH pubkey authentication. Note this system also works with SSHFS or any other tools that run over SSH.