51–60 of 133 posts
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.
Why not use the more common "no"?
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.)
Which would prevent even that first password failure attempt from occurring.
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.
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".
http://www.amazon.com/SSH-Mastery-OpenSSH-PuTTY-Tunnels-eboo...
Earlier quoted context omitted.
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…
And if your router keeps dropping idle connections, add something like: ServerAliveInterval 240 ServerAliveCountMax 5
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".
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 general, having proper deployment, log collection and config management tools in place tends to mean you rarely need to scp files around at all - and the cases when you do, you can work around this by scping them to some other dir, and moving them locally with a sudo command.
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.
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.
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.
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.
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…
Earlier quoted context omitted.
until one of the millions of other compromised IPs begins hammering your machine minutes later..
That's the whole point. The ban-hammer in this case is automatic and will ban that one too after five attempts or whatever.