ssh and hosts.deny

[WilliamWallace]

i have ssh working....but whenever i try to login to my own machine it refuses me...in my hosts.deny file i have this:
ALL:ALL

and in my hosts.allow file i have this:

in.sshd:ip of my machine
(of course my real ip is there..not "ip of my machine") lol

if i remove the entry from hosts.deny it works fine...how can i deny ssh logins from everyone but one ip address?

one more question...

when i try to use ssh to login to my machine it fails to authenticate and falls back to RSA....i generated keys for both host and users using 1024 bits....any ideas??

[ 13 June 2001: Message edited by: WilliamWallace ]

[Craig McPherson]

Is the SSH daemon really called "in.sshd" on your machine? On my Debian system, with OpenSSH, it's just "sshd". Check that: it could be your mistake.

how can i deny ssh logins from everyone but one ip address?


Why would you want to, really? If you're using password authentication, then I can understand why you might not want SSH open to the world (still, it's not much of a security concern if you have a strong password -- a dictionary attack over SSH would take forever), but if you're using RSA authentication, why would you even worry about blocking SSH from the rest of the world?

Please restate your last question about RSA authentication, I didn't really gr0k what you were asking.

[[GoRN]]

if the public doesn't need something don't give it to them.

why would you not want the world to access bind?

**** theres a exploit for bind!

you never know.

[Craig McPherson]

Originally posted by [GoRN]:
<STRONG>if the public doesn't need something don't give it to them.</STRONG>

This is known as "security through obscurity", which is a misnomer, because it's no security at all. I have NEVER relied on TCP wrappers for any form of security because I do not trust TCP wrappers. With TCP wrappers, the port still appears wide-open to the outside world, you're just blocking most of the world from getting fully in without being marginally creative.

What happens when you're at a friend's house and you realize you need to get a file off your server, badly? Oops -- blocked by TCP wrappers because you're on another IP.

**** theres a exploit for bind!

First of all... you do know that OpenSSH is produced by the OpenBSD people, right? I seriously doubt anybody's going to find a root exploit any time soon.

If you're concerned about dictionary attacks, disable password password authentication and use RSA/DSA only. Unless somebody breaks RSA itself (in which case our species will have more things to worry about than your SSH server, such as survival), nobody's gettin' in.

[WilliamWallace]

didnt know that a dictionary attack would take forever over ssh....and the daemon on my machine is called "sshd" but i was reading a maximum linux magazine article on ssh and it said to put
"in.sshd:ip address" in the hosts.allow file...so i dont need the "in" part? and i did change my mind about the open to the world part...i have done some reading since then and have decided RSA is secure enough for me to leave open.

thanks guys...

[Craig McPherson]

If the SSH daemon is "sshd" instead of "in.sshd", then "sshd" is what you should use. A lot of daemon programs, particularly ones intended mainly to be run from Inetd, start with "in" (in.telnetd, in.imapd), but that's just a naming convention.

If you have passwords disabled and are using only RSA, then for someone to break into the system by guessing keys would take longer than the universe is expected to exist. Surely by the time the universe cools to a lifeless cloud of expended energy, either you'll check your log files and notice the attack, or the attacker will die of old age. Of course, computers will get faster, but you're face for a few centuries with an average-sized key.

If you use a very, very large key, a perfect computer (a computer operating at the maximum efficiency allowed by Thermodynamics) would expend every single big of energy in the entire universe before guessing your key. That's not because of a limit of the computer, it's because of a limit of the universe.

As an encryption document I read recently stated: "For a computer to break a sufficiently large key within the lifetime of the universe, the computer must be made of something other than matter, operate in some domain other than time, or utilize something other than energy." Quantum computers would kill public-key encryption, but for now (and maybe forever) that's just science fiction.