89 lines
3.4 KiB
Markdown
89 lines
3.4 KiB
Markdown
---
|
|
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 |