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

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.

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 ?

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. ;)

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. :)

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. ;)

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.

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

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.

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.

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

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

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.