I am a lazy linux user and often use very short passwords for my main user account(s).
Now, hopefully my firewall takes care of blocking most unsolicited access attempts and the OS (as far as it goes) deal with exploit attacks.
Anyway, I do wish to have remote ssh access for when I am out and about. So what do I do?
I disable all users for ssh, including my main account and rather allow one single ssh user with a super-password.
Is this a good practice? why{,not}?
So here is the question...given this is a benevolent action, I would like to further disable all commands for this ssh user (ls, cd, etc) except one > sudo or su.
(the root account of course also has an amazingly long and quirky quantum-inferred alien password).
Of course, all this would do is buy some time (would need to guess/know about other the username with the lazy password, and then do another rainbow/bruteforce attack), however this would or could hopefully make me notice someone is being a bad girl.
Someone could say.. please use a mega password for allaccounts but as I said... I run so many sudo commands etc over the course of an admin day.. I am lazy...
ANy other ideas or practical tips or ways of diminishing the attack surface for linux machines (servers/clients) is appreciated.
EDIT: Oh ye... the short password scheme here, does ignore physical login attacks... this is purely over-the-network related.
EDIT2: perhaps a bash script which listens to stdin for username... which then runs su $1 and do usermod -s script.sh ssh_user ? or does that introduce other dangers?
For those who might be interested.. I wrote a simple non-verbose script which expects a special handshake before running su my_lazy_user and pointed it as the login shell.
Seems ok enough for me. If this leads to other attack methods.. please shout out.
(I am content with the error handling of the script, which, as long as no heap, stack or buffer attacks are enabled, should be fine).
Thanks.
.bashrc
or something, better not do that. You can just Ctrl-C your way into freedom as an attacker. Changing the login shell should be fine though, see my answer.