Conversation

Notices

1. Embed this notice
   clacke (clacke@libranet.de)'s status on Tuesday, 24-Jun-2025 21:05:33 JST clacke

   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

   • Embed this notice
     🆘Bill Cole 🇺🇦 (grumpybozo@toad.social)'s status on Wednesday, 25-Jun-2025 09:08:08 JST 🆘Bill Cole 🇺🇦

     in reply to

     @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

     clacke likes this.
   • Embed this notice
     Julian Oliver (julianoliver@mastodon.social)'s status on Wednesday, 25-Jun-2025 09:19:06 JST Julian Oliver

     in reply to

     • 🆘Bill Cole 🇺🇦

     @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

     clacke likes this.
   • Embed this notice
     clacke (clacke@libranet.de)'s status on Wednesday, 25-Jun-2025 09:19:08 JST clacke

     in reply to

     • Julian Oliver
     • 🆘Bill Cole 🇺🇦
     @JulianOliver @grumpybozo Oh yes, these are all very good suggestions for hardening. Especially the `from="pattern" ssh-ed25519 ...` bit in .authorized_keys, very nice.
   • Embed this notice
     Julian Oliver (julianoliver@mastodon.social)'s status on Wednesday, 25-Jun-2025 09:19:10 JST Julian Oliver

     in reply to

     • 🆘Bill Cole 🇺🇦

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

     clacke likes this.
   • Embed this notice
     🆘Bill Cole 🇺🇦 (grumpybozo@toad.social)'s status on Wednesday, 25-Jun-2025 09:19:22 JST 🆘Bill Cole 🇺🇦

     in reply to

     • Julian Oliver

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

     clacke likes this.
   • Embed this notice
     Julian Oliver (julianoliver@mastodon.social)'s status on Wednesday, 25-Jun-2025 09:19:23 JST Julian Oliver

     in reply to

     • 🆘Bill Cole 🇺🇦

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

     clacke likes this.
   • Embed this notice
     Julian Oliver (julianoliver@mastodon.social)'s status on Friday, 27-Jun-2025 13:17:14 JST Julian Oliver

     in reply to

     • 🆘Bill Cole 🇺🇦

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

     clacke likes this.