---
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