The Secure Shell (SSH) protocol has survived as an internet-facing management protocol for almost 30 years. Over the decades it has transformed from a single patented codebase to a multitude of implementations available on nearly every operating system and network-connected device.<p>This presentation dives deep into the Secure Shell protocol, its popular implementations, what's changed, what hasn't, and how this leads to unexpected vulnerabilities and novel attacks. An open source tool, dubbed "sshamble", will be demonstrated, which reproduces these attacks and opens the door for further research.<p><a href="https://github.com/runZeroInc/sshamble">https://github.com/runZeroInc/sshamble</a>
SSH and other services can be further protected by Single Packet Authentication (SPA), <a href="https://github.com/mrash/fwknop">https://github.com/mrash/fwknop</a><p><i>> SPA requires only a single packet which is encrypted, non-replayable, and authenticated via an HMAC in order to communicate desired access to a service that is hidden behind a firewall in a default-drop filtering stance. The main application of SPA is to use a firewall to drop all attempts to connect to services such as SSH in order to make the exploitation of vulnerabilities (both 0-day and unpatched code) more difficult.</i>
> Tons of issues in the periphery<p>I wonder how TinySSH[1] compares<p>[1] <a href="https://github.com/janmojzis/tinyssh">https://github.com/janmojzis/tinyssh</a>
Great presentation.<p>As the founder of teclada.com, I'll also share that one of the biggest risks is not even technical but human:<p><pre><code> - not managing your SSH keys properly
- not even knowing where they are
- reuse, copying, etc
- forgotten placement of keys in authorized_keys
</code></pre>
And worst of all:<p><pre><code> - "no way I'm going to even consider changing any of it"
- "our audit logs are .bash_history"
</code></pre>
¯\_(ツ)_/¯