CentOS 7 и выше

В Centos/Redhat 7 для синхронизации времени по умолчанию используется служба chrony.
Службу ntp лучше отключить во избежании сбоев

Как и ntp, chrony выступает в качестве клиента и/или сервера синхронизации, в зависимости от настроек в /etc/chrony.conf

Порядок действий

1. Укажите свой сервер для получения времени, например с IP-адреса 172.29.16.201:

server 172.16.0.1

Допускается указание нескольких серверов, служба сама выберет наиболее подходящий по доверию/доступности

server 172.16.29.202 iburst
server 172.16.29.203 iburst
server 172.16.29.204 iburst

2. Разрешите работу в качестве сервера и указать, от каких подсетей принимать запросы: 

Например:

allow 192.168/16
allow 10/8
allow 172.16.0.2

3. Перезапустите службу:

systemctl restart chronyd

4. Проверьте состояние службы

systemctl status chronyd

Дополнительно

Посмотр источников для синхронизации времени

chronyc sources

Посмотреть текущее состояние синхронизации

chronyc tracking

CentOS 6 и ниже

За синхронизацию времени отвечает служба ntpd. Она работает одновременно как клиент, так и сервер. Настройки хранятся в файле /etc/ntp.conf . Чтобы добавить/изменить ntp-сервер для синхронизации, используем параметр server. Допускается указание нескольких серверов, служба сама выберет наиболее подходящий по доверию/доступности:

server 10.99.0.1
server 10.99.0.2
server your_ntp_server

После внесения изменения нужно перезапустить службу:

[root@URKHOV ~]# service ntpd restart

Синхронизация может не работать по нескольких причинам.

Смотрим логи. По умолчанию ntp пишет в системный лог /var/log/messages:

[root@URKHOV ~]# tail /var/log/messages
May 25 16:40:13 URKHOV ntpd[25343]: sendto(10.99.0.1) (fd=-1): Bad file descriptor
May 25 16:40:13 URKHOV ntpd[25343]: sendto(10.99.0.2) (fd=-1): Bad file descriptor
May 25 16:41:16 URKHOV ntpd[25343]: sendto(10.99.0.2) (fd=-1): Bad file descriptor
[root@URKHOV ~]#

Эта ошибка возникает, если запущено несколько копий ntp и они конфликтуют между собой:

[root@URKHOV ~]# ps aux |grep ntpd
ntp       3498  0.0  0.0  23412  5048 ?        SLs  Apr21   2:36 ntpd -u ntp:ntp -p /var/run/ntpd.pid -g
root     25343  0.0  0.0  24304  5940 ?        SLs  16:38   0:00 ntpd
root     25757  0.0  0.0  63268   824 pts/1    S+   16:40   0:00 grep ntpd
[root@URKHOV ~]#

Убьем лишний процесс:

[root@URKHOV ~]# kill -9 25343
[root@URKHOV ~]#

Ошибка в логах исчезнет, но синхронизация по-прежнему не работает. Тут есть нюанс - служба ntp после перезапуска не пытается немедленно синхронизироваться. Ей требуется определенное время(10-15мин), чтобы проанализировать работу системного таймера и потом выполнить надстройку. Чтоб заставить службу вызвать немедленную синхронизацию, остановим службу и запустим демон с ключами, которые вызовут попытку немедленной синхронизации и выход:

[root@URKHOV ~]# service ntpd stop
[root@URKHOV ~]# ntpd -q -g

Смотрим /var/log/messages и видим ошибку "no reply: clock not set"

Первая мысль - не проходят пакеты через фаерволл. Это можно проверить, запросив статус серверов у службы через утилиту ntpq , если udp-порт 123 открыт, значения reach, delay, offset не должны быть нулевыми:

[root@URKHOV ~]# service ntpd start
[root@URKHOV ~]# ntpq -pn 127.0.0.1
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*mng2.t5.fi      10.99.0.1    2 u  995 1024  377   12.432    0.133   0.276
+ns2.posiona.net 10.99.0.2    2 u  837 1024  377   14.298    0.765   0.089
 LOCAL(0)        .LOCL.                           1 l   32   64  377    0.000    0.000   0.001
[root@URKHOV ~]#

"*" - означает сервер, с которым последний раз была синхронизация.

"+" - можно использовать для синхронизации.

"-' - не рекомендуется для использования

В нашем случае пакеты проходят. Попробуем другой способ ручной синхронизации через утилиту ntpdate, службу ntp предварительно нужно выключить:

[root@URKHOV ~]# service ntpd stop
[root@URKHOV ~]# ntpdate 10.99.0.1
25 May 17:05:54 ntpdate[670]: adjust time server 10.99.0.1 offset -0.000204 sec
[root@URKHOV ~]#

Время синхронизировалось. Дело в том, что утилита ntpdate использует иные механизмы синхронизации времени. Что касается службы, несмотря на то, что обратный ответ от внутренненго сервера приходит(мы это посмотрели через ntpq), служба отказывается принимать данные в качестве достоверного источника точного времени, хотя и явно об этом не сообщает. Это может быть связано с настройками удаленного ntp-сервера, политиками безопасности, если это win-сервер.

Попробуем указать в качестве источника внешний сервер в /etc/ntp.conf:

server 0.centos.pool.ntp.org

Запустим разовую проверку:

[root@URKHOV ~]# ntpd -q -g

Как видим, с этим сервером служба оказалась сговорчивее.