Locking down your SSH client.

What options are their for locking down your Whonix ssh client.

Yubikey: Not recommended since it could leak key material. Maybe 2fa without use of ssh key?


Yubikeys supports storing OpenPGP (GnuPG / gpg) keys, OpenSSH keys, but I wouldn’t trust it. Another yubikey model had a PIN bypass bug. ( https://developers.yubico.com/ykneo-openpgp/SecurityAdvisory%202015-04-14.html )

Qubes split-ssh: Hasn’t been maintained for 2+ years. Has multiple forks but those people are unknown (to me).

ip/nf-tables: on both firewall and client box. Maybe designate an interface on firewall for ssh only. Block everything else.

Small tweaks: Change ssh to different port, strong password for key access etc…

Anythig else??

1 Like

For reference:

The value of 2FA is imo non-zero, low. Tried to flash that out for when it is useful and when not useful here: https://www.whonix.org/wiki/Two-factor_authentication_2FA

I speculate if you’re creating such a threat here, you might be in the same group of users who don’t fall for attacks that would be protected by 2FA.

Either that or any other kind of 2FA. Conindently today I was looking into all pam modules available from packages.debian.org. In result, I created a list of promising candidates for use with 2FA. While I didn’t look closely at any of these at first sight these seem to use open standards, sane, libre, you name it.


Nothing too special about yubikey here. Even a (separate) (dedicated) (old) phone(s) with TTOP (commonly known as “google authenticator” / AndOTP) could very likely be used for Linux PAM, which looks great. Basically any form of authentication modules can be stacked in any configuration for any way of authentication (virtual terminal (login), xscreensaver, sudo, su, lightdm, ssh). I.e. either

  • password only,
  • password or 2FA,
  • password and 2FA
  • password + TTOP + fingerprint

What works locally for login, sudo and/or su should also work (locally for testing and) on remote for ssh.

I see limited, non-zero value in split-gpg / split-ssh. It does not add much to security hardening rather limited damage control. A compromised VM cannot steal the key but use the key. In case of ssh, malware could take over an ssh session, install a backdoor on the server.
This would make more sense if that SSH key is used for different purposes such as from different VMs for different servers which are not all known at the same time by the same adversary.

1 Like

I recommend using v3 onions (keeping the addresses secret to prevent unauthorized probing of SSH server). Also connecting to it from trsted VMs. This would take care of the need to protect the token from malicious access while being straightforward.

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]