4

One of the universities I know has a rather unique password policy. They issue shell accounts to all computing students with strong passwords that are unchangeable. It is done via the passwd -n flag which sets the minimum number of days between password changes. A high enough number essentially means that the user will never be able to change his/her password.

The passwords are then sealed in an envelope which can be opened only by the student. Students are reminded to request a new password if the envelope's seal is broken.

When prompted on this unique practice, the university mentioned that many students in the past used a weak password and a number of accounts were compromised through brute force attacks.

Another university in a very small country simply uses a GeoIP filter to block out all brute force attempts.

Does anyone know of any other practice which can be used to protect a SSH service which is used by many inexperienced users?

  • 3
    Public key authentication? – Deer Hunter Aug 2 '15 at 18:45
  • Does the admin or the user generate the key? If the user generates the key, won't the user also need initial password access to upload the public key? If the admin generates it, how does he securely transmit and deploy the key on the user's machine? – limbenjamin Aug 2 '15 at 18:48
  • 1
    Never let the admin generate the keypair. Let the user do it, print out a QR-code of the public key, and present photo ID with the printout. – Deer Hunter Aug 2 '15 at 19:11
  • 2
    Another option is to set up an ad-hoc network during one of the classes and have the students connect to it and upload their keys to one location (not, obviously, the server). The keys are then added en masse to the appropriate folder in the SSH server. This assumes that the students aren't malicious and neither is the machine they upload to, but I think you're assuming that anyway. – KnightOfNi Aug 2 '15 at 20:13
  • Thanks for the advice, they are interesting solutions that might work. – limbenjamin Aug 3 '15 at 9:58
2

I suggest Fail2ban on all SSH servers, especially with inexperienced users. This lets you block any IP that fails to log in too often (iirc, the default is 10 tries in 10 minutes gets an IP blocked for 10 minutes). This may now be possible with just OpenSSH via MaxAuthTries, MaxSessions, and MaxStartups.

In addition to that, I'd suggest regularly running John the Ripper on each user's password hash. If it finds the user's password, have it email the user a guide to better passwords and require the user to change the password. (Be sure to make that email easily verifiable; the last thing you want is for the user to discard it as a phishing attack!)

Passwords that cannot be changed are dangerous. The password is likely hard to remember, so the user will probably write it down, and somebody else could find that note.

  • I'd agree with everything you said except the part about writing down the password. These are school systems, not the NSA. Writing down the password is fine, and if your friend hax0rs you, big deal. The threat model in this case is somoene outside the university putting malware on the network. – Steve Sether Aug 3 '15 at 21:32
  • @SteveSether it'd be really annoying to find out that your ~friend has your password and then not be able to change it. – Adam Katz Aug 3 '15 at 23:42
  • It'd be more annoying for the servers to be inaccessible because some goit changed his password to password1, causing hax0rz to install a botnet on the entire network of computers. Pick your poison. – Steve Sether Aug 4 '15 at 5:09
  • That's why I suggested John the Ripper. Fail2ban limits password cracking to one a minute, John ensures the password isn't likely to be cracked in that amount of time. You are right in that if you share an IP with an attacker, you'll suffer, but I don't see any other problems. – Adam Katz Aug 4 '15 at 6:42
  • That's another acceptable solution, along with just not allowing users to change the password. – Steve Sether Aug 4 '15 at 14:24

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.