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

61–70 of 133 posts

Re: SSH Kung Fu

#61

Post by moe »

Piskvorrr wrote: post #18
smtddr wrote: post #15

Earlier quoted context omitted.

For me I just don't like seeing /var/log/auth.log being filled with 100s of lines of: Failed password for root2 from 82.192.86.44 port 44990 ssh2 Failed password for admin from 82.192.86.44 port 44990 ssh2 Failed password for sysdb from 82.192.86.44 port 44990 ssh2 Failed password for scott from 82.192.86.44 port 44990 ssh2 (Yes, that IP has scanned my machine before)

And that's exactly what denyhosts is for. You'll see this line a few initial times, then the banhammer springs into action. (It's fully configurable - the number of failed attempts, the length of the autoban, etc.)

Unfortunately one attempt is enough when there's a pre-auth vulnerability. Your ban-hammer doesn't help you there.

Re: SSH Kung Fu

#62

Post by Spooky23 »

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". Blocking SSH access is not required meet that compliance requirement.

In our case, our library actually doesn't filter, it's left to the discretion of the librarians. And there is a time limit for access.

Re: SSH Kung Fu

#63

Post by supergauntlet »

pwg wrote: post #52
Piskvorrr wrote: post #18

Earlier quoted context omitted.

And that's exactly what denyhosts is for. You'll see this line a few initial times, then the banhammer springs into action. (It's fully configurable - the number of failed attempts, the length of the autoban, etc.)

There is also ssh-faker: http://www.pkts.ca/ssh-faker.shtml Which would prevent even that first password failure attempt from occurring.

Sending a password over telnet seems like a bad idea..

Re: SSH Kung Fu

#64

Post by bryanlarsen »

Another recommendation: start an SSH server on port 443 on a server somewhere. Then if you're stuck somewhere on an untrusted network, one that blocks most outgoing ports or one that throttles non-HTTP ports, you can use SSH for tunneling and/or setting up a quick SOCKS proxy to get yourself encrypted, unblocked, full speed internet access.

Re: SSH Kung Fu

#65

Post by moe »

Piskvorrr wrote: post #11
Morgawr wrote: post #9

I just learned about remote file editing with vim and scp thanks to this article, it's the only thing I didn't know about and... wow, it's amazing. This will make my life much easier every time I have to remotely edit some config files on my servers. As for the rest of the article, really nice stuff. Nice tricks for ssh newbies. I wish he also talked about setting up a nonce system with ssh or move sshd to a non-defa…

Moving ssh port is, IMNSHO, a stopgap measure; you should have exhausted all the other options (e.g. no passwords, no root login, denyhosts/fail2ban etc.) before this even crosses your mind. In other words, the inconvenience this brings is not adequate to the infinitesimal increase in security.

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.

Re: SSH Kung Fu

#66

Post by michaelmior »

hf wrote: post #20
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.

What is more, you can specify an abstraction for the tedious double-ssh where you first connect to some internet-facing host in order to gain access to an internal machine: Host $ALIAS User $USER HostName $INTERNAL ProxyCommand ssh $USER2@$PUBLIC -W %h:%p Now laptop> ssh jim@public.example.com public> ssh dev@myworkstation becomes laptop> ssh work (I just realized that this slightly confused article seems to accompli…

I use autossh[1] to keep a tunnel open in the background to $PUBLIC which lets me connect faster to $INTERNAL.

[1] http://www.harding.motd.ca/autossh/

Re: SSH Kung Fu

#67

Post by JoeAltmaier »

moe wrote: post #65
Piskvorrr wrote: post #11

Earlier quoted context omitted.

Moving ssh port is, IMNSHO, a stopgap measure; you should have exhausted all the other options (e.g. no passwords, no root login, denyhosts/fail2ban etc.) before this even crosses your mind. In other words, the inconvenience this brings is not adequate to the infinitesimal increase in security.

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.

Re: SSH Kung Fu

#68

Post by michaelmior »

XorNot wrote: post #8
terhechte wrote: post #7

> Sharing Connections I've tried this before, and what effectively always happened (to me) is that as soon as I started copying a file, I couldn't continue working in Vim anymore until the file was done transmitting because the copying would eat all the bandwidth. There may be a flag or setting around this, but I've never found it. When I open two connections, it is usually fine.

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.

Re: SSH Kung Fu

#69

Post by michaelmior »

Sae5waip wrote: post #53
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.

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

Why do you need root access for scp? Just scp the file as a regular user and then use sudo to copy it into place.

Re: SSH Kung Fu

#70

Post by michaelmior »

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.

This is assuming that someone is specifically targeting your machine. In which case yes, changing the port number probably won't do much. But if someone is just hammering random servers on port 22, changing the port number is much more likely to be effective.
Post reply on HN