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

SSH Kung Fu

blog.tjll.net

Post reply on HN
Print view View original

91–100 of 133 posts

Re: SSH Kung Fu

#91

Post by Piskvorrr »

moe wrote: post #73
Piskvorrr wrote: post #34

Earlier quoted context omitted.

If you must allow SSH root access, in 2014, you are doing something horribly wrong, and this will come back to bite you.

You are wrong, again. Passwordless root SSH is perfectly fine, which is why it is enabled by default. By people who have thought a little longer and harder about all this than you. (Sorry for the tone. Maladvice like yours on public forums is demonstrably harmful.)

No offense taken, I am all for a strong opinion (as opposed to a bland one trying not to offend anyone at all). I will re-examine my assumptions; any specifically relevant links you would recommend?

Re: SSH Kung Fu

#92

Post by drdaeman »

Sae5waip wrote: post #51
jimlei wrote: post #37

Earlier quoted context omitted.

Why not use the more common "no"?

Because then root login would be disabled entirely. With "without-password" SSH-key based login is still possible (and no, that's not much of a security risk).

Is it really much harder to leak a private key than a passphrase? (It's obviously harder, but not sure whenever a difference is significant.)

While one can't peek from behind your shoulder, if they got a keylogger on your machine, they could steal ~/.ssh/id_* files as well (and sniff their security passphrases too).

Re: SSH Kung Fu

#93

Post by mrlebowski »

I have a setup similar to this:

  laptop - user (userid: me)
  F - firewall (userid: me)
  A - machine 1 in colo (userid: colo)
  B - machine 2 in colo (userid: colo, machine I want to access)
  C - machine 2 in colo (userid: colo)
  .
  .
  100s of machines.
Trust (ssh password less login) is setup between me@laptop and me@F, and me@laptop and colo@A, and between all colo machine (A,B,C..). So colo@A can ssh colo@B w/o password.

I am able to log into colo@A via F w/o password as I copied the ssh key there manually. (path me@laptop -> colo@F -> colo@A)

QUESTION: Is it possible to ssh to other machines (B,C..) via A while assuming full identity of colo@A? (Path would be me@laptop -> colo@F -> colo@A -> colo@B/C/..) With my current config when I try to ssh to B it knows request is originating from 'laptop' and still asks me for password.

Re: SSH Kung Fu

#94

Post by ambrop7 »

About the "Lightweight Proxy" (ssh -D), if you want it to be transparent to the application (not require SOCKS support), you can use my tun2socks[1] program. This is useful if you can't or don't want to set up an SSH tunnel (which requires root permissions on the server). The linked page actually explains exactly this use case. It even works on Windows ;)

[1] https://code.google.com/p/badvpn/wiki/tun2socks

Re: SSH Kung Fu

#95

Post by Xylakant »

drdaeman wrote: post #92
Sae5waip wrote: post #51

Earlier quoted context omitted.

Because then root login would be disabled entirely. With "without-password" SSH-key based login is still possible (and no, that's not much of a security risk).

Is it really much harder to leak a private key than a passphrase? (It's obviously harder, but not sure whenever a difference is significant.) While one can't peek from behind your shoulder, if they got a keylogger on your machine, they could steal ~/.ssh/id_* files as well (and sniff their security passphrases too).

Brute-forcing a key is pretty much impossible and people - despite all advice - still use short and insecure passwords. Certainly a machine that does not root login at all is better than a machine with key-based root login, but a machine with key-based root login is better than password based root login. The perfect is the enemy of the good here.

Re: SSH Kung Fu

#96

Post by gatehouse »

mpapi wrote: post #74
patio11 wrote: post #13

A trick I learned recently: create .ssh/config File format: as many of the following blocks as you like Host $ALIAS You can now ssh to that server as that user by doing "ssh $ALIAS" on the command line, without needing to specify the port or user with the usual command line arguments, or necessarily spell out the entire host name.

A favorite .ssh/config feature of mine is pattern matching on hostnames with "?" and "*". So you can say something like: Host bos-?? HostName %h.mydomain.com IdentityFile ~/.ssh/my-boston-key Host nyc-?? HostName %h.mydomain2.com IdentityFile ~/.ssh/my-nyc-key and log in with e.g. "ssh bos-14".

Yeah, I use a similar thing for ec2:

    Host *.amazonaws.com
      User ec2-user
      IdentityFile ...
And then it is just

    ssh ec2-X-X-X-X.compute-1.amazonaws.com

Re: SSH Kung Fu

#97

Post by rickr »

mverwijs wrote: post #39
WestCoastJustin wrote: post #3

Earlier quoted context omitted.

There are many cases where you do not want, or cannot have a password protected ssh trust. For example, say you have a central nagios host monitoring a network, that nagios host needs to connect to remote machines to run interesting monitoring scripts (disk % full, raid controller query, mpio checks, etc), in these cases you do not want to have a password blocking the ssh trust. You will also find this type of thing…

No, in that case, you limit the commands that nagios is allowed to executed using this specific, passphrase-less key. In this case you would limit this ssh-key to only be able to execute the nagios monitoring scripts. Nothing else. You do this in ~/.ssh/config on the remote machine.

I believe you mean ~/.ssh/authorized_keys?

For anyone interested here's an SO question with an example: http://stackoverflow.com/questions/402615/how-to-restrict-ss...

Re: SSH Kung Fu

#98

Post by akerl_ »

bprieto wrote: post #58
akerl_ wrote: post #57

Earlier quoted context omitted.

Would you like to clarify how, from a security standpoint, the string "root" is worse than another user? Allowing root login can be a user-management headache in multi-user environments, but strong SSH security can exist for root just the same as for any other user.

Because a potential intruder is more probable to try "root" than "akerl_35" to get access. It's no big deal to login as any other user and then use sudo (if needed) or even su

If a potential intruder knowing what username to use helps them bruteforce your SSH, then the problem is with the entropy of your password, not your choice of username.

Re: SSH Kung Fu

#99

Post by Tyr42 »

mrlebowski wrote: post #93

I have a setup similar to this: laptop - user (userid: me) F - firewall (userid: me) A - machine 1 in colo (userid: colo) B - machine 2 in colo (userid: colo, machine I want to access) C - machine 2 in colo (userid: colo) . . 100s of machines. Trust (ssh password less login) is setup between me@laptop and me@F, and me@laptop and colo@A, and between all colo machine (A,B,C..). So colo@A can ssh colo@B w/o password. I…

I think this guy answered it https://news.ycombinator.com/item?id=7658742

ProxyCommand ssh ...

Re: SSH Kung Fu

#100

Post by michaelmior »

shabble wrote: post #77
michaelmior wrote: post #68

Earlier quoted context omitted.

I have had this problem, although fairly rarely. I have the following in my ~/.ssh/config: ControlPath /tmp/ssh_mux_%h_%p_%r This sets the path of the control file used to share the connection. If it ever hangs, I can just delete the file. But in practice I found this doesn't happen often and I appreciate the speed boost I get from connection sharing.

one minor annoyance is that there's a max limit to the ControlPath string (seemingly due to there being a max path length for Unix Sockets) which I've occasionally hit when connecting to hosts with very long hostnames (AWS default hostnames can sometimes hit it, IIRC). Also note that the docs recommend against using publicly accessible dirs such as /tmp/ for storing your mux sockets. I'm not sure of the exact threat…

Good point about the permission. I'm not doing this on a shared host anyway, so no else has access to that directory, but good to keep in mind.
Post reply on HN