If you want to secure SSH you can us IPTables to limit access to the IP's of your choosing. As long as your IP does not change you will be good to go.
------------------------ Keith Smith --- On Mon, 8/8/11, R P Herrold <[email protected]> wrote: From: R P Herrold <[email protected]> Subject: Re: I've got a VPS, now what M's should I RTF? To: "Main PLUG discussion list" <[email protected]> Date: Monday, August 8, 2011, 12:52 AM On Sun, 7 Aug 2011, Ed wrote: > what Russ said +1 > transition sshd to listening on a high/non-standard port +1 I disagree here, but this is a matter of taste as there are valid arguments on each side -- the utility of a mere port change alone, without a barrier of 'port knocking', is trivially defeated by nmap and friends and at that point, we are better back in the realm of wrappers and iptables, per my outline. But this is just IMHO +1 The suggestion in the thread of fail2ban on ssh, as such is in my personal automated scripted hardening for every instance I deploy at pmman http://orcorc.blogspot.com/2010_12_01_archive.html > AIDE (or tripwire or samhain) done from a remote system +1 > http://www.deer-run.com/~hal/sysadmin/FIA-via-SSH.html tripwire does not cope with modern library pre-linking well; aide for RH derived family systems; remote verification through ssh, sadly, cannot be trusted, because there is a working exploit out there that replaces the sshd with a poisoned variant that hides such damage, and sniffs passwords (as with sudo) To be certain, one has to be mounting an image to check RO, and non-hot, and checking from a checker not inside the running system; PMMan permits this natively for post-exploit forensics, and we've used it in post-compromise analysis. The topic of the _possible_ strneghts of systems, and their vulnerability to attacks from 'outside' the system, are well-covered in 'Godel, Escher, and Bach' -- If you have NOT taken a month to read it slowly, you ** need to ** ... As such, I hold, and need to do a more careful treatment of the thesis that when one has to set up a second end account on a box, GAINING rights is not viable any more, b/c such sniffers, and the possibility of chaned 'leap-frog' attacks, and on account of the human tendancy to re-use passwords or predictable variants [the separete Fedora and Red Hat compromises were probably of this class of chained compromise type: http://www.owlriver.com/projects/packaging/#compromises , #11 and 12] So: no more 'sudo up'; and only '/bin/su -', or keyed 'ssh -l lesser_account localhost' when one needs X forwarding, down in rights I run a different, complex, machine generated, and sadly, non-memorizable password for every new site, and have a well-protected master store http://orcorc.blogspot.com/2010/07/line-noise-and-random-numbers.html The generation script has grown a bit since I wrote that post, to handle all the site variations as to what the remote site accept (the 'password complexity checking' algorithms out there of course conflict in mutually incompatible ways, and so I extend the generator to handle new prejudices of a given site when I hit them) [herrold@bronson ~]$ gen-pw.sh -h Usage: gen-pw.sh [-a] [-h] (length) -a limits to alphanumerics (default) -l limits to letters -m is mixed alphanumerics and specials -n is only numerals -x is only hexadecimal digits (length) is the optional maximum length ... length defaults to 14 ... last option dominates [herrold@bronson ~]$ for i in `seq 1 5 ` ; do gen-pw.sh -a ; gen-pw.sh -l ; gen- pw.sh -m ; gen-pw.sh -n; gen-pw.sh -x ; done c4128084NHilP6W5 BBeBoPkicmfLokJP g!U60g51gEjG][]J 5624307050226052 aa5851ae41eb59e0b kTR062L5188iL63E FgFcLiggHNdPiBgg N!#W{NN852pO*@*L 3025344532055200 b85dc0a13df0d1f80 JYT1T1W4WEYgI86W aHiJaLcgeHmCemHc J!c498*iE9mP)[)g 3831315851260112 82f882866eef1deef LR81P520RPooH4Y2 LFeFDLeLHeoGPeDJ k!ia9T6R6TdP#~#i ... ... looks like I have a logic error in the 'truncation to size' algorithm for hex passwords. As long as I am in there reworking that part of the code, I'll add alternation between upper and lower hex digits in the output to get a 'bigger' pool of entropy going, for the (probably rare) case of a remote algo that does not force all hex to one case before hashing it. BRB This works: [ "x${HEX}" = "xy" ] && { [ "x${DEBUG}" = "xy" ] && echo -n "HEX: " echo -n "${SNIPX23}${SNIPX24}${DECK}${HEX3}${HEX4}${SNIPX25}${SNIPX26}$ cut -c 1-4 | tr 'abcdef' 'ABCDEF' | tr -d '\r\n' echo "${SNIPX23}${SNIPX24}${DECK}${HEX3}${HEX4}${SNIPX25}${SNIPX26}${SN cut -c 5- } $ for i in `seq 1 5 `; do gen-pw.sh -a ; gen-pw.sh -x ; done J73D8k65UBYkG7TY ACC7051b7ffe38f7 oW4k6F8L2U8kH7W6 0E49fbcb73eb17e3 aE97c46654YlC4E7 CEF7646cdea633ab J47745c75T7iA050 A988276799a867ab o819Y805iD1cK237 A7BA944770167b18 [herrold@centos-5 bin]$ ci gen-pw.sh RCS/gen-pw.sh,v <-- gen-pw.sh new revision: 1.5; previous revision: 1.4 enter log message, terminated with single '.' or end of file: >> fix hex bug as to length, add UC and lc digits >> done [herrold@centos-5 bin]$ co -l gen-pw.sh RCS/gen-pw.sh,v --> gen-pw.sh revision 1.5 (locked) done [herrold@centos-5 bin]$ -- Russ herrold I'll prolly work this up into a couple of blog posts, so I'll hang an explicit notice as to Copyright here -- end ================================== .-- -... ---.. ... -.- -.-- Copyright (C) 2011 R P Herrold [email protected] My words are not deathless prose, but they are mine. --------------------------------------------------- PLUG-discuss mailing list - [email protected] To subscribe, unsubscribe, or to change your mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
--------------------------------------------------- PLUG-discuss mailing list - [email protected] To subscribe, unsubscribe, or to change your mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
