Traceroute Fun
-
I'm assuming the machine isn't physically accessible to an attacker, because if it is, they could just put a LiveCD in and plug in a keyboard and monitor and do whatever they want.
My regular user already has a secure password because I only need to type it for sudoing. I could set root to have that password, but that's extra work to achieve 0 added benefits. I could also run all my programs using a pen and paper, but it's not going to make anything better.
There is no "working locally" unless I majorly fuck up the OS and need to reinstall.
If you're saying that this:
- SSH in as
ben
su -c 'apt-get dist-upgrade'
- Type password
is better than this:
- SSH in as
ben
sudo apt-get dist-upgrade
- Type password
the only reason I can think of is if you have a broken o key.
- SSH in as
-
One of the nice things about sudo is the way it will suppress asking for a password until you've not used it for fifteen minutes within a given shell session; I get the same kind of convenience from su just by leaving my root terminal minimized but open until I've finished whatever I opened it for.
Having a terminal open is not as good; you're much more likely to type into the wrong terminal than to put
sudo
when not intending it.Also,
sudo
has a finer-grained elevation and logging model thansu
.
-
There is no "working locally" unless I majorly fuck up the OS and need to reinstall.
Oh, you're exclusively using SSH. Yeah, that's different.
-
you're much more likely to type into the wrong terminal than to put sudo when not intending it
Doesn't happen. My root terminal is a different colour.
-
sudo has a finer-grained elevation and logging model
Which is useful and worthwhile and good, unless you're just using it for blanket privilege escalation for no better reason than that Canonical has deemed it to be the official synonym for "please".
If you're saying that this:
- SSH in as ben
- su -c 'apt-get dist-upgrade'
- Type password
is better than this:
- SSH in as ben
- sudo apt-get dist-upgrade
- Type password
I'm saying that
- SSH in as root
- apt-get dist-upgrade
is better than both of those.
I'll go even further than that and say that leaving password-based ssh login enabled for root is also perfectly sound, as long as you don't use a stupid password. A workflow based on storing a high-entropy root password in your KeePass is resistant to a wider class of attacks than one that requires storing an ecdsa private key in your ~/.ssh folder.
-
I'll go even further than that and say that leaving password-based ssh login enabled for root is also perfectly sound, as long as you don't use a stupid password.
I disagree. Disable all password-based ssh login capability and require people to turn up with a key or not at all; it really does discourage unwanted scum. You might know that they can't get in, but they don't and they keep on trying. Better to get them to fuck off immediately.
-
require people to turn up with a key or not at all; it really does discourage unwanted scum.
Scum who keep hitting my port 22 don't know whether I have password-based login turned off or whether I don't.
You might know that they can't get in, but they don't and they keep on trying.
That's what fail2ban is for.
Putting your ssh server on an obscure high port also eliminates 99.99% of random probing. My home's network is configured that way.
-
the only reason I can think of is if you have a broken o key.
You can tab-complete
sudo
-
I'll go even further than that and say that leaving password-based ssh login enabled for root is also perfectly sound
yes. that's why i run several servers that drop you into a honeypot when you attempt to log in as
root
,avatar
,administrator
ortorvalds
they also run fake FTP sites with open uploads (they drop the upload to
/dev/null
, only recording the filename and length, then pipe/dev/urandom
at you when you attempt to download the file, and it resets internal state every half hour too)oh, you meant for day to day purposes, not for trolling scriptkiddies and bad hackers*
*bad as in terrible, not as a morality judgement.
-
you meant for day to day purposes, not for trolling scriptkiddies and bad hackers
It's a floor wax and a dessert topping!
-
That's what fail2ban is for.
http://i.imgur.com/vZyiaZw.gif
I wanted a different Krieger picture.Putting your ssh server on an obscure high port also eliminates 99.99% of random probing.
Until the info leaks. Plus you've got to pick something actually obscure and not just “obscure”.
-
-
Until the info leaks. Plus you've got to pick something actually obscure and not just “obscure”.
easy peasy!
make SSH listen to port
50000 + ((($CJD %7) * ($CJD %11)) % 1000)
where$CJD
is the current julian date for the year.
-
I really wouldn't recommend using ports over 32767; that's the space that is used by the OS for automatically-chosen client-side ports. While collisions don't happen very often, they look really strange when they occur (as “can't happen” problems suddenly decide to happen anyway).
-
-
I really wouldn't recommend using ports over 32767; that's the space that is used by the OS for automatically-chosen client-side ports.
I do it by creating a permanent NAT mapping from TCP port 35887 on my public IP address to port 22 of an ssh server in my LAN. I've never seen it fail; the NAT subsystem seems pretty competent at avoiding port allocation collisions.
-
I really wouldn't recommend using ports over 32767
s/50000/20000/
then.point is to have thhe port change "semirandomly" daily
bonus points for having the entire port range respond to ssh connections with a valid "authentication failed" response
-
bonus points for having the entire port range respond to ssh connections with a valid "authentication failed" response
-
point is to have thhe port change "semirandomly" daily
I've actually stuck with the same randomly chosen high-numbered port for the last five years, and there are still not enough probes in my syslog to warrant installing fail2ban.
-
@accalia said:
point is to have thhe port change "semirandomly" daily
I've actually stuck with the same randomly chosen high-numbered port for the last five years, and there are still not enough probes in my syslog to warrant installing fail2ban.
depends on your level of paranoia i guess.
-
I think I have enough paranoia.
Every now and then I
zgrep fail /var/log/auth*
on my publicly accessible ssh server boxes, and I have actually never seen a failed ssh login due to anything other than my own accaliafingers.
-
-
what you did there
Typing a 14 letter made-up word and having it come out right first time? Yeah, I was pretty pleased with that.
-
Until the info leaks. Plus you've got to pick something actually obscure and not just “obscure”.
Ah - should I be moving sshd off port 8022 then?...
-
-
accalia-
(prefix)
Added to noun or verb to denote an action or action performed by object has been accaliaed.
-
This isn't the discopaedia.
-
I don't really want to add it in discopaedia either.
-
I don't really want to add it in discopaedia either.
Good, because it's not a Discourse-ism! Thanks for maintaining civility!