What Approaches Allow Automated, Secure SSH Server Access?

This page describes options to secure systems accessed via SSH, information collected as part of securing our laboratory systems. In particular, three different threat models are considered:

  1. Remote attacker with zero inside knowledge, but the ability to try connecting directly to the SSH resource (server).
  2. Remote attacker with transient access to a compromised computer used to access the SSH resource (server).
  3. Remote attacker with permanent access to a compromised computer used to access the SSH resource (server).

This analysis also considers only the security of the primary authentication mechanism. A reasonably good solution here can be nullified if the process a user uses to recover access in the event they lose their credentials is weak. For example, the common method of emailing a recovery link to the user upon request is roughly equivalent to the pure password entry below (weaker for users who select a strong password).


Method Overall
Security		 Threat Models Access Automatibility Encourages
Secure Behavior		 User Best Practice
1 2 3
Password orange red red red green green http://sshpass.sourceforge.net orange Randomly generate a long (15+ character) password (secure password manager)
Password & Challenge Questions orange orange orange orange green green AutoTFA orange Randomly generate long (15+ character) password and random, long responses to secret questions (secure password manager)
Password & Google Authenticator(TOTP/HOTP) yellow green yellow yellow yellow green AutoTFA red Randomly generate long (15+ character) password (secure password manager)
Password & Second Channel(SMS/Ph) yellow green yellow yellow yellow yellow Requires VoIP SMS Messaging and scripting. Alternately, establish permanent/long-time connection with user device A. User devices B/C/D/etc. then access via device A. red Randomly generate long (15+ character) password (secure password manager)
Public/Private Keypair yellow green yellow yellow chartreuse green Directly with ssh or ssh-agent yellow Choose a random passphrase and, if possible, use the next option
Hardware Public/Private Keypair green green chartreuse chartreuse chartreuse green Directly with gpg-agent green Always require a PIN for every authentication (e.g. with YubiKey)
Password & Separated Hardware Token green green chartreuse chartreuse yellow yellow Establish permanent/long-time connection with user device A. User devices B/C/D/etc. then access via device A. yellow Randomly generate long (15+ character) password (secure password manager)

SUMMARY: If a user device is compromised, an attacker will gain access to the resource [in fact, there are demonstrated examples of every option listed being attacked in a widespread manner by attackers of minimal skill]. If access by user devices is a requirement, the most effective security is to assume users will be compromised and design defenses accordingly (principle of least privilege, effective auditing and monitoring including actual-human-being review, etc.). Public/Private Keypairs (with dedicated hardware or not) is the best choice in most scenarios, since they prevent credential theft (assuming appropriate passphrases have been set, of course) while not encouraging users to implement less secured workarounds.


Welcome to the collection of programs and patches that we are publically releasing in the hope that others find them useful. They are provided WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Copyrights remain with the owners of the respective works.