PFSense blocking SSH access



  • Hello all. I have a pfSense running for the past year and its been great. I recently wanted to access it through SSH and i read that I need to enable it from the advanced page, which I did, but I cant login at all. I tried from my win and my mac computers and the connection drops instantly. It doesn't even prompt me for a password. What can be the cause of the problem? The ssh service is runing and I tried both users admin and root. pfSense ver.2.2.2

    Thanks.



  • Are you accessing via LAN or WAN?  Check for firewall rules that may be blocking.  Also have you enabled anti lockout.  That will create a pass rule for port 22 at top of LAN firewall.



  • I am accessing from the LAN. Anti-lockout already has a top rule to enable port 22. SSH Lockout table is empty


  • Rebel Alliance Global Moderator

    "It doesn't even prompt me for a password."

    So you get prompted for username, and then it disconnects sounds like you have password auth turned off - which is good but you would have to setup public key auth.  Did you setup public key auth??




  • Well from my Mac I do " ssh root@10.0.1.1" and I dont get a prompt for a password, the connection closes instantly. From putty in Windows I get the login prompt, but as soon as I enter root and hit enter, the connection drops. The Disable password login for Secure Shell option is disabled. I never had to login with ssh before, so I have not changed any options regarding ssh or any firewall rules. I was never able to login.


  • Rebel Alliance Global Moderator

    disabled so you have a check box or don't have a check.. If you have a CHECK then password is disabled an you have to use public key.



  • I do not have a check box. Here is the output

    macbook-air:~ user$ ssh root@10.0.1.1
    The authenticity of host '10.0.1.1 (10.0.1.1)' can't be established.
    RSA key fingerprint is 41:3e:39:85:59:2b:4c:2f:b8:08:f8:e6:0b:df:4b:8f.
    Are you sure you want to continue connecting (yes/no)? yes
    Warning: Permanently added '10.0.1.1' (RSA) to the list of known hosts.
    Connection closed by 10.0.1.1
    macbook-air:~ user$


  • Netgate

    What's in Status > System Logs > System Tab when you try to connect?



  • This is the system log:

    Sep 6 01:59:03 init: _secure_path: /etc/login.conf is not owned by root
    Sep 6 01:59:03 init: _secure_path: /etc/login.conf is not owned by root
    Sep 6 01:59:03 init: _secure_path: /etc/login.conf is not owned by root
    Sep 6 01:59:03 init: _secure_path: /etc/login.conf is not owned by root
    Sep 6 01:59:03 login: _secure_path: /etc/login.conf is not owned by root
    Sep 6 01:59:03 login: _secure_path: /etc/login.conf is not owned by root
    Sep 6 01:59:03 login: in openpam_check_desc_owner_perms(): /etc/pam.d/login: insecure ownership or permissions
    Sep 6 01:59:03 login: in openpam_check_desc_owner_perms(): /etc/pam.d/login: insecure ownership or permissions
    Sep 6 01:59:03 login: pam_start(): system error
    Sep 6 01:59:03 login: pam_start(): system error
    Sep 6 01:59:03 init: _secure_path: /etc/login.conf is not owned by root
    Sep 6 01:59:03 init: _secure_path: /etc/login.conf is not owned by root
    Sep 6 01:59:03 init: _secure_path: /etc/login.conf is not owned by root
    Sep 6 01:59:03 init: _secure_path: /etc/login.conf is not owned by root
    Sep 6 01:59:03 login: _secure_path: /etc/login.conf is not owned by root
    Sep 6 01:59:03 login: _secure_path: /etc/login.conf is not owned by root
    Sep 6 01:59:03 login: in openpam_check_desc_owner_perms(): /etc/pam.d/login: insecure ownership or permissions
    Sep 6 01:59:03 login: in openpam_check_desc_owner_perms(): /etc/pam.d/login: insecure ownership or permissions
    Sep 6 01:59:03 login: pam_start(): system error
    Sep 6 01:59:03 login: pam_start(): system error
    Sep 6 01:59:03 init: _secure_path: /etc/login.conf is not owned by root
    Sep 6 01:59:03 init: _secure_path: /etc/login.conf is not owned by root
    Sep 6 01:59:03 init: _secure_path: /etc/login.conf is not owned by root
    Sep 6 01:59:03 init: _secure_path: /etc/login.conf is not owned by root
    Sep 6 01:59:03 login: _secure_path: /etc/login.conf is not owned by root
    Sep 6 01:59:03 login: _secure_path: /etc/login.conf is not owned by root
    Sep 6 01:59:03 login: in openpam_check_desc_owner_perms(): /etc/pam.d/login: insecure ownership or permissions
    Sep 6 01:59:03 login: in openpam_check_desc_owner_perms(): /etc/pam.d/login: insecure ownership or permissions
    Sep 6 01:59:03 login: pam_start(): system error
    Sep 6 01:59:03 login: pam_start(): system error
    Sep 6 01:59:03 init: _secure_path: /etc/login.conf is not owned by root
    Sep 6 01:59:03 init: _secure_path: /etc/login.conf is not owned by root
    Sep 6 01:59:03 init: _secure_path: /etc/login.conf is not owned by root
    Sep 6 01:59:03 init: _secure_path: /etc/login.conf is not owned by root
    Sep 6 01:59:03 login: _secure_path: /etc/login.conf is not owned by root
    Sep 6 01:59:03 login: _secure_path: /etc/login.conf is not owned by root
    Sep 6 01:59:03 login: in openpam_check_desc_owner_perms(): /etc/pam.d/login: insecure ownership or permissions
    Sep 6 01:59:03 login: in openpam_check_desc_owner_perms(): /etc/pam.d/login: insecure ownership or permissions
    Sep 6 01:59:03 login: pam_start(): system error
    Sep 6 01:59:03 login: pam_start(): system error
    Sep 6 01:59:03 init: getty repeating too quickly on port /dev/ttyv0, sleeping 30 secs
    Sep 6 01:59:03 init: getty repeating too quickly on port /dev/ttyv0, sleeping 30 secs
    Sep 6 01:59:07 sshd[28230]: _secure_path: /etc/login.conf is not owned by root
    Sep 6 01:59:07 sshd[28230]: _secure_path: /etc/login.conf is not owned by root
    Sep 6 01:59:07 sshd[28230]: login_getclass: unknown class 'root'
    Sep 6 01:59:07 sshd[28230]: login_getclass: unknown class 'root'
    Sep 6 01:59:07 sshd[28230]: in openpam_check_desc_owner_perms(): /etc/pam.d/sshd: insecure ownership or permissions
    Sep 6 01:59:07 sshd[28230]: in openpam_check_desc_owner_perms(): /etc/pam.d/sshd: insecure ownership or permissions
    Sep 6 01:59:07 sshd[28230]: fatal: PAM: initialisation failed
    Sep 6 01:59:07 sshd[28230]: fatal: PAM: initialisation failed


  • Banned

    Yeah. pfSense is blocking nothing, you have messed up permissions on your system.



  • But I have not been changing any permissions.  I never changed anything from ssh since I never used it. I only have NAT and Firewall rules, DHCP, DNS  and recently installed Squid. All was managed from the web interface.

    Solution, clean install? Will config backup/restore all settings on the new pfinstall ?


  • Netgate

    What's the output of this in Diagnostics > Command Prompt

    Command: ls -l /etc

    Could this be another by-product of the /etc corruption crap?  Is this a nano install?


  • Banned

    Well, whatever it is, I'd re-apply latest 2.2.4 upgrade to get same permissions everywhere.



  • @jolebole:

    This is the system log:

    Sep 6 01:59:03 init: _secure_path: /etc/login.conf is not owned by root
    Sep 6 01:59:03 init: _secure_path: /etc/login.conf is not owned by root

    [snip]

    Sep 6 01:59:07 sshd[28230]: login_getclass: unknown class 'root'
    Sep 6 01:59:07 sshd[28230]: login_getclass: unknown class 'root'
    Sep 6 01:59:07 sshd[28230]: in openpam_check_desc_owner_perms(): /etc/pam.d/sshd: insecure ownership or permissions
    Sep 6 01:59:07 sshd[28230]: in openpam_check_desc_owner_perms(): /etc/pam.d/sshd: insecure ownership or permissions
    Sep 6 01:59:07 sshd[28230]: fatal: PAM: initialisation failed
    Sep 6 01:59:07 sshd[28230]: fatal: PAM: initialisation failed

    What do you have installed package wise and have you made any changes of your own at the command line?

    You might want to look at this thread https://forum.pfsense.org/index.php?topic=92620.0

    Where the "/etc/login.conf is not owned by root" message pops up, its related to the Jail which controls the permissions.

    Now a possible quick and simple solution would be to use "chown root /etc/login*" but as you dont know what caused this problem, I'd investigate it first.

    One thing I will say, if you have had your pfsense fw compromised and its not an unreported bug, all your devices that can be updated have the potential for being compromised, ie your bios, if using windows on a spin disk, where windows does a quick format, that can leave malware on the sectors of little used parts of the spin disk waiting to be reactivated even though windows follows an algo to split programs and files across the spin disk to speed up the user experience, printers, scanners etc where the firmware can also be updated. Its very easy decompiling code in an automated fashion and its quite easy auditing a network and systems for HW as the NSA would like to testify but cant due to their inherent requirement for operational secrecy, but they do use Linux alot.  ;)

    Dont under estimate the ingenuity of hackers.

    What I'd be curious to know at this stage is if your pfsense machine has been compromised/hacked and if its being used in much the same way Lizard Squad have pwn'ed routers making them part of a botnet as you can read here.
    http://krebsonsecurity.com/2015/01/lizard-stresser-runs-on-hacked-home-routers/

    If you just re-apply the 2.2.4 patch, you will be none the wiser to finding out if your pfsense fw has been hacked or not and if it has been hacked, then you still wont be able to stop the hack until you find how they hacked your pfsense fw. Do you see the problem?

    So if you want to find out, which will help all the pfsense users, you could start by making an image, make a backup of your pfsense fw before reinstalling 2.2.4 or the 2.2.2 version thats got permission issues and then start comparing your dodgy image against the newly installed image.

    If you upgraded to 2.2.2 from 2.2.1 and 2.2.1 was a fresh install, I'd reinstall 2.2.1, restore that backup before upgrading to 2.2.2. This way any upgrade errors/anomalies will likely be reproduced which might also have contributed to you permissions failure. It takes about 10mins to do a fresh install, restore a backup and about another 10mins to upgrade and restore the backup for that version. It also pays to keep copies of old backups before you upgraded in case you ever have to do some sort of forensic analysis like this.

    dd or dcfldd will help you do images on a linux box, then to compare cmp using a command like "cmp /dev/hda /dev/hdb" will report the differences. This will report differences as your logs will be different, but if pfsense stores logs on a seperate partition (havent looked) then it will help reduce the number of errors reported as file date time stamps will be different and will get reported the most, but its the differences file sizes you want to look for as well as additional files that will help you find out if you have you any additional code added to your fw. If that shows nothing up, the other possibility is a zero day in some code used by pfsense which may not have been reported to FreeBSD amongst a few other possibilitys.

    Of course what makes this exercise even harder is the packages you may have been running, might have been updated after you original installed them. One way around this problem is to make your own offline copy of the package repository to keep copies of what you installed at the time for such a forensic exercise. This link will help you with that problem. https://doc.pfsense.org/index.php/Creating_a_Custom_Package_Repository

    Anyway just a bit of food for thought if you are so inclined to find out a little more about whether your pfsense box has been hacked or not.  :)

    fwiw.


  • Banned

    @firewalluser:

    I'd reinstall 2.2.1, restore that backup before upgrading to 2.2.2.

    Leaving the loads of OT crap aside, why on earth would you be restoring known buggy versions that caused the huge /etc corruption issues? WTF really.



  • @doktornotor:

    Well, whatever it is, I'd re-apply latest 2.2.4 upgrade to get same permissions everywhere.

    I'm gonna run the upgrade and see if that helps. If not I'll do a clean install.



  • @Derelict:

    What's the output of this in Diagnostics > Command Prompt

    Command: ls -l /etc

    Could this be another by-product of the /etc corruption crap?  Is this a nano install?

    Sorry I ran the upgrade and did not check that command. It's a regular install to a hdd.



  • @firewalluser:

    @jolebole:

    This is the system log:

    Sep 6 01:59:03 init: _secure_path: /etc/login.conf is not owned by root
    Sep 6 01:59:03 init: _secure_path: /etc/login.conf is not owned by root

    [snip]

    Sep 6 01:59:07 sshd[28230]: login_getclass: unknown class 'root'
    Sep 6 01:59:07 sshd[28230]: login_getclass: unknown class 'root'
    Sep 6 01:59:07 sshd[28230]: in openpam_check_desc_owner_perms(): /etc/pam.d/sshd: insecure ownership or permissions
    Sep 6 01:59:07 sshd[28230]: in openpam_check_desc_owner_perms(): /etc/pam.d/sshd: insecure ownership or permissions
    Sep 6 01:59:07 sshd[28230]: fatal: PAM: initialisation failed
    Sep 6 01:59:07 sshd[28230]: fatal: PAM: initialisation failed

    What do you have installed package wise and have you made any changes of your own at the command line?

    You might want to look at this thread https://forum.pfsense.org/index.php?topic=92620.0

    Where the "/etc/login.conf is not owned by root" message pops up, its related to the Jail which controls the permissions.

    Now a possible quick and simple solution would be to use "chown root /etc/login*" but as you dont know what caused this problem, I'd investigate it first.

    One thing I will say, if you have had your pfsense fw compromised and its not an unreported bug, all your devices that can be updated have the potential for being compromised, ie your bios, if using windows on a spin disk, where windows does a quick format, that can leave malware on the sectors of little used parts of the spin disk waiting to be reactivated even though windows follows an algo to split programs and files across the spin disk to speed up the user experience, printers, scanners etc where the firmware can also be updated. Its very easy decompiling code in an automated fashion and its quite easy auditing a network and systems for HW as the NSA would like to testify but cant due to their inherent requirement for operational secrecy, but they do use Linux alot.  ;)

    Dont under estimate the ingenuity of hackers.

    What I'd be curious to know at this stage is if your pfsense machine has been compromised/hacked and if its being used in much the same way Lizard Squad have pwn'ed routers making them part of a botnet as you can read here.
    http://krebsonsecurity.com/2015/01/lizard-stresser-runs-on-hacked-home-routers/

    If you just re-apply the 2.2.4 patch, you will be none the wiser to finding out if your pfsense fw has been hacked or not and if it has been hacked, then you still wont be able to stop the hack until you find how they hacked your pfsense fw. Do you see the problem?

    So if you want to find out, which will help all the pfsense users, you could start by making an image, make a backup of your pfsense fw before reinstalling 2.2.4 or the 2.2.2 version thats got permission issues and then start comparing your dodgy image against the newly installed image.

    If you upgraded to 2.2.2 from 2.2.1 and 2.2.1 was a fresh install, I'd reinstall 2.2.1, restore that backup before upgrading to 2.2.2. This way any upgrade errors/anomalies will likely be reproduced which might also have contributed to you permissions failure. It takes about 10mins to do a fresh install, restore a backup and about another 10mins to upgrade and restore the backup for that version. It also pays to keep copies of old backups before you upgraded in case you ever have to do some sort of forensic analysis like this.

    dd or dcfldd will help you do images on a linux box, then to compare cmp using a command like "cmp /dev/hda /dev/hdb" will report the differences. This will report differences as your logs will be different, but if pfsense stores logs on a seperate partition (havent looked) then it will help reduce the number of errors reported as file date time stamps will be different and will get reported the most, but its the differences file sizes you want to look for as well as additional files that will help you find out if you have you any additional code added to your fw. If that shows nothing up, the other possibility is a zero day in some code used by pfsense which may not have been reported to FreeBSD amongst a few other possibilitys.

    Of course what makes this exercise even harder is the packages you may have been running, might have been updated after you original installed them. One way around this problem is to make your own offline copy of the package repository to keep copies of what you installed at the time for such a forensic exercise. This link will help you with that problem. https://doc.pfsense.org/index.php/Creating_a_Custom_Package_Repository

    Anyway just a bit of food for thought if you are so inclined to find out a little more about whether your pfsense box has been hacked or not.  :)

    fwiw.

    I  dont know if the pfsense has been compromised. I have not noticed any weird network or bandwith issues. As a precaution I will be changing the password and lock the box from the outside.



  • @jolebole:

    I  dont know if the pfsense has been compromised. I have not noticed any weird network or bandwith issues. As a precaution I will be changing the password and lock the box from the outside.

    You wont or shouldnt notice anything unusual by getting at the first node in a network, ie the router or firewall, thats the point of going for these targets.



  • @doktornotor:

    @firewalluser:

    I'd reinstall 2.2.1, restore that backup before upgrading to 2.2.2.

    Leaving the loads of OT crap aside, why on earth would you be restoring known buggy versions that caused the huge /etc corruption issues? WTF really.

    WTF Really?

    @firewalluser:

    If you upgraded to 2.2.2 from 2.2.1 and 2.2.1 was a fresh install, I'd reinstall 2.2.1, restore that backup before upgrading to 2.2.2. This way any upgrade errors/anomalies will likely be reproduced which might also have contributed to you permissions failure.

    All releases have bugs, including the current version 2.2.4 which you are recommending people to upgrade to, these bugs  are currently unknown bugs or zero days, until reported and are patched in 2.2.5 or later versions.

    So get over the fact thats the name of the game, its a moving target. Its what makes or breaks sloppy firewalls and internet security practices leaving users exposed.  :D



  • @doktornotor:

    Well, whatever it is, I'd re-apply latest 2.2.4 upgrade to get same permissions everywhere.

    Upgrading to 2.2.4 fixed the problem. I can ssh as root now. :)


  • Netgate

    All releases have bugs, including the current version 2.2.4 which you are recommending people to upgrade to, these bugs  are currently unknown bugs or zero days, until reported and are patched in 2.2.5 or later versions.

    So get over the fact thats the name of the game, its a moving target. Its what makes or breaks sloppy firewalls and internet security practices leaving users exposed.  :D

    OP should be using 2.2.4. Chances are his /etc got corrupted by the 2.2 sync mistakes that were corrected in 2.2.3 and enhanced in 2.2.4. The nano problem is slow writes.  As I understand it the /etc corruption is not nano-specific but due to the slow writes and the misguided speedup method in 2.2.2 and older, nano was more susceptible.

    I know I experienced it testing failover by removing power on APUs with full-install mSATA on good intel drives from netgate.



  • @Derelict:

    All releases have bugs, including the current version 2.2.4 which you are recommending people to upgrade to, these bugs  are currently unknown bugs or zero days, until reported and are patched in 2.2.5 or later versions.

    So get over the fact thats the name of the game, its a moving target. Its what makes or breaks sloppy firewalls and internet security practices leaving users exposed.  :D

    OP should be using 2.2.4. Chances are his /etc got corrupted by the 2.2 sync mistakes that were corrected in 2.2.3 and enhanced in 2.2.4. The nano problem is slow writes.  As I understand it the /etc corruption is not nano-specific but due to the slow writes and the misguided speedup method in 2.2.2 and older, nano was more susceptible.

    I know I experienced it testing failover by removing power on APUs with full-install mSATA on good intel drives from netgate.

    Lesson learned. I will be updating to the latest releases as soon as they come out now.


  • Netgate

    It's just that telling someone to not update to the latest version because there might be a zero day is nonsense.



  • @Derelict:

    It's just that telling someone to not update to the latest version because there might be a zero day is nonsense.

    But you'll note if you read carefully what I put, I have not told someone to NOT update to the latest version, but I have provided a way to find out what the problem might be if so inclined to do so for piece of mind not to mention it being an educational exercise as its assumed at this stage to be the /etc bug.

    However on the laws of probability would you like to wager there are no zero days in 2.2.4?  ;D


  • Rebel Alliance Global Moderator

    I agree the odds that the OP issue was because of a compromise what what??  More likely hit by lightning hit the power ball, and the mega millions while you bought 10 winning scratch offs in a row??

    Its great and all that your tinfoil hat is 2 sizes too small for you and the NSA has a detail just to trail you.. But the rest of us live in the real world ;)



  • @johnpoz:

    I agree the odds that the OP issue was because of a compromise what what??  More likely hit by lightning hit the power ball, and the mega millions while you bought 10 winning scratch offs in a row??

    Its great and all that your tinfoil hat is 2 sizes too small for you and the NSA has a detail just to trail you.. But the rest of us live in the real world ;)

    Why do you attack your users for suggesting a way for other users to educate themselves and have piece of mind over the what they use? Do you like keeping your users dumb?

    I mentioned the NSA as its a good level to aim for, because they have only had a few major leaks in recent times, the most notable being Snowden.

    So if you can lock your systems down to a level beyond their capabilities including the legals ones, then I'd say you have reasonably secure system because who wants to let their IT equipment becomes involved in hacking attacks on things like this? https://cryptome.org/2015/09/nnsa-iranian-target.htm

    The NSA are a finite resource and there are certainly less of them than the rest of the world so a little bit of education can go a long long way. You do the odds.  ;D


  • Banned

    Yeah, sure like hell NSA is so lame to cut themselves off SSH by screwing up permissions in retarded way.



  • @firewalluser:

    The NSA are a finite resource and there are certainly less of them than the rest of the world so a little bit of education can go a long long way. You do the odds.  ;D

    Please stop bringing NSA into every thread. Keep the roll of tinfoil all to yourself. Thanks.



  • @fragged:

    @firewalluser:

    The NSA are a finite resource and there are certainly less of them than the rest of the world so a little bit of education can go a long long way. You do the odds.  ;D

    Please stop bringing NSA into every thread. Keep the roll of tinfoil all to yourself. Thanks.

    So when all other arguments have been lost, all you can revert to is the suggestion of tinfoil hats et al?

    If people dont value privacy, they must be exhibitionists.

    @doktornotor:

    Yeah, sure like hell NSA is so lame to cut themselves off SSH by screwing up permissions in retarded way.

    So pfsense screwed up permissions in a retarded way then? Doesnt inspire pfsense users with confidence does it?


  • Banned

    @firewalluser:

    So pfsense screwed up permissions in a retarded way then?

    Yeah. It's been a fucking bug with filesystem corruption. Fixed. Hard to miss, but maybe you've been abducted by aliens meanwhile, or busy shopping for more tinfoil…  ::)


  • Rebel Alliance Global Moderator

    But was it a bug that the NSA planted to thwart further adoption of pfsense and increased development while they worked on the bug??  Hmmm  makes you wonder ;) ROFL..

    Oh hold on those black helicopters are out there again..



  • Why are you lot even suggesting the NSA planted the bug? Geez you guys are worse than I thought.

    The NSA will exploit bugs where possible though when programmers make mistakes, they even buy some of the zero days from online hacking forums.
    https://www.washingtonpost.com/news/the-switch/wp/2013/08/31/the-nsa-hacks-other-countries-by-buying-millions-of-dollars-worth-of-computer-vulnerabilities/

    The NSA are actively supporting Hackers by outbidding other countries, they need peoples stupidity to exist.


  • Banned

    Noone here was suggesting that NSA had anything to do with it. You just yet again ruined another thread with your conspiracy theories. Perhaps, if you think about it for a while, no "hacker" will mess up permissions in a way that he gets cut off the shell… Christ.



  • Read carefully what exactly I put and quote me if you can where I have associated these problems to the NSA.

    In the mean time enjoy paying your tax dollars to fund the terrorists!  ;D