Billy Kim enscribed thusly:
> Is it safe to enable ssh logins on a machine that's
> going to sit on the internet?
> Is it really hackerproof?
Hackerproof is like drown-proof. Nothing is either and everything
is relative. Rootshell claimed that they got "hacked" through ssh. Well
that was true but horribly misleading. Someone obtained their root password
through other means and then proceeded to connect to their system using
ssh. Ok... Yes they got hacked and the hackers used ssh to do it. But
they had the root password and merely used ssh like you would use telnet
or rsh. No exploit involved.
Reason I stress this is that ssh is no more secure that the security
you provide your system and your passwords. If either is cracked, you can't
rely on ssh to save your butt.
To quote Bruce Schneier: "If you believe that cryptography is
going to solve your problem, you don't understand your problem and you
don't understand cryptography"
Using something like the term "hackerproof" leads me to feel you
fall into that category.
> Running some tests, I noticed that in order to log
> into a remote machine, even if I don't have any keys,
> it still
> lets me login with a password.
Correct. But the login process is encrypted.
> Is it then any safer that just using 'rsh' to login to
> machines?
Oh! Much! Your systems authenticate against each other using
public/private key systems and you can restrict that to only systems each
other knows. That prevents spoofing attacks and such that rsh/rcp/rlogin
are renowned for. Your entire session is encrypted so no one can sniff your
login id or password. You CAN set it up to require RSA authentication and
then it's "no-keys - no-connect - sorry charley.
> And when I have no keys or configuration files on my
> local machine and log into a remote machine using
> ssh, it the transmission still encrypted? (Yes, it
> does let me do this).
Yes, the connection is encrypted.
> How do I limit logins from only certain IP addresses?
> Do I just use it with tcp-wrappers?
Read the docs dude. In particular look at the following options for
/etc/sshd_config:
AllowHosts *.our.com friend.other.com
DenyHosts lowsecurity.theirs.com *.evil.org evil.org
I personally believe in "defense in depth". That's a principle of
layered defenses that turns the tables on crackers. Without defense in depth,
a defender has to be perfect and an attacker only needs to have one hole to
succeed. Defense in depth reverses that senario through layers of defenses,
alarms and traps. The attacker has to make his way through all of the
defenses, like the firewall rules, tcpwrappers, the config files, and the
authentication system; plus he has to avoid all of the alarms while he's
trying to figure his way past a defense; pluse he has to ignore the various
traps and lures set in his way to distract him.
Based on that, I would use the Linux firewalling code, plus Abacus
Port Sentry to monitor for port scans, plus the tcpwrapper code (which really
doesn't apply to daemons like ssh unless properly linked in) plus the ssh
config files. Do all of them and add a log monitor on top of that to scream
bloddy murder when someone trips over themselves trying to work past an
unexpected layer of defense.
> I'm debating whether to enable ssh logins on a machine
> that's not behind a firewall. Just plain sitting out
> there on the internet just waiting for someone to hack
> in.
Ssh is the only way to go (IMHO). I would set it up to restrict
it to RSA authentication only, plus add the firewall rules to further
restrict the connect access, plus add the Allow/Deny rules to sshd_config.
When it comes to defense, redundancy is the minimum.
> Any comments suggestions on making logins more secure?
> Thanks
Mike
--
Michael H. Warfield | (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (770) 925-8248 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
