hosts.allow workaround

[John Payne_2]

We are running ssh w/ tcp wrappers. We have some users who want to connect from home really badly using ssh, but they are on dsl lines, and do not have a static ip or a static machine name. Does anyone know a good/easy way to let them in when we are using hosts.allow/hosts.deny in our environment? Thanks
John

[Shannon Petry]

Usually they should be getting IP's on the same Class B or C. If so, just add their class C(preferrably) to the hosts.allow file. As long as you are forcing them to authenticate, then you should be okay with this.

Regards,
Shannon

[John Payne_2]

Yes, but we are hoping to not open the hosts.allow to their entire ISP. That is where the concern lies...

[Chris Calabrese]

I definitely would not do this given the number of security issues that have popped up in SSH over the years. But, if you are going to do this, use OpenSSH (which has a better track record than other variants) and use only the 2.0 protocol (not 1.0 or 1.5).

A better idea is to use IPsec with strong authentication (X.509 certs with passphrases, for example).

[John Payne_2]

This is not our only security tool, just a small piece of it. (Partly to get rid of plaintext passwords, etc.) We also have a heterogenious environment here, and have to use tools that can span across to AIX, Solaris, Linux. (Unfortunately for me...)

[Bill Thorsteinson]

You only need to open ssh for their ISP if they truely
don't have effectively static addresses or names.
The ADSL server I work with has a static name.
My home network effectively has a static IP. Doesn't
change unless I change my NIC. It depends on
the ISPs implementation.

Try a hosts.allow entry like
ssh : 24.24. 142.222.221.
using the appropriate subnets.

[Chris Calabrese]

Re. ssh vs. ipsec, I agree that ssh definitely has its place. We use it quite extensively here. I just wouldn't use it directly from the Internet. SSH tunneled in IPsec is your best bet. Yes, this is redundant encryption. But the IPsec would likely terminate at a firewall or VPN appliance on the corporate network, so you still need something that covers from there to the end system.

[Wodisch]

Hello John,

why don't you tell your users to make use of the tool
"xauth" - that is just what it is good for?

HTH,
Wodisch

[Dayanand Naik]

Hi John Payne,

This is not any answer to your qts, as you have mention that u have configured tcp wrappers on Hp-UX, can you guide me in doing so. As 'm not able to get it working.

when i do it using :
make REAL_DAEMON_DIR=/bkp/tcpw hpux
it throws the following errors :

(Bundled) cc: warning 480: The -O option is available only with the C/ANSI C product; ignored.
/usr/ccs/bin/ld: (Warning) At least one PA 2.0 object file (tcpd.o) was detected. The linked output may not run on a PA 1.x system.
/usr/ccs/bin/ld: Unsatisfied symbols:
yp_get_default_domain (code)
*** Error exit code 1
Stop.
*** Error exit code 1
Stop.

Regards,
Dayanand Naik.

[John Payne_2]

Here is the fix:

HP-UX: if you have trouble building TCP Wrapper, and the compilation
fails with: /usr/ccs/bin/ld: Unsatisfied symbols: yp_get_default_domain
(code), edit the Makefile and add -DUSE_GETDOMAIN to the definition
of the BUGS macro.

This is from Wietse's FAQ. I have seen the problem and this fixes the problem and lets you compile.

[John Payne_2]

Wodisch, (or anyone else)
Can you elaborate as to how to use xauth? We try not to use CDE or it's buddies here as much as we can..

Thanks

John