PDA

View Full Version : SPLAT and ssh issue



cciesec2006
2010-06-20, 20:43
I have a SPLAT firewall running NGx R65 with HFA_70 fine for almost eight weeks without any issues.

Today I could NO longer ssh into the firewall. When I tried to ssh into the firewall
with the "admin" password, it prompts me for the password and when I type in the password,
it keeps telling me that the authentication has failed. With THE SAME PASSWORD, I CAN
log into the firewall from the serial port without any issues. Here is the current
configuration of the firewall:

- I added the /etc/scpusers file and have root and admin in this file,
- I modified the /etc/ssh/sshd_config file and modify the following lines:

[Expert@cciesec2006]# cat /etc/ssh/sshd_config | grep Root
PermitRootLogin yes
[Expert@cciesec2006]#
[Expert@cciesec2006]# cat /etc/ssh/sshd_config | grep Verify
VerifyReverseMapping no
[Expert@cciesec2006]# cat /etc/ssh/sshd_config | grep Deny
DenyUsers shutdown halt nobody ntp pcap rpm
[Expert@cciesec2006]# cat /etc/ssh/sshd_config | grep Allow
AllowTcpForwarding no
AllowGroups root admin
[Expert@cciesec2006]#
[Expert@cciesec2006]# cat /etc/passwd | grep admin
admin:x:0:0::/home/admin:/bin/bash
[Expert@cciesec2006]#


I also created a /root/.ssh/authorized_keys file and add the id_rsa.pub from my linux host
system into this file and that I can perform "ssh -l root cciesec2006" and it gets me directly
into the system expert mode. Therefore, it is telling me that my sshd config file is correct.

When I tried to ssh with the "admin" account, looking at the /var/log/messages, I see this:

Jun 20 04:13:57 cciesec2006 sshd(pam_unix)[1995]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=192.168.1.1 user=admin

Anyone know why the admin account does not work with ssh but works fine in serial port (aka console)?

Thorpuse
2010-06-20, 21:10
Did you change the hostname of the machine?

cciesec2006
2010-06-20, 22:03
Did you change the hostname of the machine?

Nope. Nothing was changed whatsoever.

[Expert@cciesec2006]# cat /etc/hosts
10.3.250.10 cciesec2006
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost localhost.localdomain

Rebooting the firewall a few times did not solve it either.

belvdr
2010-06-21, 08:51
What about IgnoreRhosts and IgnoreUserKnownHosts?

cciesec2006
2010-06-21, 09:27
What about IgnoreRhosts and IgnoreUserKnownHosts?

[Expert@cciesec2006]# cat /etc/ssh/sshd_config | grep Ignore
IgnoreRhosts yes
IgnoreUserKnownHosts yes
[Expert@cciesec2006]#


The /etc/ssh/sshd_config is exactly the same as other SPLAT system and only this one is NOT working. Other systems are working fine.

I am at a lost here.

belvdr
2010-06-21, 09:29
If sshd_config is the same as other working systems, then could it be the shell or home for admin? Anything in /etc/hosts.deny?

cciesec2006
2010-06-21, 09:40
If sshd_config is the same as other working systems, then could it be the shell or home for admin? Anything in /etc/hosts.deny?

[Expert@cciesec2006]# cat /etc/hosts.deny
ALL: ALL
[Expert@cciesec2006]#

belvdr
2010-06-21, 10:32
What about the shell or home?

At this point, try using ssh with -vv to debug the client. Hopefully it will show us what is being rejected.

You could also run the daemon in debug mode with -d.

cciesec2006
2010-06-21, 11:00
What about the shell or home?

At this point, try using ssh with -vv to debug the client. Hopefully it will show us what is being rejected.

You could also run the daemon in debug mode with -d.

This is a production box and it is very important box. It is the firewall running out of our CTO home office.
If I touch it now and it dies, I better look for another job :-(

I am not sure why it behaves this way. In the mean time, I will use "ssh -l root cciesec2006" and I can go directly into expert mode so I do not really worry too much about log in with "admin" account.

Not sure why the box behaves this way.

alienbaby
2010-06-21, 11:34
Bare in mind that CheckPoint has made changes to the code for SSH. They've added the scpusers functionality. Perhaps you've enabled some feature, for which they removed some need code, and now the sshd gives a denied by default.

Why are you enabling the root user when admin is UID 0? And after you login with admin, you can 'su - root'.

If you have a box that you know works with your desired configuration, then I suggest you md5sum the files in /etc/ and /etc/ssh/ on both the working and the broken one... Compare, and copy files with non-matching MD5s from the working box to the broken one.

I might even md5sum the ssh and sshd binaries; and everything that concerns PAM as well..

I saw mention of hosts.deny.. My hosts.deny and hosts.allow have the same contents. Be sure your hosts.allow hasn't been mucked with.. I believe hosts.allow is parsed before hosts.deny.

alienbaby
2010-06-21, 11:38
Jun 20 04:13:57 cciesec2006 sshd(pam_unix)[1995]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=192.168.1.1 user=admin

I note that the tty= says NODEV..

Interesting..

Check your /etc/securetty hasn't become corrupt.

cciesec2006
2010-06-21, 11:39
Bare in mind that CheckPoint has made changes to the code for SSH. They've added the scpusers functionality. Perhaps you've enabled some feature, for which they removed some need code, and now the sshd gives a denied by default.

Why are you enabling the root user when admin is UID 0? And after you login with admin, you can 'su - root'.

If you have a box that you know works with your desired configuration, then I suggest you md5sum the files in /etc/ and /etc/ssh/ on both the working and the broken one... Compare, and copy files with non-matching MD5s from the working box to the broken one.

I might even md5sum the ssh and sshd binaries; and everything that concerns PAM as well..

I saw mention of hosts.deny.. My hosts.deny and hosts.allow have the same contents. Be sure your hosts.allow hasn't been mucked with.. I believe hosts.allow is parsed before hosts.deny.


Already did all the things you described above during the maintenance window and rebooted the box several times. Same issue.

alienbaby
2010-06-21, 11:48
Does /var/log/secure give any additional clues?

cciesec2006
2010-06-21, 13:07
Does /var/log/secure give any additional clues?

Jun 21 17:06:35 cciesec2006 sshd[22066]: Failed password for admin from 192.168.1.1 port 2855 ssh2

alienbaby
2010-06-22, 13:47
The only thing I can think to do at this point is to log into the broken firewall via console, and stop sshd.. restart it in Debug mode and watch yourself authenticate. Gotta be some clue in the debug output..

Gotta be something broke in sshd_config or PAM.. Like a DOS CR/LF or something else messing up the parsing of the configs or somesuch..

Routerkid1
2010-06-22, 15:48
I have seen this before and I logged in via webui and created a new admin account. I then logged in to a 2nd webui with the new admin account and deleted and recreated the orig account.

cciesec2006
2010-06-22, 15:56
I have seen this before and I logged in via webui and created a new admin account. I then logged in to a 2nd webui with the new admin account and deleted and recreated the orig account.

Unfortunately, that method was already been tried by me two days ago and it did not work either.

Routerkid1
2010-06-22, 16:00
I have seen this before and I logged in via webui and created a new admin account. I then logged in to a 2nd webui with the new admin account and deleted and recreated the orig account.

Sucks build anew box

cciesec2006
2010-06-22, 16:02
Sucks build anew box

Is that the recommendation from a CCMA :-)

Routerkid1
2010-06-22, 16:59
Yea just like when a CCIE tells me to upgrade code on my core switch :)

Routerkid1
2010-06-22, 17:04
what do you have in your hosts.allow file in /etc ?


This comes to mind:

Solution ID: sk33481 Average Rating:

Cannot access WebUI or SSH on a SecurePlatform security gateway

Product: SecurePlatform / Pro
Version: NGX R60, NGX R62, NGX R65, R70, R71, NGX R61
OS: SecurePlatform
Last Modified: 23-May-2010




Symptoms



Cannot access WebUI or SSH on a SecurePlatform security gateway.
When trying to connect to the WebUI, after the certificate popup, the following message is displayed: "Cannot connect to server. Make sure the device is up and running and that you are allowed to login from this machine."
For SSH, the following error message pops up: "Server unexpectedly closed network connection."

Cause



The connection is rejected because it is not coming from an acceptable IP. The user has unchecked "Any" client in the Web and SSH clients page of the Device tab in the WebUI.

Solution



Proceed as follows:
On the security gateway command line, enter Expert Mode and then type cd /etc and access the hosts.allow file. This file contains the list of acceptable IPs for SSH and WebUI clients to the security gateway.

Add the line ALL:ALL to this file.

Then, access the WebUI and add the appropriate client IPs on the Web and SSH Clients page of the Device tab.


: Not sure if this will be the fix because typically you will have an issue accessing webui as well.

cciesec2006
2010-06-23, 06:06
what do you have in your hosts.allow file in /etc ?

Add the line ALL:ALL to this file.

Then, access the WebUI and add the appropriate client IPs on the Web and SSH Clients page of the Device tab.


: Not sure if this will be the fix because typically you will have an issue accessing webui as well.

First of all, I also have "ALL:ALL" in the hosts.allow file. it's the default. I did not touch this file.

Secondly, if you read from my previous post, I WAS ABLE to log into the box via RSA key with the "root" account without any issues. Therefore, I don't think this issue is relevant to mine.

ccie16798
2010-06-24, 08:29
First of all, I also have "ALL:ALL" in the hosts.allow file. it's the default. I did not touch this file.

Secondly, if you read from my previous post, I WAS ABLE to log into the box via RSA key with the "root" account without any issues. Therefore, I don't think this issue is relevant to mine.

hello,

i think it's related to how splat handles passwords; it doesn't seem to use /etc/shadow for 'checkpoint' accounts;
so if you set your shell to /bin/bash, you'll be authenticated the unix way and you need to have a UNIX password in /etc/shadow
use '\password $yourlogin' (yes, backslash so it doesn't use the checkpoint alias that uses in fact '/bin/expert_passwd' instead of the regular UNIX /usr/bin/passwd)

etienne

apachepro
2010-06-24, 13:10
Does /var/log/security reveal something more interesting about the login process?

alienbaby
2010-06-24, 13:49
hello,

i think it's related to how splat handles passwords; it doesn't seem to use /etc/shadow for 'checkpoint' accounts;
so if you set your shell to /bin/bash, you'll be authenticated the unix way and you need to have a UNIX password in /etc/shadow
use '\password $yourlogin' (yes, backslash so it doesn't use the checkpoint alias that uses in fact '/bin/expert_passwd' instead of the regular UNIX /usr/bin/passwd)

etienne


Then I would direct my view to PAM... specifically /etc/pam.d/sshd ....