Black Hat 2024: Secure Shells in Shambles [pdf] • Hacker News Board

Re: Black Hat 2024: Secure Shells in Shambles [pdf]

#31

Post by davidfiala » Tue, Aug 13, 2024, 6:15 PM UTC

Great presentation.

As the founder of teclada.com, I'll also share that one of the biggest risks is not even technical but human:

  - not managing your SSH keys properly
  - not even knowing where they are
  - reuse, copying, etc
  - forgotten placement of keys in authorized_keys

And worst of all:

  - "no way I'm going to even consider changing any of it"
  - "our audit logs are .bash_history"

¯\_(ツ)_/¯

Re: Black Hat 2024: Secure Shells in Shambles [pdf]

#32

Post by jcynix » Tue, Aug 13, 2024, 9:03 PM UTC

g_p wrote: post #30

jcynix wrote: post #4

Earlier quoted context omitted.

Every now and then I use GnuPG encrypted emails (or a web form) to my servers to open the firewall for certain IP addresses. If the server can decrypt such a message it can safely act on it. The server's default is to only allow certain network ranges to access certain ports, e.g. from my local providers or employers networks.

Presumably you sign the emails rather than encrypt them? Otherwise anyone who knew the public key of the server (which shouldn't be presumed secret) could send an encrypted instruction, and it would be acted upon, and past encrypted instructions could be replayed.

> Presumably you sign the emails rather than encrypt them?

That's correct, encrypted and signed. Replaying wouldn't be easy because the payload contains a timestamp. The main purpose was to limit the networks which can attempt to connect to ssh and still allow me to have a fallback if I'd happen to be outside of the "usual" network ranges.

Re: Black Hat 2024: Secure Shells in Shambles [pdf]

#33

Post by jcynix » Tue, Aug 13, 2024, 9:11 PM UTC

anotherhue wrote: post #11

jcynix wrote: post #4

Earlier quoted context omitted.

Every now and then I use GnuPG encrypted emails (or a web form) to my servers to open the firewall for certain IP addresses. If the server can decrypt such a message it can safely act on it. The server's default is to only allow certain network ranges to access certain ports, e.g. from my local providers or employers networks.

Doesn’t wireguard solve the same issue? Crypto key packet authentication?

> Doesn’t wireguard solve the same issue?

Presumably, but my solution is quite a bit older and just a poor man's hack from about 20 years ago ...