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

71–80 of 133 posts

Re: SSH Kung Fu

#71

Post by moe »

JoeAltmaier wrote: post #67
moe wrote: post #65

Earlier quoted context omitted.

In other words, the inconvenience this brings is not adequate to the infinitesimal increase in security. You are wrong. Please refrain from giving security advice. Changing or filtering the SSH port prevents your host from being compromised by automated netrange sweeps in the event of a pre-auth ssh vulnerability. For this reason changing the SSH port is considered best practice.

Since port numbers are a very tiny space, that would amount to an infinitesimal increase in security, right? Essentially, 'hiding' the port is 'security through obscurity' which is a thoroughly discredited idea.

You misunderstand.

Changing the port does nothing against targeted attacks and it's not about 'hiding' anything. The purpose is to take your host out of the scope of automatic scans which almost exclusively focus on the most common ports (22, 2222, 22222 ...).

Re: SSH Kung Fu

#72

Post by VLM »

Spooky23 wrote: post #62
luxpir wrote: post #33

One problem I have with SSH is DPI. Deep Packet Inspection seems to be behind the SSH block in place at a local library I work at. SSH out in any form just isn't possible there, even via a browser-based console (such as that used by Digital Ocean, for example). There doesn't seem to be a suitable solution to get around it offered anywhere. My own fix was to use 3G to do the SSH work via a tethered phone and to use th…

I'd recommend complaining to the library trustees about it. There's no reason they should be refusing your traffic, and they are probably only causing a problem because some overzealous consultant cranked up the setting too high. In my city, the compliance requirement that must be met is to have a policy to address "obscene, indecent, violent, or otherwise inappropriate for viewing in the library environment". Blocki…

"Blocking SSH access is not required meet that compliance requirement."

Read up about SSH VPNs. Probably some kid set up a proxy accessed over SSH port forwarding, to access some pr0n site, got caught, and next thing you know, no SSH allowed anymore. If they were really smart they'd allow it but rate limit it to 2400 bit/s, which is fairly fast for console work but not so great for downloading animated pr0n gifs.

Whats weird is librarians typically are pretty hard core against censorship. The same place thats willing to go to court to keep "to kill a mockingbird" or "huckleberry finn" on the shelves, will simultaneously spare no expense to block adults from accessing a breast cancer awareness site. A strange bunch, librarians.

Re: SSH Kung Fu

#73

Post by moe »

Piskvorrr wrote: post #34
hf wrote: post #32

While we are busy dispensing wisdom: Do use PermitRootLogin without-password instead of 'yes' in /etc/ssh/sshd_config if you absolutely must have ssh root access.

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

Re: SSH Kung Fu

#74

Post by mpapi »

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

Re: SSH Kung Fu

#75

Post by shabble »

jfindley wrote: post #56
Sae5waip wrote: post #53

Earlier quoted context omitted.

Did you ever stop and think about this or are you just repeating something you read on "Hacker""news"? Getting by /without/ direct SSH root access is often impractical (think about scp), and without-password is a secure way to have it. Also, the more people know about "without-password", the less people will set PermitRootLogin to "yes".

Requiring admins to ssh to a different, unique-to-them, user, and use sudo from there for any operations requiring root is much better. It's far easier to audit what's been done to the server, which is important not just for compliance but also for figuring out why something's broken suddenly. It also means that you get to have your own shell history, your own shell settings, your own vim settings, etc, etc. In gener…

...which is fine up until someone forgets to use visudo and buggers up the sudoers file so nobody can get back in to fix it.

A user login followed by su to root is a valid alternative, but I wouldn't have a problem with allowing key-only root access via sshd either.

You'd want the root key/password to be very tightly controlled for the reasons you mention, but having it set is (IMO) a worthwhile backup plan for when things go wrong.

Re: SSH Kung Fu

#76

Post by shabble »

magnetikonline wrote: post #6

Some good tips here - I like Controlmaster/Controlpath. Note that on the tip of ~/.ssh/known_hosts providing ssh auto completion, adding SSH server config to ~/.ssh/config will also enable auto completion.

It's great for tab-completion of remote paths for scp & friends.

It does have a few quirks though. One that I've noticed is (IIRC) that closing a shared session isn't sufficient to pick up new groups membership when you reconnect. You actually need to kill the master connection as well[0].

The syntax for shutting down a master connection is a bit clunky as well:

    ssh -O stop -S ~/.ssh/mux/socketname hostname
I've been meaning to make a little script or 2 that finds the current mux sockets and tests them with -O check and give you a list of simple IDs you can 'ssh-mux-kill $id' or something. In fact, it'd probably be a nice use for percol[1]

[0] There might be other ways of refreshing group memberships, but I don't know of any.

[1] https://github.com/mooz/percol

Re: SSH Kung Fu

#77

Post by shabble »

michaelmior wrote: post #68
XorNot wrote: post #8

Earlier quoted context omitted.

I've found it just tends to have the primary connection die, and never tries to reconnect. ServerKeepAlives or what have you don't seem to help either - the link goes dead, and I won't be able to connect any other sessions because SSH will just keep on routing them into the control master.

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 (maybe just info leakage about what hosts you're connected to, since the socket permissions themselves are strict), but I use ~/.ssh/mux/ for mine.

Re: SSH Kung Fu

#78

Post by vinceguidry »

Is sshfs a serious replacement for nfs? I've got a Buffalo Nas at home that I use Samba for, but Samba is too slow to watch hi-def videos over. NFS seems to be a pain in the neck to get working on that particular device, and I hate using it on a laptop. I guess I should probably just try it, but I can't see SSHFS as being any faster than Samba.

Re: SSH Kung Fu

#79

Post by stephen_g »

vinceguidry wrote: post #78

Is sshfs a serious replacement for nfs? I've got a Buffalo Nas at home that I use Samba for, but Samba is too slow to watch hi-def videos over. NFS seems to be a pain in the neck to get working on that particular device, and I hate using it on a laptop. I guess I should probably just try it, but I can't see SSHFS as being any faster than Samba.

It'll probably be less performant than NFS, but is a really great and simple way for mounting remote volumes securely across the internet without having to worry about VPNs or any extra authentication or anything.

Re: SSH Kung Fu

#80

Post by Spooky23 »

VLM wrote: post #72
Spooky23 wrote: post #62

Earlier quoted context omitted.

I'd recommend complaining to the library trustees about it. There's no reason they should be refusing your traffic, and they are probably only causing a problem because some overzealous consultant cranked up the setting too high. In my city, the compliance requirement that must be met is to have a policy to address "obscene, indecent, violent, or otherwise inappropriate for viewing in the library environment". Blocki…

"Blocking SSH access is not required meet that compliance requirement." Read up about SSH VPNs. Probably some kid set up a proxy accessed over SSH port forwarding, to access some pr0n site, got caught, and next thing you know, no SSH allowed anymore. If they were really smart they'd allow it but rate limit it to 2400 bit/s, which is fairly fast for console work but not so great for downloading animated pr0n gifs. Wha…

The library has an obligation to make a good faith effort to meet whatever compliance requirements that they are faced with. That's it. It isn't a bank or military installation.

If the original poster brings in an air card, and starts watching porn with the volume cranked up, the library doesn't have a right or obligation to jam the cellular network. They do whatever their policy calls for (usually ask the guy to leave).

Librarians are very rarely the problem -- the trustees or other governing body usually is. Make a fuss and in most cases the problems will go away. YMMV depending on the community, of course.

Post reply on HN