{{Header}} {{#seo: |description=A reasonably accurate host clock is required for many general security properties. An inaccurate clock can lead to broken internet connectivity and time related security issues. |image=TineSynchronization2134234.jpg }} [[image:TineSynchronization2134234.jpg|thumb]] {{intro| A reasonably accurate host clock is required for many general security properties. An inaccurate clock can lead to broken internet connectivity and time related security issues. }} = Introduction = It is recommended to have a host clock with accuracy of up to ± 30 minutes. Clocks that are days, weeks, months or even years slow or fast can lead to many issues such as connectivity problems with Tor, inability to download operating system upgrades. Due to invalid (not yet or no longer valid) TLS certificates. Follow the platform-specific recommendations below to avoid Tor connectivity problems and to limit possible adverse security impacts. = All Platforms = If the host clock is more than 1 hour in the past or more than 3 hours in the future, Tor cannot connect. In this case, manually fix the host clock by right-clicking on it, and also check for an empty battery. * If using {{project_name_long}} as a host operating system: Reboot. (Easiest.) * If using a VM: Then, power off and power on {{project_name_gateway_long}} and Tor should be able to reconnect. * Due to [[Network_Time_Synchronization#Block_Networking_until_sdwdate_Finishes|Block Networking until sdwdate Finishes]] if Tor failed or took too long to connect, then you need to fix Tor connection first and then restart your sdwdate sudo systemctl restart sdwdate in your VM/Qube. = Easy instructions = {{non_q_project_name_short}} in VMs or as a host operating system: It is strongly discouraged to use the pause / suspend / save / hibernate features. {{q_project_name_long}} VMs: It is strongly discouraged to use the pause feature of Qube Manager, but it is is safe to use the suspend or hibernate feature of dom0. = Advanced instructions =
If you are interested in using the pause / suspend / save / hibernate features, please click the expand button for further instructions.
'''{{project_name_workstation_long}} as a host operating system or VM''': * It is strongly discouraged to pause / suspend / save / hibernate {{project_name_short}}. If this advice is ignored, [[#Restart sdwdate|restart sdwdate]] after resume. Similarly, if users suspend or save the {{project_name_workstation_short}} state, the clock will again lag behind the correct value. This can be manually fixed by running: Start MenuApplicationsSystemTime Synchronization Monitor (sdwdate-gui)restart sdwdate. '''{{q_project_name_short}}''': * VM: It is strongly discouraged to pause {{project_name_workstation_short}} VMs using the pause feature of Qube Manager. If this advice is ignored, [[#Restart sdwdate|restart sdwdate]] after resume. Qubes does not dispatch the /etc/qubes/suspend-post.d / /etc/qubes/suspend-pre.d hooks upon pause / resume using Qube Manager. * dom0 suspend / hibernate: It is safe to use the suspend or hibernate feature of dom0 and a manual restart of sdwdate is unnecessary. https://github.com/QubesOS/qubes-issues/issues/1764
= Restart sdwdate = To restart sdwdate. Start MenuApplicationsSystemTime Synchronization Monitor (sdwdate-gui)restart sdwdate Or in a terminal. Simplified in next upgrade. {{CodeSelect|code= sudo sdwdate-clock-jump }} {{CodeSelect|code= sudo /usr/lib/sdwdate/restart_fresh }} = Manually Set Clock Time and Date = Usually not required. In case [[Sdwdate|sdwdate]] fails to properly randomize the system clock, it is possible to manually set a random value. The first step should be completed on the host to ensure the host clock is set to the correct time. {{Box|text= '''1.''' On the host ([[Qubes|{{q_project_name_short}}]]: dom0), run the following command to report the time in UTC. {{CodeSelect|code= date -u }} The output should be similar to the following. {{CodeSelect|code= Mon Apr 22 04:30:44 UTC 2019 }} {{CodeSelect|code= {{CURRENTMONTHABBREV}} {{CURRENTDAY2}} {{CURRENTTIME}}:44 UTC {{CURRENTYEAR}} }} '''2.''' Set the correct time in {{project_name_gateway_short}}. Run the following command with the correct date and time parameters. A non-zero exit codes signifies an error, while 0 means it succeeded. Also see: {{CodeSelect|code= man clock-random-manual-gui }} {{CodeSelect|code= man clock-random-manual-cli }} * clock-random-manual-gui: a randomized clock setting (in UTC) is entered via a GUI. * clock-random-manual-cli: a randomized clock setting (in UTC) is entered on the command line. For example {{CodeSelect|code= echo "Sat Oct 26 07:18:25 UTC 2019" {{!}} /usr/bin/clock-random-manual-cli }} : {{CodeSelect|code= echo "{{CURRENTMONTHABBREV}} {{CURRENTDAY2}} {{CURRENTTIME}}:44 UTC {{CURRENTYEAR}}" {{!}} sudo clock-random-manual-cli }} '''3.''' Restart sdwdate. {{CodeSelect|code= sudo service sdwdate restart }} '''4.''' If Tor is still not functional, try restarting Tor. {{CodeSelect|code= sudo service tor restart }} Tor should work once correct clock values are set, but that can be manually tested with [[systemcheck]]. }} = Block Networking until sdwdate Finishes = [[Sdwdate|sdwdate]] is a Tor-friendly replacement for rdate and ntpdate that sets the system's clock by communicating via end-to-end encrypted TCP with Tor onion webservers. Since timekeeping is crucial for security, blocking network access until sdwdate succeeds is sensible. https://forums.whonix.org/t/blocking-networking-until-sdwdate-finished/5372 Note: When using this feature, there will be no internet connectivity until sdwdate succeeded which could take approximately 2 minutes. How to enable this feature? [[Unsupported]]. This feature is has not been implemented yet for {{project_name_short}}. Developers are welcome to contribute to {{project_name_short}}. = Summary = '''Table:''' ''Network Time Synchonization Summary'' {| class="wikitable" |- ! scope="col"| '''Platform''' ! scope="col"| '''Recommendations''' |- ! scope="row"| All Platforms | * Tor cannot connect if the host clock is grossly inaccurate. In this case, users should manually fix the host clock before powering the {{project_name_gateway_short}} off and on again. * Periodically check the host clock to ensure that it is accurate or approximately so. * For greater security, [[#Block_Networking_until_sdwdate_Finishes|block networking until sdwdate finishes]]. |- ! scope="row"| {{non_q_project_name_short}} | * It is strongly discouraged to use the pause / suspend / save / hibernate features. |- ! scope="row"| {{q_project_name_short}} | * It is strongly discouraged to use the pause feature of Qube Manager. * it is is safe to use the suspend or hibernate feature of dom0. |} = Appendix = == Deactivate Automatic TimeSync == {{mbox | image = [[File:Ambox_warning_pn.svg.png|40px]] | text = '''Warning:''' This action is recommended against and is usually not required. In all cases, first check with the {{project_name_short}} developers. }} To deactivate sdwdate, run. {{CodeSelect|code= sudo service sdwdate stop }} {{CodeSelect|code= sudo systemctl mask sdwdate }} = Related = * [[Timezone]] * [[sdwdate]] * [[sdwdate-gui]] * [[Boot Clock Randomization]] * [[Time Attacks]] * [[Dev/sdwdate]] * [[Dev/TimeSync]] = Footnotes = {{reflist|close=1}} {{Footer}} [[Category:Documentation]]