Archive for March, 2018

How to stop your PC from automatically restarting after installing updates

Important: Before proceeding note that this is a workaround not supported by Microsoft, and it can stop working at any time. You should use it at your own risk.

  1. Open Start.
  2. Search for Task Scheduler and click the result to open the tool.
  3. Right-click the Reboot task and select Disable.

Once you completed the steps, your device will no longer restart after downloading and installing new updates. However, new updates won’t apply, and future updates won’t install until you manually reboot your computer.

Additional steps (if needed)

In the case, Windows 10 automatically re-enables the Reboot task; you can stop this behavior by doing the following:

  1. Use the Windows key + R keyboard shortcut to open the Run command.
  2. Type the following path and click OK:

    %windir%System32TasksMicrosoftWindowsUpdateOrchestrator

  3. Select the Reboot file without an extension, right-click it, and select Rename.

  4. Rename the Reboot file to Reboot.old.
  5. Right-click inside the folder, select New, and click on Folder.

After you’ve completed the steps, Windows 10 will no longer be able to re-create the task to reboot your computer automatically.

If you want to revert the changes, go back to the UpdateOrchestrator folder and delete the Reboot folder and rename the Reboot.old file back to Reboot.

Then follow the Task Scheduler steps mentioned above but on Step 3 select Enable.

Note: We’re not saying that you should skip installing updates, as they’re important to keep your device secure and up to date. However, there are scenarios where you make want to take full control and decide exactly when to restart your computer to apply new updates, and this is when knowing how to stop automatic reboots comes in handy.

Google Cloud SSH Keys

| March 2nd, 2018
You can manage persistent SSH keys in one of two ways:
METHOD 1:  gcloud
1A.  You can use the gcloud command line tool to create a key pair for you.  Provided you’ve authenticated to gcloud as an IAM user with the compute instance admin role, it will create keys for you the first time you SSH into an instance in your project.  Here’s an example walkthrough:
gcloud auth list # Make sure you’re logged in as the correct IAM user.
 
# If not logged in as the right IAM user:
gcloud auth revoke –all
gcloud auth login [your-iam-user]
gcloud compute ssh [NAME-OF-RUNNING-INSTANCE]
1B.  If you’ve never connected via SSH using gcloud, it will create a private key and prompt you for an optional passphrase.  It creates a public key as well and uploads that to project metadata (ssh-keys).  If the instance to which you’re connecting has the “block project wide SSH keys” set, the public key is uploaded to the instance’s metadata (also ssh-keys, but visible in the Cloud Console for the particular instance).  The private key is kept locally on your computer, in your home directory.  These are the filesystem locations for your private and public keys:
~/.ssh/google_compute_engine # private key
~/.ssh/google_compute_engine.pub # public key
1C.  As you can see, the private key is stored in your home directory, on your computer.  If you share it, someone who knows your IAM user name can use it to SSH into the instance.  If you lose it, you can have gcloud recreate it by deleting the corresponding public key.  In general, deleting these keys will force them to be re-created and project/instance metadata for ssh-keys will be updated to hold the new public key.

METHOD 2:  Roll your own…

With the previous example, gcloud controls access to your instances by IAM user role.  Any compute instance admin can generate key pairs, with the public keys written to project/instance metadata, and picked up by the Linux Guest Environment (which includes the Google Accounts Daemon).

But you can also leverage project/instance metadata and the Accounts Daemon to distribute your own public keys.  This is useful if you have established systems for users to create their own key material, or if you have users who just need to SSH into some instances.  Here’s a walkthrough:

2A.  You or your users would generate SSH key pairs in the usual way, using ssh-keygen [1][2].  Your user keeps track of his/her private key.

2B.  Format the public key [3] so it matches one of these patterns:

ssh-rsa [KEY_VALUE] [USERNAME] # for keys that do not expire

ssh-rsa [KEY_VALUE] google-ssh {“userName”:”[USERNAME]”,”expireOn”:”[EXPIRE_TIME]”} # for keys that you want to expire
2C.  Add the formatted public key to project or instance ssh-keys metadata [4].  This must be done by an IAM user with the compute instance admin role, but you can control the deployment of the key to just some instances, etc.  Again, this is a great way to leverage existing conventions in places where you may have users who just need to SSH into their instances.
MORE TO KEEP IN MIND
* SSH access requires that instances have public IP addresses unless you’ve connected to your VPC network via a VPN connection [5] or if you use another instance as a SSH bastion [6].
* SSH access can be blocked by firewall rules you define on your VPC network.
* In both cases, even where you add SSH keys yourself, you must have a working Linux Guest Environment.  This includes the Accounts Daemon, which is responsible for picking up the metadata.  Without that, defining SSH keys in instance metadata will have no effect on instances.  All instance images provided by Google have either the Google Linux Guest Environment or an equivalent (as is the case for CoreOS), so this is usually only a concern if you import images and need to install the Guest Environment manually.