- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: SSH in Security Containment
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
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
тАО06-26-2006 07:42 AM
тАО06-26-2006 07:42 AM
Ok, now some command outputs:
--- Client ---
#ssh root@192.168.0.80
(nothing happens)
--- Server ---
# ps -ef | grep sshd
root 822 1 0 08:45:08 ? 0:00 /opt/ssh/sbin/sshd
root 3208 1547 0 17:37:18 console 0:00 grep sshd
# netstat -an | grep 22
tcp 0 0 *.22 *.* LISTEN
tcp 0 1 192.168.0.80.22 192.168.0.134.41846 SYN_RCVD
tcp 0 0 *.22 *.* LISTEN
--- Rules in /etc/cmpt/ concerning this problem ---
compartment INIT {
/* ... */
grant server tcp port 22 in_iface /* SSH daemon */
/* ... */
}
compartment in_iface {
interface lan0
}
-------
Any suggestions for trying to solve this problem will be appreciated, thanks in advance.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-26-2006 07:52 AM
тАО06-26-2006 07:52 AM
Re: SSH in Security Containment
Secure shell is pretty secure (check name). Its a properly named product.
Try ssh -vvv root@192.168.0.80
At least you'll be sure its this other security product.
Try turning off the other security product and see if it works.
Good Luck,
SEP
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-26-2006 09:01 AM
тАО06-26-2006 09:01 AM
Re: SSH in Security Containment
felipo@uxso33:~$ ssh -vvv root@192.168.0.80
OpenSSH_4.1p1 Debian-7ubuntu4.1, OpenSSL 0.9.7g 11 Apr 2005
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.0.80 [192.168.0.80] port 22.
# ssh -vvv root@192.168.0.80
OpenSSH_4.3p2-hpn, OpenSSL 0.9.7i 14 Oct 2005
HP-UX Secure Shell-A.04.30.000, HP-UX Secure Shell version
debug1: Reading configuration data /opt/ssh/etc/ssh_config
debug3: Seeding PRNG from /opt/ssh/libexec/ssh-rand-helper
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.0.80 [192.168.0.80] port 22.
If I disable the other products the SSH will work fine, but I need IPFilter and Security Containment because I'm going to run a secure web server environment on that server, but first I need to get SSH access to it.
Anyway, thanks for your help so far.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-27-2006 04:30 AM
тАО06-27-2006 04:30 AM
Re: SSH in Security Containment
It is not clear from the description if you were able to narrow it down to Security Containment setup as the culprit, or if you believe if the IPFilter setup is a culprit too. Supposing that it is Containment, it is possible that sshd is trying to map the IP addresses back to hostnames via DNS and is experiencing problems. Add the following line/lines to INIT compartment and see if it solves the problem:
grant bidir udp peer port 53 in_iface /* permit DNS lookup */
Additionally (depending on configuration, I *think* you may need the following too):
grant bidir udp port 53 in_face /* DNS transfers for local caching server */
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-27-2006 06:11 AM
тАО06-27-2006 06:11 AM
Re: SSH in Security Containment
ipfstat -io | ipf -rf -
So I think the problem is really with compartments, since when I disable compartments (cmpt_tune -d) it works even with IPFilter rules loaded. I tried adding the rules for DNS that you posted and it still doesn't work. Also tried to add the hostnames to /etc/hosts but I really don't think it has to do with hostnames.
I'd like to add that when I try ssh root@192.168.0.80 I see the following in netstat -an:
--- Client ---
felipo@uxso33:~$ netstat -an | grep 22
tcp 0 1 192.168.0.134:42130 192.168.0.80:22 SYN_SENT
--- Server ---
# netstat -an | grep 22
tcp 0 1 192.168.0.80.22 192.168.0.134.42134 SYN_RCVD
------
I'm not an expert in networking but it seems that "some" communication is working but no connection.
Then I also tried to put sshd in debug mode:
# /sbin/init.d/secsh stop
HP-UX Secure Shell stopped
# ps -ef | grep sshd
root 4748 1547 1 15:52:07 console 0:00 grep sshd
# /opt/ssh/sbin/sshd -ddd
debug2: load_server_config: filename /opt/ssh/etc/sshd_config
debug2: load_server_config: done config len = 240
debug2: parse_server_config: config /opt/ssh/etc/sshd_config len 240
debug1: sshd version OpenSSH_3.9 [ HP-UX Secure Shell-A.03.91.009 ]
debug3: Not a RSA1 key file /opt/ssh/etc/ssh_host_rsa_key.
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug3: Not a RSA1 key file /opt/ssh/etc/ssh_host_dsa_key.
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/opt/ssh/sbin/sshd'
debug1: rexec_argv[1]='-ddd'
debug2: fd 3 setting O_NONBLOCK
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug2: fd 4 setting O_NONBLOCK
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
(nothing happens!)
But nothing happens when I try to connect from client machines.
For those reasons I think that the problem is with the compartment rules, but I don't know what I could be doing wrong, is there anything else I should be checking?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-27-2006 08:28 AM
тАО06-27-2006 08:28 AM
SolutionHi Felipo,
Looks like the server is not responding or
something is preventing it from responding.
So its still in SYN_RCVD state and looks
it has not sent the ACK.
Can you provide the IPFilter rules you are
using? Are you sure that the routing is not
modified when you enable compartments.
Thanks
Hrishikesh
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-27-2006 10:11 AM
тАО06-27-2006 10:11 AM
Re: SSH in Security Containment
I was unable to reproduce the problem on my box, so now we are going to go fishing.
Make sure that sshd is not running in a different cmpt ("getfilexsec /opt/ssh/sbin/sshd" should result in an error message; if not, do a "setfilexsec -d /opt/ssh/sbin/sshd" and try it again). Also make sure that you are not invoking the sshd from non-init cmpt either ("getprocxsec $$").
Assuming that it was not the problem, let us turn on a few debugs:
a) ndd -set /dev/tcp tcp_debug 1
b)run "adb -o -w /stand/vmunix /dev/kmem"
at the prompt, do "tcp_safer_debug_flag/W 1"
and "ucmdebug/W 5" and "lcmdebug/W 5" (all without quotes, of course)
c) strace > /tmp/strace.out &
Now run the "sshd -dddd" and try connecting.
After a second or two, interrupt and set the variables back to 0 to avoid excessive output into syslog. ("adb....", "lcmdebug/W 0" etc).
Then we have to take a look at /var/adm/syslog/syslog.log and /tmp/strace.out to see what we can figureout.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-28-2006 01:57 AM
тАО06-28-2006 01:57 AM
Re: SSH in Security Containment
I'm making most tests with IPFilter disabled just to be sure. When I turn compartments on I can access SSH even with IPFilter on, so it's not a problem with it or with SSH configuration.
I was skeptical about the problem being with routing but I tried to disable the second network interface and the routing for it and surprisingly it worked!
Now I have to check what was wrong with my old NIC/Routing configuration.
ratan,
I checked the security properties for SSHD. SSHD is being started in the INIT compartment, both in /sbin/init.d/secsh and from command line.
# getfilexsec /opt/ssh/sbin/sshd
getfilexsec: File "/opt/ssh/sbin/sshd" is not a privileged application
# getprocxsec $$
effective= BASIC
permitted= BASIC
retained= BASIC
cmpt= init
euid= zero
But as you can see above, the problem wasn't with compartment rules itself, but something about routing.
Anyway I have SSH access now and I am going to check what was wrong with routing.
That's it, thank you very much. Your help was indeed valuable.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-28-2006 03:08 AM
тАО06-28-2006 03:08 AM