Could not get shadow information for root (Errors)?

I am getting the error "Could not get shadow information for root (Errors)" what does this mean?

You can ignore that if you're running a 4.x series, as it likely deals with 'ssh' while unRAID does not support shadowed passwords.

OK thanks, that's at least one problem solved easily.

I started seeing this error in my logs after I installed transmission from outside of my firewall on transmission ports for ssh2.  Does this mean someone is trying to hack me over the ports transmission opened via uPnP or is this just something I should ignore.

 

I was spooked enough when I saw it initially that I shut down transmission but it would be nice to start using it again as long as it is safe to do so.

 

 

I started seeing this error in my logs after I installed transmission from outside of my firewall on transmission ports for ssh2.  Does this mean someone is trying to hack me over the ports transmission opened via uPnP or is this just something I should ignore.

Probably.

I was spooked enough when I saw it initially that I shut down transmission but it would be nice to start using it again as long as it is safe to do so.

unRAID is not secure unless YOU secure it, and there is only one way to get it right, and every other way will get it wrong.  (and the experts can't get it right most of the time) 

 

Best advice, unless using a VPN, It is not safe to open up ANY ports to the outside world.

Just to make sure I am reading this correctly, you are saying the Transmission plugin for unRaid is unsafe to use.  Is that correct?

Just to make sure I am reading this correctly, you are saying the Transmission plugin for unRaid is unsafe to use.  Is that correct?

No, I said that you should not open up ports on your router.  You mentioned ssh2.  Transmission does not use that, does it?

 

Joe L.

If you keep your unRAID machine behind a firewall or behind a NAT'd router where you only open the ports needed then you should be fine. However, if you open up more ports than needed in your router or place the machine directly on the internet, it is not secure. It's only as secure as you set it up as.

I have opened no ports manually.  As I mentioned, Transmission uses uPnP to open ports for itself.  Those ports should only be used for bittorrents but I keep seeing log messages as if someone is trying to get in on those ports with ssh2. 

 

It sounds like this is nothing to be concerned about as they will not be able to get in but it is a bit disconcerting to see my log continually telling me they are trying so I figured I would ask around to see if there was a known vulnerability here.

Set up a 20 char random password.

What would I setup the password on?  I get having passwords, blocking ports, vpns and all that good stuff but when it comes down to it if I am going to run a torrent client I need to allow random strangers from all over the internet to connect to me, just sorta how the protocol works.  I just want to make sure nothing else is being opened up except the ability to transfer torrents..

 

So are you saying I should have a password on the torrent client (which seems like a non-starter) or are you saying I should put a password on unRaid?

If the torrent client is secure then you should have no problems.

I couldn't help at laugh at how hard this is to get a straight answer on, or at least an understandable answer for someone who is not a guru.

 

I could almost (I realize it's a bit of a stretch) reword my initial question to "Is the torrent client secure? Will I have any problems?" and the answer boils down to "If the torrent client is secure then you should have no problems". 

 

I'm going to take this to mean "Yeah, the transmission install available as an unMenu package is secure, don't sweat it, ignore the consistent messages in your log that someone from the internet is trying to connect to your unRaid server over the port mapped for transmission via the ssh2 protocol because unRaid is not making ssh2 available on that port so this message while scary is absolutely unimportant".

 

Thanks for all of the input and let me know if I am interpreting this incorrectly.

Could you post more of your syslog?  That one line does not tel us much.

 

I have transmission running on my machine and I don't remember getting anything about ssh2 ports.  I have Upnp turned off though as Upnp can be a bag of hurt to begin with.

Bag of hurt eh?  So you're saying uPnP is to firewalls as Blu-Ray is to HD media? 

 

Here is what I am seeing in my syslog.  It sure looks like someone is trying to hack me but I don't mind them trying, I mind them succeeding.

 

Jan 11 04:40:01 Tower syslogd 1.4.1: restart.

Jan 11 04:40:07 Tower sshd[29228]: Invalid user larry from 122.224.246.194

Jan 11 04:40:07 Tower sshd[29228]: error: Could not get shadow information for NOUSER (Errors)

Jan 11 04:40:07 Tower sshd[29228]: Failed password for invalid user larry from 122.224.246.194 port 16502 ssh2

Jan 11 04:40:21 Tower sshd[29354]: Invalid user tony from 122.224.246.194

Jan 11 04:40:21 Tower sshd[29354]: error: Could not get shadow information for NOUSER (Errors)

Jan 11 04:40:21 Tower sshd[29354]: Failed password for invalid user tony from 122.224.246.194 port 20434 ssh2

Jan 11 04:40:33 Tower sshd[29472]: Invalid user cvs from 122.224.246.194

Jan 11 04:40:33 Tower sshd[29472]: error: Could not get shadow information for NOUSER (Errors)

Jan 11 04:40:33 Tower sshd[29472]: Failed password for invalid user cvs from 122.224.246.194 port 27999 ssh2

Jan 11 04:40:43 Tower sshd[29560]: Invalid user kevin from 122.224.246.194

Jan 11 04:40:44 Tower sshd[29560]: error: Could not get shadow information for NOUSER (Errors)

Jan 11 04:40:44 Tower sshd[29560]: Failed password for invalid user kevin from 122.224.246.194 port 32323 ssh2

Jan 11 04:40:48 Tower sshd[29602]: Invalid user eric from 122.224.246.194

Jan 11 04:40:49 Tower sshd[29602]: error: Could not get shadow information for NOUSER (Errors)

Jan 11 04:40:49 Tower sshd[29602]: Failed password for invalid user eric from 122.224.246.194 port 33389 ssh2

Jan 11 04:41:01 Tower sshd[29748]: Invalid user patrick from 122.224.246.194

Jan 11 04:41:01 Tower sshd[29748]: error: Could not get shadow information for NOUSER (Errors)

Jan 11 04:41:01 Tower sshd[29748]: Failed password for invalid user patrick from 122.224.246.194 port 25737 ssh2

Jan 11 04:41:06 Tower sshd[29792]: Invalid user frank from 122.224.246.194

Jan 11 04:41:07 Tower sshd[29792]: error: Could not get shadow information for NOUSER (Errors)

Jan 11 04:41:07 Tower sshd[29792]: Failed password for invalid user frank from 122.224.246.194 port 27028 ssh2

 

Looks to me like one guy running a script.  The IP address changes from time to time but the pattern seems the same.  Actually, initially I was seeing attempts on the ports mapped to Transmission (maybe that is how I was selected, from someone scanning ips from a bit torrent cloud?) and only with root user.  Now it appears they are trying different ports and user names.  I actually don't even have ssh2 enabled right now, when this started I disabled the ssh package in unRaid.

I am fairly confident that those messages DO NOT have anything to do with Transmission and your comment about disabling ssh and it still working affirms that thought.

 

Using ip-lookup you can see that the IP is coming from China.  Someone was attempting to gain access to your server via ssh.

Bag of hurt eh?  So you're saying uPnP is to firewalls as Blu-Ray is to HD media?  

 

Here is what I am seeing in my syslog.  It sure looks like someone is trying to hack me but I don't mind them trying, I mind them succeeding.

 

Jan 11 04:40:01 Tower syslogd 1.4.1: restart.

Jan 11 04:40:07 Tower sshd[29228]: Invalid user larry from 122.224.246.194

Jan 11 04:40:07 Tower sshd[29228]: error: Could not get shadow information for NOUSER (Errors)

Jan 11 04:40:07 Tower sshd[29228]: Failed password for invalid user larry from 122.224.246.194 port 16502 ssh2

Jan 11 04:40:21 Tower sshd[29354]: Invalid user tony from 122.224.246.194

Jan 11 04:40:21 Tower sshd[29354]: error: Could not get shadow information for NOUSER (Errors)

Jan 11 04:40:21 Tower sshd[29354]: Failed password for invalid user tony from 122.224.246.194 port 20434 ssh2

Jan 11 04:40:33 Tower sshd[29472]: Invalid user cvs from 122.224.246.194

Jan 11 04:40:33 Tower sshd[29472]: error: Could not get shadow information for NOUSER (Errors)

Jan 11 04:40:33 Tower sshd[29472]: Failed password for invalid user cvs from 122.224.246.194 port 27999 ssh2

Jan 11 04:40:43 Tower sshd[29560]: Invalid user kevin from 122.224.246.194

Jan 11 04:40:44 Tower sshd[29560]: error: Could not get shadow information for NOUSER (Errors)

Jan 11 04:40:44 Tower sshd[29560]: Failed password for invalid user kevin from 122.224.246.194 port 32323 ssh2

Jan 11 04:40:48 Tower sshd[29602]: Invalid user eric from 122.224.246.194

Jan 11 04:40:49 Tower sshd[29602]: error: Could not get shadow information for NOUSER (Errors)

Jan 11 04:40:49 Tower sshd[29602]: Failed password for invalid user eric from 122.224.246.194 port 33389 ssh2

Jan 11 04:41:01 Tower sshd[29748]: Invalid user patrick from 122.224.246.194

Jan 11 04:41:01 Tower sshd[29748]: error: Could not get shadow information for NOUSER (Errors)

Jan 11 04:41:01 Tower sshd[29748]: Failed password for invalid user patrick from 122.224.246.194 port 25737 ssh2

Jan 11 04:41:06 Tower sshd[29792]: Invalid user frank from 122.224.246.194

Jan 11 04:41:07 Tower sshd[29792]: error: Could not get shadow information for NOUSER (Errors)

Jan 11 04:41:07 Tower sshd[29792]: Failed password for invalid user frank from 122.224.246.194 port 27028 ssh2

 

Looks to me like one guy running a script.  The IP address changes from time to time but the pattern seems the same.  Actually, initially I was seeing attempts on the ports mapped to Transmission (maybe that is how I was selected, from someone scanning ips from a bit torrent cloud?) and only with root user.  Now it appears they are trying different ports and user names.  I actually don't even have ssh2 enabled right now, when this started I disabled the ssh package in unRaid.

sshd is still running or you would not be getting those messages in your system log.   Disabling the re-install does not disable the sshd process.   If you are running almost any release of unRAID there are some logins without passwords.  Odds are very high you could have been  been successfully hacked already unless you previously assigned passwords to ALL the logins in /etc/passwd.

 

I'd try typing:

/etc/rc.d/rc.sshd stop

or, if that does not do it,

killall sshd

 

Joe L.

Got it.  It is actually stopped now, thanks for the commands.

 

What makes you think they have already gotten in though?  If they had already gotten in wouldn't they stop trying new passwords?  How could I verify if I had already been successfully hacked?

Since this isn't my thread I can't mark it as solved but I finally found the root of the problem.  When it was mentioned that I shouldn't be seeing logged attempts if the service wasn't open on that port to the internet it made me go back and take a second look at my firewall config.  When I did that I found a HUGE mistake.  I had only manually mapped a couple of services I wanted mapped but there was also a separate setting for default host with a checkbox "use nat-pmp" which was unchecked.  I had a default host ip set, pointed to my unraid server but had unchecked "use nat-pmp" so I thought the default host mapping was turned off.  I re-read the manual and found that those two settings are completely unrelated, I was actually mapping ALL ports from the internet to my unRaid box along with the two I had manually setup.

 

Oops.  Luckily no harm done, I am only using my unRaid server for media right now and none of it is personal so even if someone got access all they have is my Blu-Ray collection. 

 

Thanks again for all of the help, no more attempts in my log now that I have correctly configured my firewall. 

As an additional safety precaution, you might want to reboot your unRAID server. If any part of your system was hacked doing a reboot should revert any hacks because unRAID uses a ram-based root filesystem. Not many script kiddies would recognize an unRAID system. For the system to truely be hacked, the user would have to hack into your "go" file or add additional addons in /boot/packages or modify the original 'bzroot' file on your USB drive.

 

I'm glad you figured out your misconfiguration.

Thanks for the heads up.  I'll reboot when I get home tonight.  Still haven't figured out how to reboot remotely, I have tried a couple of the stop array/shutdown safely/reboot scripts but strangely I haven't found an easy & reliable way to remotely reboot my server, it sometimes ends up not shutting down or shutting down and not coming back up.  I sure with there was a "reboot" button right in the UI that just worked.

Thanks for the heads up.  I'll reboot when I get home tonight.  Still haven't figured out how to reboot remotely, I have tried a couple of the stop array/shutdown safely/reboot scripts but strangely I haven't found an easy & reliable way to remotely reboot my server, it sometimes ends up not shutting down or shutting down and not coming back up.  I sure with there was a "reboot" button right in the UI that just worked.

There is.  It is on the stock web-management page when you stop the array.

You make stopping the array sound so simple, like I would just hit the stop button.  Been trying for a few minutes now, so far no luck.  I'll get used it it all eventually but this is the first server OS I have seen of any flavor that didn't just have a reboot button/switch/command that would be obeyed under all circumstances, even if it had to force quit something.  I have transmission stopped but it still won't stop.  There is no disk access that I can see.  Not sure what I'm missing but I thought it was just a known unRaid deficiency.

You make stopping the array sound so simple, like I would just hit the stop button.  Been trying for a few minutes now, so far no luck.  I'll get used it it all eventually but this is the first server OS I have seen of any flavor that didn't just have a reboot button/switch/command that would be obeyed under all circumstances, even if it had to force quit something.  I have transmission stopped but it still won't stop.  There is no disk access that I can see.  Not sure what I'm missing but I thought it was just a known unRaid deficiency.

The array will not stop if a disk is busy.  It does that to protect your data.  A disk is busy if a file on it is open, or if it is the current directory for a process.  It could be you and a telnet session holding a disk busy if you changed directory to a disk, as it would be your current working directory.

 

If you do not stop any add-ons prior to stopping the array, it will wait (nearly forever) for you to stop those add-on programs before continuing its stop of the array.  The only reason it will not wait forever is because it will log its attempts to stop the array to the system log.  Eventually, the log will use all available memory and the server will start terminating programs trying to free memory.

 

To see all the processes holding disks busy you can type:

fuser -mv /mnt/disk* /mnt/user/*

 

Joe L.

 

That helps, thanks.  It was SABNZBD holding it open (just watching a directory every 15 seconds, you wouldn't think that would keep a server from rebooting).  Rebooted it and when it came back up the array did not start.  Scary.  I just got home and hit the power button on the front and rebooted it that way and then it came right back up like nothing was wrong. 

 

I have no idea why it behaves differently but this sure is a finicky system to reboot.