- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: inet.sec with SSH
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-05-2010 02:08 PM
тАО04-05-2010 02:08 PM
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?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-05-2010 04:33 PM
тАО04-05-2010 04:33 PM
Re: inet.sec with SSH
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-05-2010 10:23 PM
тАО04-05-2010 10:23 PM
SolutionHowever, 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-06-2010 06:09 AM
тАО04-06-2010 06:09 AM
Re: inet.sec with SSH
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-06-2010 06:48 AM
тАО04-06-2010 06:48 AM
Re: inet.sec with SSH
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-06-2010 11:08 AM
тАО04-06-2010 11:08 AM
Re: inet.sec with SSH
Matti, your post is the best....
I have a new question
You can make the same restriction for the use of SFTP?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-06-2010 11:33 AM
тАО04-06-2010 11:33 AM
Re: inet.sec with SSH
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-08-2010 02:00 AM
тАО04-08-2010 02:00 AM
Re: inet.sec with SSH
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