initial

presentation/ssh-advanced.md

@@ -0,0 +1,89 @@
+---
+theme: uncover
+_class: lead
+size: 16:9
+paginate: true
+footer: "SSH advanced uses - Felix"
+marp: true
+backgroundColor: #fff
+backgroundImage: url('https://marp.app/assets/hero-background.svg')
+---
+# **SSH advanced uses**
+
+Cool things you can do with **ssh** beyond the basics
+<span style="color: darkgrey; font-size: 0.5em">(**s**ecure **sh**ell, though nobody calls it that)</span>
+
+---
+## TOC
+1. [Port forwarding](#port-forwarding)
+2. [ProxyJump](#proxyjump)
+3. [Certificates](#certificates)
+4. [X11 forwarding](#x11)
+5. [outdated hosts](#modern-client-old-hosts)
+6. Control channel reuse
+7. ssh_config best practices & tricks
+---
+# Port forwarding
+
+---
+# ProxyJump
+The problem: *remote-server* can only be accessed from *jumphost*, so you need to connect to *jumphost* first and then connect to *remote-server*.
+<!-- Most people instinctively log onto the jumphost into an interactive shell, then use the jumphost's ssh to connect to their intended destination (remote-server). This creates many problems, most glaringly you have to expose your authentication credentials to the jumphost. As discussed in the basics, you *never* put your private key onto a machine that is not your personal workstation, and you never forward agent to a system where you are not root and trust the other co-roots (and even then it's discouraged).
+A large problem usually arises when people need to copy files from *client* to *remote-server*, because often times the jumphost is an aging solaris machine with 50MB user quota or something like that.
+-->
+
+openssh from ca 2016 on allows you to do
+```ssh -J user@jumphost root@remote-server```
+<!-- This creates port forwarding under the hood, first making a connection from *client* to *jumphost* with port forwarding, then a second connection from client to the remote ports on jumphost -->
+
+---
+# Certificates
+
+Awesome!
+
+---
+
+## create CA 
+```ssh-keygen -f my_ssh_cert_authority```
+<!-- yes, the same command as a regular ssh key - this is just a regular ssh key! -->
+
+--- 
+
+## sign a pubkey
+```ssh-keygen -V +1h -s my_ssh_cert_authority -I felix_via_cert my_test_user.pub```
+<!-- -V is the validity / lifetime of a signed cert; -s is the signing key, -I gives the pubkey to sign -->
+This creates ```my_test_user-cert.pub```, get this back to the user requesting access.
+
+---
+### inspect a signed cert
+```ssh-keygen -L -f my_test_user-cert.pub```
+```
+my_test_user-cert.pub:
+        Type: ssh-ed25519-cert-v01@openssh.com user certificate
+        Public key: ED25519-CERT SHA256:VJyz194XhAw4HcMZ5uboj/35ZJyC9yNLP0lLtjiKCX8
+        Signing CA: RSA SHA256:5Fs780JRzis+3lEreIZGoo+Ao7hKX8ksUU58cI58AyQ (using rsa-sha2-512)
+        Key ID: "felix_via_cert"
+        Serial: 0
+        Valid: from 2024-07-14T13:46:00 to 2024-07-14T14:47:34
+        Principals: (none)
+        Critical Options: (none)
+        Extensions:
+                permit-X11-forwarding
+                permit-agent-forwarding
+                permit-port-forwarding
+                permit-pty
+                permit-user-rc
+```
+
+---
+## use your shiny new cert
+
+for openssh based systems, place the $IDENTITY-cert.pub file next to the $IDENTITY file. Make sure it has the correct permissions (of 0600), and it will be used automatically when you specify to use $IDENTITY.
+
+---
+# X11
+- check out x2go
+
+---
+# modern client, old hosts
+Increasingly often, I get old (older than 2016 or so) kit that does not let me connect