If you fear being locked out you can also put iptables on time lock so that
for a short period of time every day you can have cron run a script that
alters and restarts iptables. During that window you can set it to say,
allow login from any ip. You still need a working account (I assume you
disabled root login in sshd) and password so it is still secure during that
window but allows you to log in if your IP changes.
On Mon, Aug 8, 2011 at 9:28 AM, keith smith <
klsmith2020@yahoo.com> wrote:
>
> 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 <herrold@owlriver.com>* wrote:
>
>
> From: R P Herrold <herrold@owlriver.com>
> Subject: Re: I've got a VPS, now what M's should I RTF?
> To: "Main PLUG discussion list" <plug-discuss@lists.plug.phoenix.az.us>
> 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
> herrold@owlriver.com <http://mc/compose?to=herrold@owlriver.com>
> My words are not deathless prose,
> but they are mine.
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us<http://mc/compose?to=PLUG-discuss@lists.plug.phoenix.az.us>
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)