Post AvT3hre1FgRTWq954y by JulianOliver@mastodon.social
 (DIR) More posts by JulianOliver@mastodon.social
 (DIR) Post #AvS2BqHKV7TYugjuj2 by clacke@libranet.de
       2025-06-24T09:21:44Z
       
       0 likes, 0 repeats
       
       When you have an ssh jumphost, the trivial setup is one that conflates OS access and application access.The application is ssh, providing the jump to the privileged network, but ssh also allows OS access, potentially allowing privilege escalation within the jumphost.Are people taking this seriously and e.g. running an unprivileged sshd inside a container? Access the OS over port 22 to the privileged sshd, restricting that to the segregated admin network, access the jumping over port 2222 and minimize the attack surface on the outer host?#infosec #bastion #jumphost#ssh #sshd #OpenSSH
       
 (DIR) Post #AvS5Tf5v7a29Ilajtg by clacke@libranet.de
       2025-06-24T10:04:56Z
       
       0 likes, 0 repeats
       
       @jay I'm guessing most people find that sufficent, but I wonder if some setups regulated by PCI DSS, ECB etc are required to resolve this OS vs app conflation.I'm particularly curious if minimal sshd implementations exist, that don't expect to run as root and don't provide any functionality other than jumping, rather than just trying to fortify a full-fledged OpenSSH sshd with the right configuration.
       
 (DIR) Post #AvSkBv0vI5yTaCucJE by grumpybozo@toad.social
       2025-06-24T17:22:26Z
       
       1 likes, 0 repeats
       
       @clacke Yes and no… Instead of the overhead of containers, my 'jump' machines bind specific keys to the ssh commands that do the specifically authorized next hops and (where possible) restrict to specific client IPs. The OS of those machines are only accessible over a VPN or (for some VMs) a tightly secured web interface that has VNC over WebSockets inside a private network to their virtual consoles. #infosec #bastion #jumphost#ssh #sshd #OpenSSH
       
 (DIR) Post #AvT3hre1FgRTWq954y by JulianOliver@mastodon.social
       2025-06-24T20:10:22Z
       
       1 likes, 0 repeats
       
       @grumpybozo @clacke tunnel solely over VPN, ingress IP set in authorized_hosts and/or ip(6)tables, & to jailed lobby user (no root SSH, even with keys), whose $SHELL is rbash or so, only accessible binary in immutable path sudo, for escalation to root. Jailed VMs should be reached from host over SSH, not outside, no attack surface dilation with VNC, unless over VPN. Should be no VM<->VM traffic on bridge other than needed (like to MTA via VM), no traffic VM->host, other than through rev proxy
       
 (DIR) Post #AvT3hwtniR2LpEZFs8 by JulianOliver@mastodon.social
       2025-06-24T20:21:16Z
       
       1 likes, 0 repeats
       
       @grumpybozo @clacke an oft overlooked vector is sysadmin machines with dangling SSH agents set to an identity allowing an open door to root on a remote machine. Laptops are stolen left AFK powered on, a fuzzable lock screen between the attacker and root on remote hosts, and often just a few up arrows back in history. This is another reason why it is wise to have a depriv jailed UNIX account (no bypasses) as a landing or lobby account, and with a tight sudo timeout. A 2nd line of defense.
       
 (DIR) Post #AvT3i6sOcVr4llzH4S by grumpybozo@toad.social
       2025-06-24T20:52:20Z
       
       1 likes, 0 repeats
       
       @JulianOliver @clacke I am fortunate enough to have a limited number of very paranoid colleagues who could theoretically have such issues and we work to reduce the attack surface, e.g. no root login, no passwordless escalation (doas/sudo) by users who can log in, idle logouts, and we avoid issues with X and lockscreens by not having X (or any other GUI) installed.
       
 (DIR) Post #AvT3iFlzXh50MW3mq0 by JulianOliver@mastodon.social
       2025-06-24T21:05:13Z
       
       1 likes, 0 repeats
       
       @grumpybozo @clacke that sounds sane and healthy.I also do not use a desktop environment on my sysadmin machines, to minimise the surface (and also because I like it). But I teach a lot of sysadmins and while we work together to lock down their sysadmin machines, there's only so much I can do or impose, and I've also little control of their operating context. Some of my students look after high value targets, with capable adversaries, & so are more vulnerable to physical attacks than most!
       
 (DIR) Post #AvTetBO1t89mFNvVoW by clacke@libranet.de
       2025-06-25T00:10:01Z
       
       0 likes, 0 repeats
       
       @JulianOliver @grumpybozo Oh yes, these are all very good suggestions for hardening. Especially the `from="pattern" ssh-ed25519 ...` bit in .authorized_keys, very nice.
       
 (DIR) Post #AvTete851Vd7OJggTo by JulianOliver@mastodon.social
       2025-06-25T04:08:59Z
       
       1 likes, 0 repeats
       
       @clacke @grumpybozo Yeah, some low-cost high-quality walling! Can even define which commands the SSH client can reach on host with command=" ", and set extra hardening options, like: `no-pty,no-user-rc,no-port-forwarding,no-agent-forwarding` to really lock it down further.