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

131–140 of 230 posts

Re: SSH hacks – a little sanity for remote workers

#131

Post by mercora »

axegon_ wrote: post #60

A few I can't live without off the top of my head: * "-D" for ssh tunneling. * "-L" for forwarding all traffic on a specific port. * sshfs - mount small directories over ssh on your local machine (works with big ones but way too slow, for big ones I go rsync).

also:

* "-R" for reverse forwarding on a specific address.

That is, you can connect from the remote host to your local network. I used to do this to make my system at home accessible on my workstation in the office :) if you don't specify the address to forward to you will get a SOCKS proxy on the port specified that tunnels connections to your local network.

It is also possible to forward non local ports but ports on machines accessible to the side that is forwarding too.

Re: SSH hacks – a little sanity for remote workers

#132

Post by lucb1e »

heavyset_go wrote: post #17

Port tunneling, X forwarding, keys + agents, sshuttle and byobu all make SSH a good solution for getting stuff done.

It would be nice if you could include at least one sentence about these product names to give an idea of what they do. For other readers:

sshuttle:

> Transparent proxy server that works as a poor man's VPN. Forwards over ssh. Doesn't require admin. Works with Linux and MacOS. Supports DNS tunneling.

> Forward all traffic:

> sshuttle -r username@sshserver 0.0.0.0/0

byobu:

> Byobu is an enhancement for the GNU Screen terminal multiplexer or tmux [...] that can be used to provide on-screen notification or status, and tabbed multi-window management. It is intended to improve terminal sessions when users connect to remote servers.

Re: SSH hacks – a little sanity for remote workers

#133

Post by mfontani »

riedel wrote: post #117
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…

But if you use agent forwarding with other keys loaded into the agent, how does hat help?

I don't. Each agent gets one key, and that key alone. That's what helps.

https://github.com/ccontavalli/ssh-ident is what I use to manage those agents - one agent per key.

Re: SSH hacks – a little sanity for remote workers

#134

Post by orbitingpluto »

mercora wrote: post #125
s_gourichon wrote: post #83

Earlier quoted context omitted.

> My closest coffee shop would allow people to access Wi-Fi only if you gave them full access to your Facebook account. What the???

I've seen this on Ubiquity hardware as an option too. Apparently it requires you to "check-in" via facebook to use it, whatever that means exactly. There is also an option to login via facebook without this though.

This was awhile back and was particularly nasty. No token, no check-ins, it was an unapologetic man-in-the-middle login prompt.

Terms of service had wording that made mining all data in your Facebook account sound like the intent.

Re: SSH hacks – a little sanity for remote workers

#135

Post by jenscow »

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.

Re: SSH hacks – a little sanity for remote workers

#136

Post by Tistel »

switch007 wrote: post #126
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.

Emacs supports e.g. /ssh:my.server.net:/path (with host name completion too e.g. /ssh:my. )

emacs is nice too in that if you are using tramp mode (/ssh:blah) to open a remote file you can create a remote eshell too. you can do diffs and merges between remote machines also. in the pre container/k8s days i worked at a place that did horizontal load balancing between 20ish remote VMs. the ability to have many eshell tiled on screen was so helpful. i also had some elisp that took advantage of tramp mode to very crudely do VM orchestration across the 20. i will shut up now because i don’t want to be that emacs guy.

Re: SSH hacks – a little sanity for remote workers

#137

Post by Boulth »

mfontani wrote: post #111
snowwrestler wrote: post #84

Earlier quoted context omitted.

I use a config file for all my regular SSH connections as well. But I stopped using more than one key when I could not think of a threat model that it addressed. If the bad guys get a copy of my public key off one remote server, they can't use it to access any other remote server. They would need the private key, which is on my laptop. And if the bad guys get my laptop, then they get all my keys; having separate priv…

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

Re: SSH hacks – a little sanity for remote workers

#138

Post by dredmorbius »

lucb1e wrote: post #120
Cthulhu_ wrote: post #104

Earlier quoted context omitted.

It would put your password into your `~/.bash_history` and show up on the screen though; using a commandline argument to pass passwords is inherently unsafe. Sure you could have a secure system that only you use, but the people behind ssh cannot make that assumption. Removing the risk entirely is better than trusting the users. I'm sure there's a shell trick you could use to pass a password on the prompt anyway. For…

> It would put your password into your `~/.bash_history` I'm fine typing (or pasting) my password in an interactive prompt when I'm interactively using it; that's not the problem. What I would like a --password option for is when I'm not interactively using it, like from a script. It'll still show up in the process list (ssh could overwrite it but there are some µs where it's there) but my laptop is single-user so th…

It's quite likely that what you want in this case is to use SSH forced commands with sshkey auth and a remote account exclusively dedicated to serving this one request.

https://binblog.info/2008/10/20/openssh-going-flexible-with-...

Re: SSH hacks – a little sanity for remote workers

#140

Post by siver_john »

segfaultbuserr wrote: post #4

> What are your favorite SSH tips & tricks? $ ssh -J user1@host1 user_final@host_final or $ ssh -J user1@host1,user2@host2 user_final@host_final Not many people know it, you don't need to launch a SSH within a SSH session - SSH has built-in support of using one SSH server as a proxy to another SSH server. Useful for hacking servers accessing servers behind a firewall, or using your own server as a proxy to bypass a b…

Thank you for being worth the whole reason I clicked on this link. I could have used this forever ago when I was trying to figure out how to do this to bypass a firewall (now I don't need to but this will be useful in the future).
Post reply on HN