cancel
Showing results for 
Search instead for 
Did you mean: 

inet.sec with SSH

SOLVED
Go to solution
Fernando Boza
Regular Advisor

inet.sec with SSH

I have security configured in /var/adm/inetd.sec

telnet allow 172.IP.RED.* 172.IP.IP.IP

ftp allow 172.IP.RED.* 172.IP.IP.IP


I will replace Telnet for SSH...
as I can maintain this security restriction?
7 REPLIES
rick jones
Honored Contributor

Re: inet.sec with SSH

I have never had to set them up myself, but either through something specific to the sshd 's config file(s) (start at man sshd) or perhaps via an ipfilter setup.
there is no rest for the wicked yet the virtuous have no pillows
Matti_Kurkela
Honored Contributor
Solution

Re: inet.sec with SSH

Yes, the sshd_config file (/opt/ssh/etc/sshd_config, if you use the free HP Secure Shell package from software.hp.com) allows such restrictions

However, the syntax is different. I believe your restriction would be written something like this:

AllowUsers *@172.IP.RED.* *@172.IP.IP.IP

(disclaimer: not tested)

As far as I understand, sshd's connection rejection works in a sneaky way: the user is allowed to enter a password, but even a valid password will always fail if the user is not on the allowed list. This is done to minimize the number of clues given to a potential intruder.

sshd will always write the reason for rejecting a login attempt to the syslog: when troubleshooting SSH connection problems, this will be one of the first things you want to check.

MK
MK
Doug O'Leary
Honored Contributor

Re: inet.sec with SSH

Hey;

As far as I know, sshd won't be affected by any entries in /etc/inetd.sec. That file, after all, is for services that are supplied by inetd. Go figure.

A previous post mentioned one possible way to do what you want. Another is to use /etc/hosts.allow and /etc/hosts.deny. This may require tcpwrappers to be installed; but, I'm not sure. tcpwrappers is available as a free download from software.hp.com

Please note that you're setting yourself up for some rather entertaining administration. Any time an IP address changes, or a new range comes in, you'll have to update those files. If your company/client is reasonably small, this may not be a big deal - if it's global in nature, I'd probably rethink the process.

Hope that helps.

Doug O'Leary

------
Senior UNIX Admin
O'Leary Computers Inc
linkedin: http://www.linkedin.com/dkoleary
Resume: http://www.olearycomputers.com/resume.html
Michael Steele_2
Honored Contributor

Re: inet.sec with SSH

Hi

You have two types of security going on here, a) ip filtering, and,
b) user authentication with encryption.

a) works in a static ip address system and keeps out workstations by ip.

b) adds encryption authentication to passwords authentication during the login process.

So you are hardening the system and can brag about it to management.
Support Fatherhood - Stop Family Law
Fernando Boza
Regular Advisor

Re: inet.sec with SSH

Thanks to All....
Matti, your post is the best....

I have a new question

You can make the same restriction for the use of SFTP?
Michael Steele_2
Honored Contributor

Re: inet.sec with SSH

Hello again.

sftp should be apart of the ssh package. sftp provides 128 bit encryption during the transmission of files between sites. You will also need the destination site url or hostname or ip, as well as the destination userid and password.

sftp provides you with 3 forms of authentication.
Support Fatherhood - Stop Family Law
VK2COT
Honored Contributor

Re: inet.sec with SSH

Hello,

a) By default, SSH is not run via
superdaemon inetd, so /var/adm/inetd.sec
is not going to help.

To do so, you need to make sure ssh will not start at boot time by editing
/etc/rc.config.d/sshd

Change SSHD_START=1 to 0

... and then add sshd line into /etc/inetd.conf. Something like:

ssh stream tcp nowait root /usr/sbin/sshd sshd -i

Then, you can use /var/adm/inetd.sec.

With small key sizes (e.g. 512) using sshd
from inetd may be feasible ("sshd -i").

b) If you install TCPwrappers,
it supports SSH via /etc/hosts.allow and
/etc/hosts.deny.

c) You can also use various tricks to limit
access to your server via SSH.

Take a look at the following options in sshd_config:

ListenAddress
AllowUsers
DenyUsers
and so on.

d) You can also use creative options in
ssh_config (either global file or
per-user). For example, to allow a key to be
used from anywhere within an organisation
except from the â dangerâ pool, the following
entry in authorized_keys file could be used:

from="!*.danger.mydom.dom,*.mydom.dom"

e) IPFilter can be used to
set ACLs for any protocol including SSH.

f) Port pam_access to HP-UX. From memory,
there was an old port to HP-UX 11.0 very long ago. pam_access delivers
log-daemon-style login access control using
login/domain names depending on pre-defined
rules in /etc/security/access.conf...

g) Finally, instead of using just sftp,
why not set up more comprehensive
options like vsftpd and/or ProFTPD:

http://vsftpd.beasts.org/
http://www.proftpd.org/module_news.html

For ProFTPD take a look at modules
mod_ban and mod_sftp. I implemented them
for various customers.

I also did the same with vsftpd for
other customers.

By the way, ProFTPD is part of
HP-UX Internet Express! You do not need
to compile it yourself:

https://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=HPUXIEXP1131

I hope this helps,

VK2COT
VK2COT - Dusan Baljevic