0

I want to use CA signed SSH keys (that would be rotated frequently and have short expiry, ideally centrally managed, all that great stuff). Unfortunately, most of windows GUI tools, such as WinSCP or even PuTTY, don't support these SSH certificates.

I've searched a lot, and other than finding people with the same question, there is never a solution. Mostly, people say "just use Window's OpenSSH ssh with native scp, etc, from command line", dismissing the fact that Windows users prefer their GUI windows (and those simply don't accept signed SSH keys). I am not targeting sysadmins here, but rather developers and artists.

One enterprise-level workaround is complex software, with agents on each remote server communicating to central location, adding and removing regular SSH keys from each host while giving out disposable keys to end-users. These systems aren't cheap, nor robust (what happens when the central location is down? What happens when host was offline and missed keys update?)

So, I think I came up with a solution that would be transparent to Windows users, affordable to smaller companies (free), and not require a jump/bastion server in between.

Solution: When connecting with WinSCP, PuTTY, etc, one can setup a "local proxy" which is nothing more than a local command that is executed to create the connection. This can be configured to run Window's ssh along with the signed certificate to the server to create an authenticated and secure tunnel.

Now, the Windows tools can login... but the first thing they execute is an authentication attempt... which they cannot do with a signed SSH key.

Workaround: I configured the remote SSH server to accept CA signed SSH keys. I also configured it to allow accept password authentication with blank password, but only on 127.0.0.1:22. This way, once the Windows tool established an authenticated and secure tunnel, it will then login with a blank password, without keys.

The question: How safe is this? I basically have this at the end of my /etc/ssh/sshd_config:

Match address 127.0.0.1
    PermitEmptyPasswords yes
    PasswordAuthentication yes

I also had to add ssh to the top of /etc/securetty file

Assuming that my signed-SSH-key-based tunnel is secure, what are the implications of having a blank-password user on the system (who can do sudo), but cannot login "remotely" unless through 127.0.0.1? Since I am mainly focused on cloud based hosts, there is no physically attached console for someone to login with this user either.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.