2

I ran lynis 1.5.6 and got the following log message.

Performing test ID TIME-3120 (Check unreliable NTP peers)
Test: Checking unreliable ntp peers
Result: Found one or more unreliable peers (marked with a minus or dash sign)
Unreliable peer: 50.7.96.4
Suggestion: Check ntpq peers output for unreliable ntp peers and correct/replace them [TIME-3120]

I ran

sudo ntpq -i and it gives the commands explained here. However, it does not say how to correct or replace a peer.

I made the changes suggested here but still get the lynis suggestion. I looked in /var/log/ntpstats and there was nothing there. I did give the unreliable peer as 50.7.0.147 which is Abovenet Communications according to isc.sans.edu.

Can this lynis suggestion be ignored?

Braiam
  • 35,991
OtagoHarbour
  • 785
  • 4
  • 13
  • 28

2 Answers2

3

You can ignore that warning. To be honest it is not an accurate description of the peer status codes. A minus does not mean that the server is unreliable. It means that the peer was discarded by the cluster algorithm. This is a normal by product of the clock selection algorithm.

The other answer suggests using servers from the pool project. The pool project monitors servers and removes those that are misfunctioning. However it will not eliminate servers that have a minus in the peer status code for you. Furthermore as a client you have no control over what servers the pool project randomly assigns you. Given a decent list of peers it is very likely that one server will be rejected by the clustering algo. This can be for any number of reasons such as latency spikes or temperature changes. Here is my ntpqq billboard from machine I just booted up. I have my local ntp server (stratum 1 GPS), another stratum 1 server that is close to me and four servers that that the pool project randomly selected for me randomly.

 dfc@jumbo:~$ ntpq -p
      remote           refid      st t when poll reach   delay   offset  jitter
 ==============================================================================
 *ronin.llamahaus .GPS.            1 u   58   64    7    0.187   -0.168   0.789
 +clock1.alb1.ino .CDMA.           1 u   59   64    7   37.231    6.703   3.304
 +pool-test.ntp.o 204.123.2.5      2 u   60   64    7   77.727    1.775   1.139
 -defiance.terran 209.118.204.201  3 u   59   64    7   50.638   10.097   1.630
 -ponderosa.piney 209.51.161.238   2 u   57   64    7   37.756    9.511   2.780
 +greenwix.netlob 216.218.254.202  2 u   56   64    7   87.031   -2.368   1.846

There are two servers with a minus sign in front of them, these are pool servers. ntp did not select those to sync the time with. The server with the star is the peer I am synced with and the the servers with the plus signs were the other candidates.

TLDR: Ignore the warning from lynis. Check out the documentation from ntp.org if you want to read more about the peer status codes .

dfc
  • 1,026
  • Thank you for your reply. I can understand that clustering algorithms can give dubious results, particularly using K-means which still appears to be the most popular. Thanks again, – OtagoHarbour Sep 20 '14 at 14:55
2

How many peers are you using? If you use three (or more) servers, then NTP has the intelligence to tell if one is out of sync with the others and it will stop using it until it becomes "sane" again.

I would suggest choosing servers from here:

http://www.pool.ntp.org/en/

There's probably nothing you can do about a server misbehaving if you don't control it. Just pick a different server.

nelsonov
  • 99
  • Thank you for your reply. I never actually set NTP up. I suspect the peers were assigned when I installed Debian 6.5. This PC always appears to keep perfect time, unlike some of the other computers I have. It could be because it has a wired connection while the others are wireless. Thanks, – OtagoHarbour Sep 20 '14 at 14:35