ProHoster > Blog > Administrim > Si u bë i sigurt sinkronizimi i kohës

Si u bë i sigurt sinkronizimi i kohës

Si u bë i sigurt sinkronizimi i kohës
Si të bëni që koha per se të mos gabojë, nëse keni një milion pajisje të mëdha e të vogla që ndërveprojnë përmes TCP/IP? Sepse secila prej tyre ka orën e vet, ndërsa koha duhet të jetë e saktë në të gjitha. Këtë problem nuk mund ta shmangni pa ntp.

Le të imagjinojmë për një minutë se në një segment të infrastrukturës industriale IT kanë lindur probleme me sinkronizimin kohor të shërbimeve. Menjëherë fillon të dështojë stack-u i klasterit të software-it Enterprise, domenet shpërbëhen dhe nyjet master dhe Standby përpiqen më kot të rikthejnë status quo-në.

Mund të ndodhë gjithashtu që një sulmues të përpiqet qëllimisht të prishë kohën përmes një sulmi MiTM ose DDOS. Në një situatë të tillë mund të ndodhë gjithçka:

  • do tĂ« skadojnĂ« fjalĂ«kalimet e llogarive tĂ« pĂ«rdoruesve;
  • do tĂ« skadojnĂ« certifikatat X.509;
  • autentifikimi me dy faktorĂ« TOTP do tĂ« ndalojĂ« sĂ« funksionuari;
  • backup-et do tĂ« “vjetrohen” dhe sistemi do t’i fshijĂ«;
  • DNSSec do tĂ« prishet.

ËshtĂ« e qartĂ« se pothuajse çdo departament IT Ă«shtĂ« i interesuar pĂ«r funksionimin e qĂ«ndrueshĂ«m tĂ« shĂ«rbimeve tĂ« sinkronizimit tĂ« kohĂ«s, dhe do tĂ« ishte mirĂ« qĂ« ato tĂ« ishin tĂ« besueshme dhe tĂ« sigurta nĂ« pĂ«rdorim industrial.

Si të prishet NTP për 25 minuta

Protokollet e rrjetit — milenialĂ«t kanĂ« njĂ« veçori: ata prej kohĂ«sh janĂ« skaduar nuk vlejnĂ« mĂ« askund, por t’i zĂ«vendĂ«sosh nuk Ă«shtĂ« aq e lehtĂ« edhe kur krijohet njĂ« masĂ« kritike entuziastĂ«sh dhe financimi.

Ankesa kryesore ndaj NTP klasik është mungesa e mekanizmave të besueshëm mbrojtës kundër sulmeve të keqbërësve. Janë bërë përpjekje të ndryshme për ta zgjidhur këtë problem. Për këtë fillimisht u zbatua mekanizmi i çelësave të parainstaluar (PSK) për shkëmbimin e çelësave simetrikë.

FatkeqĂ«sisht, kjo qasje nuk e justifikoi veten pĂ«r njĂ« arsye tĂ« thjeshtĂ« — ajo shkallĂ«zohet dobĂ«t. KĂ«rkohet konfigurim manual nĂ« anĂ«n e klientit, nĂ« varĂ«si tĂ« serverit. Kjo do tĂ« thotĂ« se nuk mund tĂ« shtoni thjesht edhe njĂ« klient tjetĂ«r. NĂ«se ndryshon diçka nĂ« serverin NTP, duhet tĂ« rikonfiguroni tĂ« gjithĂ« klientĂ«t.

Më pas u shpik AutoKey, por shumë shpejt në të u zbuluan një sërë dobësish serioze në vetë dizajnin e algoritmit dhe prej tij u hoq dorë. E gjithë çështja është se numri fillestar (seed) përmban vetëm 32 bita; kjo është tepër pak dhe nuk ofron kompleksitet të mjaftueshëm llogaritës për një sulm bruteforce.

  • Key ID — çelĂ«s simetrik 32-bitĂ«sh;
  • MAC (message authentication code) — shuma e kontrollit e paketĂ«s NTP;

Autokey llogaritet si më poshtë.

Autokey=H(Sender-IP||Receiver-IP||KeyID||Cookie)

Ku H() është funksion hash kriptografik.

Për llogaritjen e shumës së kontrollit të paketës përdoret i njëjti funksion.

MAC=H(Autokey||NTP packet)

Kështu, rezulton se e gjithë integriteti i verifikimit të paketave mbështetet te autenticiteti i cookies. Duke i përvetësuar ato, mund të rikuperohet autokey dhe më pas të falsifikohet MAC. Megjithatë, serveri NTP gjatë gjenerimit të tyre përdor një numër fillestar (seed). Pikërisht këtu qëndron problemi.

Cookie=MSB_32(H(Client IP||Server IP||0||Server Seed))

Funksioni MSB_32 i pret 32 bitët më të lartë nga rezultati i llogaritjes së hash-it md5. Cookie i klientit nuk ndryshon për aq kohë sa parametrat e serverit mbeten të pandryshuar. Më pas sulmuesit i mbetet vetëm të rikuperojë numrin fillestar dhe të fitojë mundësinë të gjenerojë vetë cookies.

Së pari duhet të lidheni me serverin NTP si klient dhe të merrni cookie. Pas kësaj, me metodën e provës së të gjitha varianteve, sulmuesi rikuperon numrin fillestar duke ndjekur një algoritëm të thjeshtë.

Algoritmi i sulmit për llogaritjen e numrit fillestar me metodën brute force.

   for i=0:2^32 − 1 do
        Ci=H(Server-IP||Client-IP||0||i)
        if Ci=Cookie then
            return i
        end if 
    end for

Adresat IP dihen, kështu që mbetet vetëm të krijohen 2^32 hash-e derisa cookie i krijuar të përputhet me atë të marrë nga serveri NTP. Në një kompjuter të zakonshëm shtëpiak me Intel Core i5, kjo do të marrë 25 minuta.

NTS — Autokey i ri

Ishte e pamundur të pajtohej me vrima të tilla sigurie në Autokey dhe në vitin 2012 u shfaq versioni i ri protokolli. Për shkak të emrit të kompromentuar, u vendos të kryhej një rebrandim, ndaj Autokey v.2 u quajt Network Time Security.

Protokolli NTS është një zgjerim sigurie i NTP dhe aktualisht mbështet vetëm mënyrën unicast. Ai ofron mbrojtje të besueshme kriptografike kundër manipulimit të paketave, parandalon gjurmimin, shkallëzohet mirë, është rezistent ndaj humbjes së paketave në rrjet dhe sjell humbjet më të vogla të saktësisë që shfaqen gjatë mbrojtjes së lidhjes.

Lidhja NTS përbëhet nga dy faza, ku përdoren protokolle të nivelit më të ulët. Në fazën e parë klienti dhe serveri bien dakord për parametra të ndryshëm të lidhjes dhe shkëmbejnë cookies që përmbajnë çelësa me të gjithë grupin shoqërues të të dhënave. Në fazën e dytë Në këtë fazë zhvillohet vetë sesioni i mbrojtur NTS midis klientit dhe serverit NTP.

Si u bë i sigurt sinkronizimi i kohës

NTS pĂ«rbĂ«het nga dy protokolle tĂ« nivelit mĂ« tĂ« ulĂ«t: Network Time Security Key Exchange (NTS-KE), qĂ« inicializon njĂ« lidhje tĂ« sigurt mbi TLS, dhe NTPv4 — versioni mĂ« i fundit i protokollit NTP. MĂ« poshtĂ« e shpjegojmĂ« kĂ«tĂ« mĂ« nĂ« detaje.

Faza e parĂ« — NTS KE

Në këtë fazë, klienti NTP nis një sesion TLS 1.2/1.3 përmes një lidhjeje të veçantë TCP me serverin NTS KE. Gjatë këtij sesioni ndodh sa vijon.

  • PalĂ«t pĂ«rcaktojnĂ« parametrat AEAD tĂ« algoritmit pĂ«r fazĂ«n e dytĂ«.
  • PalĂ«t pĂ«rcaktojnĂ« protokollin e dytĂ« tĂ« nivelit mĂ« tĂ« ulĂ«t, por aktualisht mbĂ«shtetet vetĂ«m NTPv4.
  • PalĂ«t pĂ«rcaktojnĂ« adresĂ«n IP dhe portĂ«n e serverit NTP.
  • Serveri NTS KE lĂ«shon cookie pĂ«r NTPv4.
  • PalĂ«t nxjerrin nga materiali i cookie-ve njĂ« çift çelĂ«sash simetrikĂ« (C2S dhe S2C).

Kjo qasje ka një avantazh të madh: e gjithë ngarkesa e transmetimit të informacionit sekret dhe parametrave të lidhjes mbështetet te protokolli i provuar dhe i besueshëm TLS. Kështu, nuk ka nevojë të shpiket një zgjidhje e re për handshake-in e sigurt të NTP.

Faza e dytĂ« — NTP i mbrojtur nga NTS

Në fazën e dytë, klienti sinkronizon në mënyrë të sigurt kohën me serverin NTP. Për këtë qëllim, ai dërgon katër zgjerime të veçanta (extension field) në strukturën e paketës NTPv4.

  • Unique Identifier Extension pĂ«rmban njĂ« nonce tĂ« rastĂ«sishĂ«m pĂ«r tĂ« parandaluar sulmet me ripĂ«rsĂ«ritje.
  • NTS Cookie Extension pĂ«rmban njĂ« nga cookie-t NTP qĂ« klienti ka nĂ« dispozicion. MeqenĂ«se vetĂ«m klienti zotĂ«ron çelĂ«sat simetrikĂ« AEAD C2S dhe S2C, serveri NTP duhet t’i nxjerrĂ« ata nga materiali i cookie-ve.
  • NTS Cookie Placeholder Extension Ă«shtĂ« njĂ« mĂ«nyrĂ« qĂ« klienti tĂ« kĂ«rkojĂ« cookie shtesĂ« nga serveri. Ky zgjerim Ă«shtĂ« i nevojshĂ«m qĂ« pĂ«rgjigjja e serverit NTP tĂ« mos jetĂ« shumĂ« mĂ« e gjatĂ« se kĂ«rkesa. Kjo ndihmon nĂ« parandalimin e sulmeve tĂ« amplifikimit.
  • NTS Authenticator and Encrypted Extension Fields Extension pĂ«rmban shifrĂ«n e algoritmit AEAD me çelĂ«sin C2S, header-in NTP, vulat kohore dhe EF-tĂ« e pĂ«rmendura mĂ« sipĂ«r si tĂ« dhĂ«na shoqĂ«ruese. Pa kĂ«tĂ« zgjerim, Ă«shtĂ« e mundur tĂ« falsifikohen vulat kohore.

Si u bë i sigurt sinkronizimi i kohës

Pasi merr kërkesën nga klienti, serveri verifikon autenticitetin e paketës NTP. Për këtë, ai duhet të deshifrojë cookie-t dhe të nxjerrë algoritmin AEAD si edhe çelësat. Pas verifikimit të suksesshëm të vlefshmërisë së paketës NTP, serveri i përgjigjet klientit në formatin e mëposhtëm.

  • Unique Identifier Extension Ă«shtĂ« njĂ« kopje pasqyrĂ« e kĂ«rkesĂ«s sĂ« klientit, si masĂ« kundĂ«r sulmeve me ripĂ«rsĂ«ritje.
  • NTS Cookie Extension shton mĂ« shumĂ« cookie pĂ«r tĂ« vazhduar seancĂ«n.
  • NTS Authenticator and Encrypted Extension Fields Extension pĂ«rmban njĂ« shifĂ«r AEAD me çelĂ«s S2C.

Shtrëngimi i dytë i duarve mund të përsëritet shumë herë duke anashkaluar fazën e parë, sepse çdo kërkesë dhe përgjigje i jep klientit cookie shtesë. Kjo sjell avantazhin që operacionet TLS relativisht të kushtueshme për llogaritje dhe transmetim të të dhënave PKI ndahen në një numër kërkesash të përsëritura. Kjo është veçanërisht e përshtatshme për kronometra të specializuar FPGA, kur i gjithë funksionaliteti kryesor mund të përmblidhet në disa funksione nga fusha e kriptografisë simetrike, ndërsa i gjithë stack-u TLS i delegohet një pajisjeje tjetër.

NTPSec

ÇfarĂ« e bĂ«n NTP tĂ« veçantĂ«? Edhe pse autori i projektit Dave Mills u pĂ«rpoq ta dokumentonte kodin e tij sa mĂ« mirĂ«, pak programues do tĂ« arrijnĂ« tĂ« kuptojnĂ« ndĂ«rlikimet e algoritmeve tĂ« sinkronizimit tĂ« kohĂ«s tĂ« krijuara 35 vjet mĂ« parĂ«. NjĂ« pjesĂ« e kodit Ă«shtĂ« shkruar para epokĂ«s POSIX, dhe API i Unix atĂ«herĂ« ndryshonte ndjeshĂ«m nga ai qĂ« pĂ«rdoret sot. PĂ«rveç kĂ«saj, duhen njohuri statistikore pĂ«r tĂ« pastruar sinjalin nga ndĂ«rhyrjet nĂ« linja me shumĂ« zhurmĂ«.

NTS nuk ishte përpjekja e parë për të rregulluar NTP. Pasi sulmuesit mësuan të shfrytëzonin dobësitë e NTP për të amplifikuar sulmet DDoS, u bë e qartë se nevojiteshin ndryshime rrënjësore. Ndërsa draftet e NTS po përgatiteshin dhe përpunoheshin, National Science Foundation e SHBA-së në fund të vitit 2014 akordoi urgjentisht një grant për modernizimin e NTP.

Grupin e punĂ«s nuk e drejtonte kushdo, por Eric Steven Raymond — njĂ« nga themeluesit dhe figurat kyçe tĂ« komunitetit Open Source dhe autor i librit Katedralja dhe Pazari. Fillimisht, Eric dhe ekipi i tij u pĂ«rpoqĂ«n tĂ« transferonin kodin e NTP nga platforma BitKeeper nĂ« git, por kjo nuk rezultoi e mundur. UdhĂ«heqĂ«si i projektit Harlan Stenn ishte kundĂ«r kĂ«tij vendimi dhe negociatat ngecĂ«n. AtĂ«herĂ« u vendos tĂ« bĂ«hej njĂ« fork i kodit tĂ« projektit, dhe kĂ«shtu lindi NTPSec.

Me përvojë të gjerë, përfshirë punën në GPSD, me një bazë të fortë matematikore dhe me aftësinë pothuajse magjike për të lexuar kod të lashtë, Eric Raymond ishte pikërisht ai haker që mund ta çonte përpara një projekt të tillë. Në ekip u gjend edhe një specialist për migrimin e kodit dhe për vetëm 10 javë NTP u vendosnë GitLab. Puna mori vrull.

Ekipi i Eric Raymond iu qas punës njësoj si Auguste Rodin kur punonte me një bllok guri. Duke hequr 175 KLOC kod të vjetër, ata arritën ta zvogëlonin ndjeshëm sipërfaqen e sulmit, duke mbyllur shumë boshllëqe sigurie.

Ja një listë jo e plotë e asaj që u hoq:

  • Refclock tĂ« padokumentuara, tĂ« vjetruara ose tĂ« dĂ«mtuara.
  • Biblioteka e papĂ«rdorur ICS.
  • libopts/autogen.
  • Kod i vjetĂ«r pĂ«r Windows.
  • ntpdc.
  • Autokey.
  • Kodi C i ntpq u rishkrua nĂ« Python.
  • Kodi C i sntp/ntpdig u rishkrua nĂ« Python.

Përveç pastrimit të kodit, projekti kishte edhe objektiva të tjera. Ja një listë jo e plotë e arritjeve:

  • Mbrojtja e kodit nga tejmbushja e buffer-it u forcua ndjeshĂ«m. PĂ«r tĂ« parandaluar tejmbushjen e buffer-it, tĂ« gjitha funksionet e pasigurta tĂ« vargjeve (strcpy / strcat / strtok / sprintf / vsprintf / gets) u zĂ«vendĂ«suan me versione tĂ« sigurta qĂ« zbatojnĂ« kufizimin e madhĂ«sisĂ« sĂ« buffer-it.
  • U shtua mbĂ«shtetja pĂ«r NTS.
  • SaktĂ«sia e hapit kohor u rrit dhjetĂ«fish me anĂ« tĂ« lidhjes me pajisje fizike. Kjo lidhet me faktin se orĂ«t e kompjuterĂ«ve modernĂ« janĂ« bĂ«rĂ« shumĂ« mĂ« tĂ« sakta se ato qĂ« ekzistonin nĂ« kohĂ«n kur lindi NTP. PĂ«rfitimin mĂ« tĂ« madh e morĂ«n GPSDO dhe stacionet e dedikuara tĂ« radios pĂ«r kohĂ«n.
  • Numri i gjuhĂ«ve tĂ« programimit u reduktua nĂ« dy. NĂ« vend tĂ« skripteve Perl, awk dhe madje S, tani pĂ«rdoret kudo Python. Kjo sjell mĂ« shumĂ« mundĂ«si pĂ«r ripĂ«rdorimin e kodit.
  • NĂ« vend tĂ« rrĂ«mujĂ«s sĂ« skripteve autotools, projekti filloi tĂ« pĂ«rdorĂ« sistemin e ndĂ«rtimit tĂ« softuerit waf.
  • Dokumentacioni i projektit u pĂ«rditĂ«sua dhe u riorganizua. Nga njĂ« koleksion dokumentesh kontradiktore dhe herĂ«-herĂ« arkaike, u krijua njĂ« dokumentacion mjaft i mirĂ«. Tani çdo çelĂ«s i linjĂ«s sĂ« komandĂ«s dhe çdo entitet konfigurimi kanĂ« njĂ« burim tĂ« vetĂ«m tĂ« sĂ« vĂ«rtetĂ«s. PĂ«r mĂ« tepĂ«r, faqet e manualit dhe dokumentacioni web tani gjenerohen nga tĂ« njĂ«jtat skedarĂ« bazĂ«.

NTPSec është i disponueshëm për një sërë shpërndarjesh Linux. Aktualisht, versioni i fundit stabil është 1.1.8, ndërsa për Gentoo Linux është i parafundit.

(1:696)$ sudo emerge -av ntpsec
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild   R    ] net-misc/ntpsec-1.1.7-r1::gentoo  USE="samba seccomp -debug -doc -early -gdb -heat -libbsd -nist -ntpviz -rclock_arbiter -rclock_generic -rclock_gpsd -rclock_hpgps -rclock_jjy -rclock_local -rclock_modem -rclock_neoclock -rclock_nmea -rclock_oncore -rclock_pps -rclock_shm -rclock_spectracom -rclock_trimble -rclock_truetime -rclock_zyfer -smear -tests" PYTHON_TARGETS="python3_6" 0 KiB
Total: 1 package (1 reinstall), Size of downloads: 0 KiB
Would you like to merge these packages? [Yes/No]

Chrony

U bë edhe një përpjekje tjetër për të zëvendësuar NTP-në e vjetër me një alternativë më të sigurt. Ndryshe nga NTPSec, Chrony është shkruar nga e para dhe është projektuar për funksionim të qëndrueshëm në një gamë të gjerë kushtesh, përfshirë lidhje rrjeti të paqëndrueshme, disponueshmëri të pjesshme ose mbingarkesë të rrjetit, si edhe ndryshime të temperaturës. Përveç kësaj, chrony ka edhe përparësi të tjera:

  • chrony mund tĂ« sinkronizojĂ« mĂ« shpejt orĂ«n e sistemit me saktĂ«si mĂ« tĂ« lartĂ«;
  • chrony Ă«shtĂ« mĂ« i lehtĂ«, pĂ«rdor mĂ« pak memorie dhe ngarkon CPU-nĂ« vetĂ«m kur Ă«shtĂ« e nevojshme. Kjo Ă«shtĂ« njĂ« pĂ«rparĂ«si e madhe pĂ«r kursimin e burimeve dhe energjisĂ«;
  • chrony mbĂ«shtet shenjat kohore nĂ« nivel hardueri nĂ« Linux, gjĂ« qĂ« siguron sinkronizim jashtĂ«zakonisht tĂ« saktĂ« nĂ« rrjetet lokale.

Megjithatë, chrony nuk i ka disa funksione të NTP-së së vjetër, si klient/server me transmetim të gjerë dhe multicast. Përveç kësaj, NTP klasik mbështet një numër më të madh sistemesh operative dhe platformash.

Për të çaktivizuar funksionalitetin e serverit dhe kërkesat NTP ndaj procesit chronyd, mjafton të shtoni port 0 në skedarin chrony.conf. Kjo bëhet kur nuk ka nevojë të ofrohet koha për klientët NTP ose nyjet peer. Duke filluar nga versioni 2.0, porta e serverit NTP hapet vetëm kur qasja lejohet nga direktiva allow ose nga komanda përkatëse, ose kur është konfiguruar një nyje NTP peer, ose përdoret direktiva broadcast.

Programi përbëhet nga dy module.

  • chronyd Ă«shtĂ« njĂ« shĂ«rbim qĂ« funksionon nĂ« sfond. Ai merr informacion pĂ«r diferencĂ«n e orĂ«s sĂ« sistemit nga njĂ« server i jashtĂ«m kohe dhe korrigjon kohĂ«n lokale. Ai gjithashtu zbaton protokollin NTP dhe mund tĂ« funksionojĂ« si klient ose server.
  • chronyc Ă«shtĂ« njĂ« mjet i linjĂ«s sĂ« komandĂ«s pĂ«r monitorimin dhe kontrollin e programit. PĂ«rdoret pĂ«r rregullim tĂ« imĂ«t tĂ« parametrave tĂ« ndryshĂ«m tĂ« shĂ«rbimit; pĂ«r shembull, lejon shtimin ose heqjen e serverĂ«ve NTP ndĂ«rsa chronyd vazhdon tĂ« punojĂ«.

Duke filluar nga versioni 7 i RedHat Linux përdor chrony si shërbim për sinkronizimin e kohës. Paketa është gjithashtu e disponueshme për shpërndarjet e tjera Linux. Versioni i fundit stabil është 3.5, ndërsa v4.0 është në përgatitje për publikim.

(1:712)$ sudo emerge -av chrony
These are the packages that would be merged, in order:
Calculating dependencies... done!
[binary  N     ] net-misc/chrony-3.5-r2::gentoo  USE="adns caps cmdmon ipv6 ntp phc readline refclock rtc seccomp (-html) -libedit -pps (-selinux)" 246 KiB
Total: 1 package (1 new, 1 binary), Size of downloads: 246 KiB
Would you like to merge these packages? [Yes/No]

Si të konfiguroni serverin tuaj të largët Chrony në internet për sinkronizimin e kohës në rrjetin e zyrës. Më poshtë është një shembull konfigurimi në VPS.

Shembull i konfigurimit të Chrony në RHEL / CentOS në VPS

Tani le të praktikojmë pak dhe të ngremë serverin tonë NTP në VPS. Kjo është shumë e thjeshtë: mjafton të zgjidhni një plan të përshtatshëm në faqen e RuVDS, të merrni një server të gatshëm dhe të ekzekutoni rreth dhjetë komanda të thjeshta. Për qëllimet tona, ky opsion është plotësisht i përshtatshëm.

Si u bë i sigurt sinkronizimi i kohës

Kalojmë te konfigurimi i shërbimit dhe, si hap i parë, instalojmë paketën chrony.

[root@server ~]$ yum install chrony

RHEL 8 / CentOS 8 përdorin një menaxher tjetër paketash.

[root@server ~]$ dnf install chrony

Pas instalimit të chrony, duhet të nisni dhe aktivizoni shërbimin.

[root@server ~]$ systemctl enable chrony --now

Nëse dëshironi, mund të bëni ndryshime në /etc/chrony.conf duke zëvendësuar serverët NPT me ata lokalë më të afërt për të ulur kohën e përgjigjes.

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server 0.ru.pool.ntp.org iburst
server 1.ru.pool.ntp.org iburst
server 2.ru.pool.ntp.org iburst
server 3.ru.pool.ntp.org iburst

Më tej konfigurojmë sinkronizimin e serverit NTP me nyjet nga pool-i i specifikuar.

[root@server ~]$ timedatectl set-ntp true
[root@server ~]$ systemctl restart chronyd.service

Duhet gjithashtu të hapni portën NTP për qasje nga jashtë, përndryshe firewall-i do të bllokojë lidhjet hyrëse nga nyjet kliente.

[root@server ~]$ firewall-cmd --add-service=ntp --permanent 
[root@server ~]$ firewall-cmd --reload

Në anën e klientit mjafton të caktoni saktë zonën kohore.

[root@client ~]$ timedatectl set-timezone Europe/Moscow

Në skedarin /etc/chrony.conf tregoni IP-në ose emrin e hostit të serverit tonë VPS, në të cilin është nisur serveri NTP Chrony.

server my.vps.server

Dhe në fund, nisja e sinkronizimit të kohës në klient.

[root@client ~]$ systemctl enable --now chronyd
[root@client ~]$ timedatectl set-ntp true

Herën tjetër do të tregoj se cilat janë opsionet për sinkronizimin e kohës pa internet.

Si u bë i sigurt sinkronizimi i kohës

Si u bë i sigurt sinkronizimi i kohës

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster