Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSH hacks – a little sanity for remote workers

smallstep.com

Post reply on HN
Print view View original

141–150 of 230 posts

Re: SSH hacks – a little sanity for remote workers

#141

Post by mfontani »

Boulth wrote: post #137
mfontani wrote: post #111

Earlier quoted context omitted.

If a bad guy gets root on one server you're currently connected via ssh with, and forwarding said key via, they can also access (unless otherwise firewalled) all systems that ssh key grants them access to. See also: https://github.com/FiloSottile/whoami.filippo.io Using a private key per system or set of systems means that such an attacker would only gain access to what that key grants them access to. My "github" key…

I think the proper solution would be 1) don't use forwarding unless necessary 2) setup touch-to-use on a Yubikey so even with your scenario the attacker couldn't just use the key (it requires touch to be used).

I've (admittedly, conceptual only) a couple problem with this approach I'd love to hear folks' thoughts about, with regards to "touch-to-use".

1. I still have a need to "for s in $list_of_servers; ssh -A $s '..'; done"

How many times do I have to push the button? Is there a setting that allows that "push to allow" for a short while? Great, if so:

2) when I ssh into a system and touch the button to allow it, and the push allowed the use of they key for a short while, am I not in the same problem as before - as the system may be compromised and may be performing other operations I'm unawares of?

A solution for this would be to have multiple hardware keys for things I manage: one for $work, one for $personal, another for $github, etc. etc. but then managing them and - especially!! - their SSH agent which may be in memory but relies on the hardware being present, with all issues _that_ entails.... becomes a frigging mess.

So I'm torn... between the simplicity of a hardware key with push-to-allow... and actually being able to _use_ it _securely_.

Re: SSH hacks – a little sanity for remote workers

#143

Post by tgb »

jenscow wrote: post #135
tgb wrote: post #122

I often ssh then open a vim on the server. But it would make more sense to me if vim had support for open remote files via its own ssh connection instead. Does this exist (for vim or some other editors)? Then I could always use my local config and it would be easier to type on a bad connection.

Tried sshfs? It mounts sftp.

I haven't, I'll look into it.

Re: SSH hacks – a little sanity for remote workers

#144

Post by mnw21cam »

madars wrote: post #31

> When debugging a complex issue on your servers, you might like to share an SSH session with someone who is not in the same room. tmux is perfect for this for terminal sharing! Here are the steps: > [..] > Both of you will need to SSH to the machine using the same account. If you want, it is very easy to do view-only tmux sessions with no third-party tools required. That is, you start your tmux specifying a socket (…

Or you can execute a shell inside ytalk.

Re: SSH hacks – a little sanity for remote workers

#146

Post by Symbiote »

fulafel wrote: post #61
davb wrote: post #10

Earlier quoted context omitted.

And in your ~/.ssh/config that's the ProxyJump directive. Adding a proper configuration for the bastion/jump host and for the target host means you can just to "ssh target". In my case, I usually do "ssh target -t tmux -2 att" to attach to my tmux session, then when I detach it will close the SSH connection (and all of my tunnels).

Word of warning: using jump hosts shift your mindset towards building an internal network with lax security, the crunchy outside/soft tasty inside security antipattern. (Yes you don't intend it at the start, but the realities of your later evaluations of where to invest effort security-wise will leave the internal network to rot since you won't think of the scenarios of how it would be compromised)

Isn't that typically already the mindset, since most people set up networks with non-routable (10, 192.168 etc) IP addresses?

Re: SSH hacks – a little sanity for remote workers

#147

Post by Tyr42 »

mfontani wrote: post #141
Boulth wrote: post #137

Earlier quoted context omitted.

I think the proper solution would be 1) don't use forwarding unless necessary 2) setup touch-to-use on a Yubikey so even with your scenario the attacker couldn't just use the key (it requires touch to be used).

I've (admittedly, conceptual only) a couple problem with this approach I'd love to hear folks' thoughts about, with regards to "touch-to-use". 1. I still have a need to "for s in $list_of_servers; ssh -A $s '..'; done" How many times do I have to push the button? Is there a setting that allows that "push to allow" for a short while? Great, if so: 2) when I ssh into a system and touch the button to allow it, and the p…

If I ssh in two different tabs back to back, I still need to touch twice. So it's your case 1 that's not supported nicely. Rather than being insecure.

Re: SSH hacks – a little sanity for remote workers

#148

Post by enriquto »

tgb wrote: post #122

I often ssh then open a vim on the server. But it would make more sense to me if vim had support for open remote files via its own ssh connection instead. Does this exist (for vim or some other editors)? Then I could always use my local config and it would be easier to type on a bad connection.

> Does this exist (for vim or some other editors)?

It does:

        vim scp://server//path
Run

        :h netrw
inside vim to learn all about editing remote files.

Re: SSH hacks – a little sanity for remote workers

#149

Post by Boulth »

mfontani wrote: post #141
Boulth wrote: post #137

Earlier quoted context omitted.

I think the proper solution would be 1) don't use forwarding unless necessary 2) setup touch-to-use on a Yubikey so even with your scenario the attacker couldn't just use the key (it requires touch to be used).

I've (admittedly, conceptual only) a couple problem with this approach I'd love to hear folks' thoughts about, with regards to "touch-to-use". 1. I still have a need to "for s in $list_of_servers; ssh -A $s '..'; done" How many times do I have to push the button? Is there a setting that allows that "push to allow" for a short while? Great, if so: 2) when I ssh into a system and touch the button to allow it, and the p…

> Is there a setting that allows that "push to allow" for a short while?

Yes there is. In a newer firmware.

> 2) when I ssh into a system and touch the button to allow it, and the push allowed the use of they key for a short while, am I not in the same problem as before - as the system may be compromised and may be performing other operations I'm unawares of?

Yes but the window of opportunity for the attacker is smaller. Also: it's your setup that requires multiple key operations within short time interval, for some people touching every time is sufficient and most secure.

Re: SSH hacks – a little sanity for remote workers

#150

Post by [deleted] »

MaxBarraclough wrote: post #90
kazinator wrote: post #25

My favorite SSH trick is to have a machine at work SSH back to my home domain, and provide a tunnel back for Remote Desktop or what have you. Wee, no VPN to deal with. No lack of a VPN for remote access to deal with. https://cygwin.com/pipermail/cygwin/2020-April/244384.html

That's likely to be a firing offence, no? If I were running things I wouldn't want employees deliberately subverting my network's security measures in the name of their own convenience. If you have to spend time wrestling the VPN while you're on the clock, that's their own time being wasted.

[deleted]
Post reply on HN