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.
Use a scheme for choosing usernames that avoids common names like
"james" and avoid publishing usernames on web-sites, e-mail may differ
from the username.
This is somewhat unaviodable -- as I allow users to choose them.
Well, this is up to you, read the article and you'll see that the user
names tried apart from common system names are common English names. You
can decide to introduce a policy for new users.
It is often desirable to give users an e-mail like firstname.lastname as
it makes it easier for other people to remember.
Disable password based authentication and require ssh-keys if
possible, best if you can ensure both pasword and key based
This also assumes that people password their keys, otherwise it actually
*lessens* the security of a thing greatly. Most folks don't. I do wish
there was some standard for forcing applications to not save passwords
(other than OTP).
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.
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
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
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.
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?
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?
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.
Ph: +34.666334818 web: http://www.locolomo.org
X.509 Certificate: http://www.locolomo.org/crt/8D03551FFCE04F0C.crt
Key ID: 69:79:B8:2C:E3:8F:E7:BE:5D:C3:C3:B1:74:62:B8:3F:9F:1F:69:B9
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"