On Wed, 20 Sep 2006, Erik Norgaard wrote:
Dan Mahoney, System Admin wrote:
On Tue, 19 Sep 2006, Erik Norgaard wrote:
Along with some good advice. First of all: ssh is not a public service
like http or smtp where you need anyone to be able to connect. So don't
let them in the first place.
It is in this case. It's a web server that allows shell usage (and
encourages it, as I actually advocate the power that comes with a shell as
opposed to the primitive (and less secure) interface you may get with crap
utilities like cpanel, or FTP (where you're at the mercy of the featureset
of your particular app).
I think you misunderstood what I meant by public service, or maybe it wasn't
clear: By a public service I mean a service available for anyone, even
anonymously: You're not going to register the world to let people send mail
to your server, (while you may (recommended) require authentication to send
mail from your server).
Your ssh service should only be available to your users.
True enough, but so is/should pop3, and we're not having this problem
there. Nor is there even an option for publickey auth (even though it
uses PAM).
People can always manage access badly. Yes, you may not be sure of password
protection on the keys, but the intruder first needs to get a copy of the
key. If this is stored on a usb-stick the user carries with him, or only on
systems that require local authentication first, then I think you're better
off than password based ssh.
I think that people can better understand and manage a physical thing like a
usb-stick and use that as their key. If the capacity is small enough, it is
unlikely that people will use it for other stuff and accidentially delete the
key.
Yes, and then if/WHEN they do lose it, it's all the much MORE trouble to
regenerate it and walk them through the motions of re-uploading it.
You may still find sshd login denied entries in your log - so what? it was
denied! This is really only a problem if the traffics saturates your
connection, or your log files grow so much that you run out of diskspace.
It was denied, yes...but when it's denied for 200 different users from the
same IP, it only takes one user with a weak password (and as much as I like
keys, I personally prefer the passwords). I also find that since I have a
nice web-enabled SSH app (as part of usermin), the key becomes sorta
useless in that case.
As you read the article they had a password logger to see what passwords were
attempted, quite interesting very very weak passwords. You can easily weed
out bad password by running a cracker and forcing your users to change.
This is definitely "in the plan" -- password crackers eat CPU like
nobody's business so it would have to run "off site" but I've done this
before with crack. I may try John this time.
I would like to find an alternative to passwd that can enforce a password
policy, like min. 8 chars, upper AND lower case chars and numbers.
I've managed to very easily compile passwd against cracklib. Cracklib is
in ports and easy to build -- FreeBSD could use (but I haven't filed the
requests) a) an option in make.conf to prevent passwd from getting built
on a buildworld and b) the patched passwd/yppasswd tree in ports. If you
want a few easy ports to maintain, these could be it :)
The article also comments on moving ssh to a different port, but this
causes confusion and annoyance if you have many users and is non-standard.
Doing the other things works great, an ssh-key on a usb-keyring is great.
For anyone savvy, yes. I don't assume that level of savvy.
Well, then - can't you also assume that people can use keys and understand
that these should be protected by passwords?
No, my assumption for the sake of simplicity has been to tell people "use
this hostname for everything, and this ONE method of logging in should
work for everything".
Yes, some of my more savvy users CAN set up keys. But for someone who
wants the quick method to fix a few broken files, bad permissions, etc,
it' far easier to tell them "get putty, log in..., and then cd to your
homedir and type...".
I've been through this dance. "Get putty. Get puttygen. Now make a
keyfile with options you really don't understand. Now find
a way that, in the spirit of SSH you can upload that keyfile without using
your password since I was told to disallow it...now password protect your
key with something LONG and COMPLICATED when you can't even remember a
password that you were emailed, and trusted your FTP app to
remember...okay, now have that key with you everywhere you go (and you
can't cheat and upload it to someplace like your xdrive.com or other
service, you have to carry physical media. You understand all that?
Okay, now cd to your homedir and type...
Personally, I created a script for parsing the delegated files from the
different regional registries such as only to allow connection from EU
countries.
Sounds interesting, is it public?
http://www.daemonsecurity.com/pub/src/tools/cc-cidr.pl
Thanks.
The output is just a list of cidr addresses that can be used in tables with
packet filter. Or edit to create the output you want.
Thanks, will have a look.
-Dan
--
"We are basically...'Bandwidth Pimps'...Hrmmm...But that's cool man! You see these
gold chains? It's all good!"
-Ali Dhoon
03/03/2003, 7PM
--------Dan Mahoney--------
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
Site: http://www.gushi.org
---------------------------
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
