| gabriel rosenkoetter on Tue, 25 Sep 2001 23:40:28 +0200 |
|
On Tue, Sep 25, 2001 at 09:08:15AM -0400, Mike Leone wrote:
> If you're a programmer, perhaps not. Not everyone is, you know. :-) Too many
> Linux users forget that point.
Also, I'm coming from the (Net)BSD world where all serious users are
programmers.
> No, I'm not missing the point. I just want it to do things it's (apparently)
> not designed to do. I don't want just anybody with a SSH-enabled telnet
> client to be able to type in my IP address, and immediately get a system
> login prompt. That's only 1 layer of security.
This is not a problem that public/private key authentication of
users is meant to solve. This is what limiting clients access based
on their *host*'s public key (which you can probably do with a
little hacking too) would be for, but not based on the user's key.
Likewise, this is a problem solved very well by a good stateful
firewall or, really, just by tcp_wrapping sshd. Note that a daemon
does NOT have to be launched from /etc/inetd.conf in order to be
tcp_wrapped... intelligent distros link all their daemons against
libwrap, and OpenSSH's configure script will let you do the same.
Any daemon linked against libwrap will honor access rules in
/etc/host.{allow,deny}.
If your problem is that you have users in public-access IP ranges,
then what you're looking for is IPSec or another VPN solution. ssh
is simply not designed to deal with this, and (imho) it shouldn't
be. This is a problem *separate* from login authentication and
session encryption.
> Ideally, I want SSH to only respond if there is a public key installed on
> the host ahead of time. And even then, I want it to ask for a valid host ID
> and password.
Swell, then fix it that way and submit your changes or pay somebody
to do so. :^>
Wishing something was true about a piece of software doesn't make it
so, but making it happen is supremely easy with open source
software.
> Yes, I realize the first part is more of an authorization/authentication
> mechanism better suited to a VPN, to allow access into the LAN at all.
Bingo. This is the right way to do what you want. But tcp_wrappers
will cut it for *just* want you want without much room to expand.
> Was just trying to figure out if I could do both ways - public key
> passphrase and ID/password - to 1 host at the same time. But it looks like
> it's not to be.
Well, not without a little elbow grease expenditure. But, as you
suggested and I elaborate above, there are already ways to do what
you want. (I think probably the tcp_wrappers solution would be most
to your liking and involve the least addition cruft in between the
world and your host.)
--
~ g r @ eclipsed.net
Attachment:
pgprc82KrQhgh.pgp
|
|