3 ms·

> While good luck doing that on a laptop that is only ever used to establish an SSH session. [...] > Set that up about ten months ago now (don't remember exac

by dgl 3y ago

> While good luck doing that on a laptop that is only ever used to establish an SSH session. [...] > Set that up about ten months ago now (don't remember exactly). It's working flawlessly. Not a single issue. So now your laptop hasn't had security updates for 10 months? Things like this are part of the reason I did the research in https://dgl.cx/2023/09/ansi-terminal-security https://dgl.cx/2023/09/ansi-terminal-security. It also funny that you've reinvented basically a serial console, but in a modern way, with a second factor. (You could actually just use a physical terminal with S/Key or something.) > P.S: it's just a proof of concept... But I think that requiring to tap a Yubikey every single time you want to do something as root is something that should be envisaged/discussed more and it was great to read TFA doing it too. Agreed, https://neilzone.co.uk/2022/11/using-a-yubikey-or-other-security-key-for-sudo-via-pam/ https://neilzone.co.uk/2022/11/using-a-yubikey-or-other-secu... is another potential option for this.

TacticalCoder 3y ago
> So now your laptop hasn't had security updates for 10 months? Things like this are part of the reason I did the research in https://dgl.cx/2023/09/ansi-terminal-security https://dgl.cx/2023/09/ansi-terminal-security. That is very interesting: I'll study that. You're correct: it's a Debian 12.2 install (seriously hardened). I take it the surface attack is small. I'm literally using only SSH from that machine: it's got a firewall too. It's only allowing new SSH out session to the desktop. Every other traffic is rejected. So what can realistically affect that machine? SSH exploits for sure... So for example for the recent SSH "terraspin" exploit, I did implement the workaround (by removing broken Ciphers and MACs from the list of authorized ones). I don't know about the rest: I mainly SSH as root into the desktop when I need to install a new package and that's about it. I'm not losing too much sleep over that machine that is on a private LAN and which is not directly connected to the Internet (I'm running both 192.168.x.x and 10.x.x.x at home). I'm not saying it's a panacea: it was mostly a proof of concept and as it's working fine for my usecase, I kept using it.

by dgl 3y ago

TacticalCoder 3y ago

> So now your laptop hasn't had security updates for 10 months? Things like this are part of the reason I did the research in https://dgl.cx/2023/09/ansi-terminal-security https://dgl.cx/2023/09/ansi-terminal-security. That is very interesting: I'll study that. You're correct: it's a Debian 12.2 install (seriously hardened). I take it the surface attack is small. I'm literally using only SSH from that machine: it's got a firewall too. It's only allowing new SSH out session to the desktop. Every other traffic is rejected. So what can realistically affect that machine? SSH exploits for sure... So for example for the recent SSH "terraspin" exploit, I did implement the workaround (by removing broken Ciphers and MACs from the list of authorized ones). I don't know about the rest: I mainly SSH as root into the desktop when I need to install a new package and that's about it. I'm not losing too much sleep over that machine that is on a private LAN and which is not directly connected to the Internet (I'm running both 192.168.x.x and 10.x.x.x at home). I'm not saying it's a panacea: it was mostly a proof of concept and as it's working fine for my usecase, I kept using it.