How to Install screen on RHEL/CentOS 8

screen was included in the default repositories distributed with RHEL/CentOS 7 and earlier. Since RHEL/CentOS 8 it is now necessary to configure the Extra Packages for Enterprise Linux (EPEL) repos, which you're probably going to need eventually anyway.

dnf install epel-release

Now you can install screen as usual:

dnf install screen

Basic NFS Server and Client on RHEL/CentOS, Debian/Ubuntu and Derivatives


Install the NFS utilities, start and configure the service to run automatically on boot:

dnf install nfs-utils nfs4-acl-tools systemctl enable nfs-server.service systemctl start nfs-server.service

To configure firewalld to permit network access to the NFS services run:
firewall-cmd --permanent --add-service=nfs firewall-cmd --permanent --add-service=rpc-bind firewall-cmd --permanent --add-service=mountd firewall-cmd --reload

apt install nfs-kernel-server rpcbind systemctl enable nfs-kernel-server systemctl start nfs-kernel-server

To configure ufw to permit network access to the NFS services run:
ufw allow from to any port nfs ufw enable

Configuration files are located at /etc/nfs.conf and /etc/nfsmount.conf.

Create or edit /etc/exports:
/mnt/share1 /mnt/share2,async) /mnt/share3,sync) /mnt/share4,sync,no_all_squash,root_squash)

Specify the single IP address or range in CIDR notation that a share should be accessible to followed by its options in (brackets).

See man exports for detailed information about per-share configuration options.

To reload the exports configuration live, run:
exportfs -ar

To configure disk quotas please see Mass Virtual Hosting Part Three: Disk Quotas (including NFS).


dnf install nfs-utils nfs4-acl-tools

apt install nfs-common

To view the exported shares on the remote server:
showmount -e

To mount a remote share:
mount -t nfs /mnt/shared

To add a remote share to fstab (automatically mount at boot, simplified mount /mountpoint): /mnt/shared nfs defaults 0 0

Basic Network Interface Confguration with NetworkManager via nmcli


I have always favoured directly editing network configuration flat files (e.g: /etc/sysconfig/network-scripts/ifcfg-ifname on RedHat flavours). However it has for some time been more ideologically correct to manage the network configuration on many distributions via the NetworkManager daemon. More importantly, it is intrusive and obnoxious and annoying to disable such that it does not interfere with manual configurations (lookin' at you, Ubuntu). So this is my attempt to find religion.

Unless there is good reason I don't do GUIs on servers. nmcli is provided to interface with NetworkManager from the command line. It can be used in CLI (direct) or shell (interactive) mode, as root/via sudo:


nmcli connection modify eth0 IPv4.address nmcli connection modify eth0 IPv4.gateway nmcli connection modify eth0 IPv4.dns,, nmcli connection modify eth0 IPv4.method manual

To effect the changes you must raise or reload the interface, using nmcli:
nmcli connection up eth0
or on RedHat flavours simply:
ifup eth0

Note the following:

  • The interface's address is specified in CIDR notation (i.e. including the netmask)
  • Arrays of multiple addresses are defined as comma-delimited lists (e.g: IP1,IP2,IP3). Take care to not include spaces.

The IPv4.method property can be set to any one of: disabled, auto (dhcp), manual or link-local. For a complete list of IPv4 configuration options please see https://developer.gnome.org/NetworkManager/stable/settings-ipv4.html.

IPv6 is configured in the same way; see https://developer.gnome.org/NetworkManager/stable/settings-ipv6.html for IPv6 configuration options and modify your syntax accordingly.


As root/via sudo:
nmcli connection edit eth0 ===| nmcli interactive connection editor |=== Editing existing '802-3-ethernet' connection: 'eth0' Type 'help' or '?' for available commands. Type 'print' to show all the connection properties. Type 'describe [.]' for detailed property descrIPtion. You may edit the following settings: connection, 802-3-ethernet (ethernet), 802-1x, dcb, sriov, ethtool, match, IPv4, IPv6, tc, proxy nmcli> set IPv4.address nmcli> set IPv4.gateway nmcli> set IPv4.dns,, nmcli> set IPv4.method manual nmcli> save Connection 'eth0' successfully updated. nmcli> quit

Again the connection must either be reloaded or raised to take effect:
nmcli connection up eth0 or ifup eth0

Installing Windows to a Qubes VM: A Detailed Guide

This article is a quick step-by-step for installing Windows 10 and 7 x64 HVM virtual machines under Qubes 4.x. It incorporates procedures and optimizations from multiple sources and my own modifications, clarifications and additions.

The official documentation is available at:

If you choose to use the original documentation I would point out five important items where I differ:

  • You are instructed to change the virtualized graphics adapter to cirrus for the duration of Windows 7 installation:
    qvm-features vmname video-model cirrus
    Then switch back to the default adapter to enable resolutions greater than 1024x768:
    qvm-features --unset vmname video-model
    This was not my experience on Qubes 4.0. Indeed, it does not seem necessary to use CLI tools to configure the VM at all, with one caveat we will reach near the end.
  • It is suggested that you disable the DHCP client service because it "makes no sense in a VM context" however, until qubes-windows-tools is installed, DHCP is used by Qubes to autoconfigure VM networking. Disabling this service will result in no connectivity upon reboot, unless you have configured the interface statically. Since you are advised to complete all Windows Updates before installing qubes-windows-tools I recommend leaving it alone. Once the tools are installed it can be safely disabled.
  • The documentation recommends creating a System image at least 30GB in size. I strongly recommend a minimum of 40GB; before running disk cleanup by the time you have installed all of the updates for Windows 7 you will exceed 30GB and find yourself wanting for application storage.
  • Contrary to the documentation, seamless mode is not enabled automatically by installing qubes-windows-tools. A manual registry edit is necessary, which is covered in the following procedures.
  • It is recommended that you clone your VM after each Windows Update cycle. I find that excessive; if you are working with unlimited storage it certainly can't hurt but I had no issues updating Windows 7. I do recommend making clones:
    • After setup is complete (i.e. the explorer shell (desktop) has loaded)
    • After applying all Windows Updates and performing all optimization steps (see lower section of main list)
    • After activating
    • After installing and configuring all of your essential applications and Windows settings (everything you want to be on every VM you spawn from this installation)

Note: at present qubes-windows-tools supports 64-bit versions of Windows 7 and up, but gui-agent (auxiliary support for arbitrary screen resolution and seamless mode) requires exactly Windows 7. That means you will be missing a substantial feature set if installing another version. The installation procedure is essentially the same for all versions, version-specific notes follow at the end of the list.

  • Install sudo qubes-dom0-update qubes-windows-tools to dom0:
    sudo qubes-dom0-update qubes-windows-tools
  • All Versions - Installation
    • Have the ISO image downloaded in some qube.
    • Create a new Qube:
      • Color: black
      • Standalone Qube not based on a template
      • Networking: sys-firewall (default)
      • Launch settings after creation: check
      • Click “OK”.
    • Settings:
      • Basic:
        • System storage: 40000+ MB
      • Advanced:
        • Include in memory balancing: uncheck
        • Initial memory: 4096+ MB
        • Kernel: None
        • Mode: HVM
      • Click “Apply”.
      • Click “Boot from CDROM”:
        • “from file in qube”:
          • Select the qube that has the ISO.
          • Select ISO by clicking “…”.
          • The Qube containing the image will be started; bear this in mind if you are working with limited resources and consider downloading/storing the image to a VM you would have running during this hours-long process anyway. The Qube can be shut down (i.e. through the Qube Manager or CLI) after the Windows Qube's first reboot during installation to free up resources. It will not shut down automatically.
        • Click “OK” to boot into the windows installer.
    • Windows Installer:
      • Mostly as usual, but automatic reboots will halt the qube - just restart
        it again and again until the installation is finished.
      • Install on first disk.
      • Windows license may be read from flash via root in dom0:

        strings < /sys/firmware/acpi/tables/MSDM

        For Windows 10 you can also try a Windows 7 license key (as of 2018/11 they are still accepted for a free upgrade).

        Installed Windows and all updates, then enter the license key.

    • Afterwards:
      • In case you switch from sys-network to sys-whonix, you’ll need a static IP network configuration, DHCP won’t work for sys-whonix.
      • Launch the command line in Administrator mode and use powercfg -H off and disk cleanup to save some disk space.
    • Press the shift key five times. This will enable Sticky keys, allowing you to press the control, alt, shift and meta keys one-after-the-other to activate key combos instead of holding them down. This will make sending keyboard shortcuts (Alt+F4, CTRL+ALT+DEL, etc) from Qubes much less prone to being captured by dom0. This becomes especially important in those occasions where you lose cursor input.
    • Clone the Qube so you can always start over from square one.
  • Windows 7
    • Do not provide a password during setup if you would like to ensure automatic login
    • I advise disabling automatic updates as they will consume background resources at inconvenient times and cause unexpectedly lengthened startups and shutdowns. You will have to remember to manually update when appropriate.
    • You can reduce the allocated RAM to 2048MB.
    • Adjust the display resolution.
    • Changing the theme to Windows Classic (Control Panel > Personalization > Basic and High Contrast Themes) will improve performance.
    • Control Panel > Performance Information and Tools
      • Adjust visual effects > Visual Effects: Check the Adjust for best performance radio button.
    • Perform activation.
    • Right click on the taskbar and select properties. Check Use small icons to make better use of display space.
    • Open Control Panel > Add/Remove Programs and click on Turn Windows features on or off. Remove unnecessary components (i.e. Games) to increase disk space. Add any desired missing components. I like:
      • Print and Document Services > LPD Print Service, LPR Port Monitor, Scan Management
      • Services for NFS
      • Simple Network Management Protocol (SNMP)
      • Subsystem for UNIX-based Applications
      • Telnet Client
      • TFTP Client
      • Telnet Client
    • Manually run Windows Update.
    • Run msconfig. Disable all unnecessary services.
      Recommendations from the Qubes documentation:

      • Base Filtering Engine (only required if you want to use Microsoft IPSEC)
      • The documentation recommends that you disable DHCP Client however I encourage you to keep it to use the Qubes networking out of the box, otherwise you will be forced to muck about with static addresses and sys-firewall. Under Control Panel > Netowrk and Sharing Center you will see Identifying... under View your active networks where it should indicate Public/Home/Work network type until you have a working configuration. Once the qubes-windows-tools are installed networking is managed by Qubes and it is safe to disable the service. At that point your Network Location will always show as Identifying... but still work; attempting to change the network location will result in an error or crash.
      • Function Discovery Provider Host
      • Peer Name Resolution Protocol
      • Peer Netwoking Grouping
      • Peer Networking Identity Manager
      • SSDP Discovery
      • TCP/IP Netbios Helper
      • Themes

      My recommendations (sorted by Status, ascending):

      • Computer Browser
      • LPD Service (if you installed it and are not using UNIX printing at this time)
      • Client for NFS (ibid)
      • SNMP Service (ibid)
      • SNMP Trap
      • Print Spooler (if not using print services at this time)
      • Power
      • UPnP Device Host
      • Windows Media Player Network Sharing Service
      • Bluetooth Support Service
      • Disk Defragmenter
      • Fax
      • Adaptive Brightness
      • Telephony
      • Parental Controls
      • Volume Shadow Copy (will reduce disk i/o at the expense of Restore Points but that's what Qube Cloning is for)
    • The qubes-windows-tools ISO has a very important README file that you should read and follow before installing the PV drivers:

      I. Installing Qubes Windows Tools

      Qubes Windows Tools are currently supported on 64-bit Windows (7 or
      newer), but gui-agent (auxiliary support for arbitrary screen resolution and seamless
      mode) requires exactly Windows 7.

      How to prepare for Windows 7 installation
      In order to install gui-agent on Windows 7, disable driver
      signature checking policy, as the current drivers are only self-signed. In
      order to disable driver signing requirement (in the Windows VM):

      1) Start command prompt as Administrator Mode, i.e. right click on the Command
      Prompt icon and choose "Run as administrator".

      2) In the command prompt type:
      bcdedit /set testsigning on

      3) Reboot your Windows VM.

      Installing Qubes Windows Tools

      Run the .exe file from this virtual CDROM. Installation may require a few
      reboots, especially in case of an upgrade -- make sure the process is
      completed before using the VM (this is especially important for VM templates).

      * During the installation, you will be prompted to allow installation of
      multiple drivers, signed by The Linux Foundation -- allow that.

      * In some situations, you might be prompted to format a "Qubes Private
      Image" -- cancel that prompt.

      * Some of Xen PV drivers will request a system restart during the
      installation -- answer "No" there
      , and reboot the system only after the
      whole installation.

      II. Known issues

      1) The Xen PV disk driver is disabled by default. This is because it causes
      a BSOD after installation in Qubes. However, it seems to work fine after
      that, so you may want to use it (for better performance and the ability
      to use qvm-block). MAKE SURE TO BACK UP YOUR VM FIRST in case something
      goes very wrong.

      2) Windows shows an exclamation mark on the network icon in the system tray,
      but this is only a cosmetic issue (network configuration is being set

      • Boot the windows VM with the qubes-windows-tools installer software loaded in the virtual CD drive:
        qvm-start vmname --install-windows-tools
      • One critical thing the documentation does not point out is that if you do not install the Xen PV Disk Drivers you will not have the option to install them in a second run of the setup tool. Your only options when you re-run the tool are Repair and Uninstall and Repair is an entirely automatic process. Make sure you have a clone available to restore from in case anything goes wrong.
      • The documentation indicates that the PV Disk Drivers cause Qubes to BSoD after the first boot. This was not my experience.
      • One of the installed components is Move user profiles which

        Moves user profiles directory (C:\Users) to the HVM's private disk (private.img)

        The prepare-volume utility will automatically format the drive backed by private.img on the first boot after installing qubes-windows-tools if you have installed the PV Disk Drivers. If you have not installed them or if you want to skip straight to what would be the second boot where relocate-dir will move the C:\Users directory to the second disk you may format it yourself now. If you have any additional unformatted disks I suggest that it would be a good idea to format them before proceeding.

        • Control Panel > Computer Management
          • Computer Management (Local) > Storage > Disk Management
          • You will be asked to initialize additional disks. You may select MBR or GPT; due to the comparative simplicity of using CLI tools to manage MBR disks from the CLI external to the VM I suggest MBR.
          • Right click on the initialized disk(s) and select New Simple Volume... to launch the wizard.
      • After installing qubes-windows-tools when the VM has halted it is critical that you increase the qrexec_timeout from 60 to something like 300. Your machine may be fast enough to launch Windows in under 60 seconds but these are the consequences I dealt with for having not followed this step:
        • The VM failed to boot with the following message:

          Cannot connect to qrexec agent for 60 seconds, see /var/log/xen/console/guest-vmname.log for details

        • The log file was completely empty. This ocurred regardless of whether or not I installed the PV Disk Drivers. I noticed under Qube settings > Advanced that the Include in memory balancing checkbox had been enabled without my intervention. Unchecking the checkbox and increasing the amount of Initial memory did nothing to solve the issue. While memory ballooning is technically supported by Windows after installing the tools I found my VM crashed constantly with this feature enabled.
        • xl top indicated heavy CPU utilization and there appeared to be heavy corresponding disk i/o. I theorized that Windows might be taking longer to load and that seamless gui mode was preventing me from seeing the activity. I increased the qrexec_timeout thus:
          qvm-prefs vmname qrexec_timeout 300
        • Then I started the VM and in another dom0 shell forced the emulated graphics console:
          qvm-start-gui --force-stubdomain vmname
          I was greeted with Windows Startup Repair. After bailing out of the procedure I was able to successfully boot the VM.
      • You may notice after shutting down the VM and rebooting that you are met with an unclean shutdown menu. For this reason I encourage you to also increase shutdown_timeout. It should be noted that this is merely a precautionary measure; in my experience the VM never takes more than a few seconds to terminate.
      • My VM crashed constantly. I was able to fix this by unchecking the Include in memory balancing checkbox under Qube Manager > Qube settings > Advanced tab. This will likely do far more to reduce the ocurrance of unclean shutdowns.
      • The documentation indicates that the following new properties should be automatically added to the output of qvm-prefs vmname: qrexec_installed and guiagent_installed. These properties have now been replaced by qrexec and gui, viewable and configurable with the qvm-features command.
      • Contrary to the official documentation, seamless mode is not enabled by default. The VM will launch in a window that takes up the entire space of one screen. You must perform a manual registry edit inside the Windows VM. Open regedit.exe
        set HKEY_LOCAL_MACHINE\SOFTWARE\Invisible Things Lab\Qubes Tools\qga\Seamless Mode to 1
      • Before shutting down the VM open its Qube settings from the Qube Manager. On the Applications tab click Refresh Applications. Add some applications to the Qubes menu then shut down the machine. Now when you start an application it should open in seamless mode; if you have multiple displays the VM will boot and load the desktop across all displays and instead of appearing inside of an xfcewm window it will cover the entire viewport, including the taskbar. Once it disappears your application may not appear if the VM is booting for the first time, re-open the application from the Qubes menu if this is the case.
      • After installing qubes-windows-tools your Network Location will be Identifying... but this doesn't seem to matter (under normal circumstances you would not be able to send or receive traffic). Attempting to set my Location to Public crashed the VM. Attempting to set the Location to Home simply failed. The only potential downside is you are not able to join a homegroup unless a Network Location has been specified.
    • Run disk cleanup: C: Drive context menu > Properties > General > Disk Cleanup
      • After the Disk Cleanup utility has finished scanning click the Clean up system files button. Another scan will initiate.
      • After the System Files scan additional items will become available at the bottom of the Files to delete: list (scroll to the bottom), including up to several GB of Windows Update data. Be sure to check these items.
      • Click the OK button to proceed with cleanup.
      • In my case System Queued Windows Error Reporting Files were consuming an alleged 13GB by the end of my installation and configuration. Interestingly, only ~2GB appeared to be freed by the end of the deletion operation. After rebooting and a lengthly pre-boot update and cleanup procedure another ~2GB was freed for a grand total of 25.8GB used. Regardless, you may find it worthwhile to turn this feature off.

        From https://www.techsupportalert.com/content/how-disable-error-reporting-windows-7.htm:

        When a program or the operating system hangs or crashes, Windows 7 sends an error report to Microsoft by default. It will also spend time looking for a solution. (In my experience, it never seems to find one.) If you find the error messages and the delay in closing down a hung application annoying or have concerns about privacy, you can turn off error reporting. Do be aware, however, that the error reporting function creates a local log file that sometimes can be useful for analyzing the causes of problems and this service will be lost.

        The procedure for disabling error reporting is quite simple. Here’s how:

        1. Open the Action Center. Either use the icon in the taskbar notification area or enter “action” (without quotes) in the Start search bar. See this previous tip for more details about the Action Center.
        2. Select “Change Action Center Settings” in the left panel of the Action Center dialog box.
        3. In the new dialog that opens, click “Problem Reporting Settings”.
        4. The window shown in the figure below will open. The four error reporting options are shown in the figure. If you want the setting to apply to all users, click “Change report settings for all users”. Otherwise, the setting will apply to the current user only.
        5. To disable error reporting, choose “Never check for solutions”. Microsoft labels this "not recommended" but the choice is up to you. It is the setting I use.
        6. Click “OK” and “OK” again. Then close the Action Center.

        I found the easiest way to open the Action Center from Qubes was to click on a Windows VM's active window, press the meta key once. You will not see the Start Menu but it is effectively open and your cursor is already in the search box. Type action center and hit Enter. The Action Center should open in a new managed window.

    • At this point I like to check the filesystem to make sure none of the crashes have mangled it before using the VM as the basis for dozens of future VMs. It is important to note that after Windows reboots to check the active disk Qubes will attempt to kill the VM after qrexec_timeout expires:
      Domain vmname has failed to start: Cannot connect to qrexec agent for qrexec_timeout seconds...
      You must temporarily adjust the timeout value to something (un)reasonable:
      qvm-prefs vmname qrexec_timeout 300000
      Don't forget to set it back after chkdsk has done its thing.
    • These are some applications I like to install in my base image before spawning usage-specific clones:
      • Firefox (my Favourite Browser Extensions)
      • Chrome (my Favourite Browser Extensions)
      • VLC
      • Deluge
      • Wireshark
      • nmap
      • Angry IP Scanner
      • TeraTerm
      • PuTTY
      • Xming
      • FileZilla
      • 7Zip
      • OpenVPN
      • TeamViewer
      • TigerVNC
      • Notepad++
      • Gizmo Drive
      • Rufus
      • Java
      • Cygwin NOTE: Cygwin can consume huge amounts of space. From Stack Overflow: What is the current full install size of Cygwin? by user Warren Young:

        A full Cygwin installation can range from 23 to 112 GiB, depending on how you define "full."


        I've come up with a simple set of package exclusion rules that results in a much smaller installation:

        1. Skip all of the -debuginfo packages. Few people need these, and they take up a lot of space. Savings: about 53 GiB in the installation tree alone; more in the download tree.

          It's easy to apply this rule. After selecting all packages for installation with the sneaky trick above but before you move on to the next screen, click the "Install" text next to the "Debug" category header until it switches back to "Default."

          If you've already installed the debug packages, click that text until it says "Uninstall" instead.

        2. Do not explicitly install any of the lib* packages. Let Cygwin's setup-*.exe automatically install libraries to satisfy package dependencies. Savings: about 5 GiB ⁵

          To apply this rule, switch the "Libs" category to "Default" or "Uninstall" as you did with the "Debug" category. The installer will figure out which libraries you actually need in a later step.

        3. Skip the cross-compilers and associated packages. Again, few people need these.⁶ Savings: About 4 GiB

          There are two major sets of cross-development tools in Cygwin: the set for creating Cygwin executables of the other word size (i.e. 64-bit tools and libraries for 32-bit Cygwin, or vice versa) and the set for building MinGW executables of the same word size as your Cygwin installation.

          To apply this rule for a 64-bit Cygwin installation, while still on the "Select Packages" screen, type cygwin32- in the package name search box at the top of that screen, then click the Default text next to each top-level category until it cycles to Default or Uninstall, as above.

          Repeat that for mingw64-.

          The idea is the same for 32-bit Cygwin, except that you search for and exclude packages with cygwin64- and mingw32- in their names instead.

        By following this rule set, I was able to install nearly everything, taking only about 23 GiB.


        We can get the installation to be even smaller by excluding several other notorious disk hogs:

        • X11, the desktop environments, and the GUI apps together require about 11 GiB.⁷
        • A Cygwin Base + Devel installation comes to about 10 GiB.
        • A Cygwin Base + TeX category installation takes about 5 GiB. If you install only your native language's support package, it comes to about 3.7 GiB instead.
        • All of the -doc packages combined chew up about 5 GiB of disk space.

        You really should read the original post if you intend to install Cygwin, it's extraordinarily detailed. Hats off to Mr. Young for the hands-down best answer I have ever seen posted to Stack Overflow.

      • You can find more suggestions at Favourite Windows Software.
    • Some additional configuration changes I like to make:
      • Control Panel > Filder Options
        • Check Show hidden files, folders, and drives
        • Uncheck Hide empty drives in the Computer folder
        • Uncheck Hide extensions for known file types
        • Uncheck Hide protected operating system files
  • Windows 10
    • Windows 10 comes out of the box with an impressive array of bloats and privacy invasions. Whether you care about privacy or not, disabling them now will make working with the VM noticably faster. There are a number of utilities to assist with this process, I am fond of W10Privacy for its ability to save its configuration, making reverting changes back extremely easy. There are literally hundreds of checkboxes but it is worth taking your time to inspect them all and make your own decisions as to what should be disabled. Once you have made your selections be sure to save the configuration (it comes in the form of a .ini file) and put it somewhere safe so it can be re-used on other installations without having to spend time going through each checkbox from scratch over again.
    • Run disk cleanup: C: Drive context menu > Properties > General > Disk Cleanup
      • After the Disk Cleanup utility has finished scanning click the Clean up system files button. Another scan will initiate.
      • After the System Files scan additional items will become available at the bottom of the Files to delete: list (scroll to the bottom), including up to several GB of Windows Update data. Be sure to check these items.
      • Click the OK button to proceed with cleanup.
  • All Versions - Post Install

Generate and Automatically Load SSH Keys for Convenient Passwordless Authentication

When correctly executed, public/private key authentication is more secure than shared secrets (passwords) for a number of reasons including but not limited to:

  • Disabling password-based authentication on remote hosts eliminates the potential for password brute-forcing.
  • Keyloggers installed on a local machine or keyboard firmware can only capture the key's passphrase as valid passwords for remote hosts are never typed.
  • A compromised, malicious, Man-in-the-Middle'd, DNS or ARP poisoned (and so on...) remote host can intercept passwords in the clear; a private key is a component in a randomized and unique cryptographic challenge and is never transmitted.
  • If a public key on a remote host is compromised or intercepted enumerating the private key is significantly more difficult (virtually impossible) than hash cracking/rainbow lookup.
  • Enforcing key authentication establishes a standard level of complexity regardless of users' choice in passwords.
  • One key can be used for any number of remote hosts under a variety of usernames permitting a diversity of remote-local account passwords and configurations.
  • Securing your private key with a password that only has to be entered once alleviates the influence of convenience in selecting a suitably complex password.

Note: It is a matter of personal policy that regardless of the method of authentication used, no management interface should be exposed to the wild wherever possible. Inherent in the term 0-day, there is always a potential for yet-unknown flaws in authentication methodology or any other part of the vast machinery of daemons and their host OS to come to light and render the most supposedly secure authentication scheme ineffective. Where full out-of-band administration is not possible I generally subscribe to an architecture wherein hosts are placed on a private internal network and only the essential public-facing ports are exposed to public address space by a firewall configured for DNAT (1-1 NAT). Access to management interfaces is obtained by VPN tunnel to the private network. Ideally VPN gateway services are provided by a separate host from the firewall - which should do nothing but firewall and itself expose no management interfaces to the wild. This has an added benefit of allowing one to "stack" services from multiple compartmentalized hosts (e.g. HTTP, SMTP, DNS) behind individual IPs, making more efficient use of (often costly) public address space.

Ten years ago I wrote an article for this site on how to implement Passwordless or Single Password SSH with Key Exchange. A lot has changed since then; most importantly ECDSA became available in 2011 and is now widely implemented.

From SSH.com https://www.ssh.com/ssh/keygen/:

SSH supports several public key algorithms for authentication keys. These include:

  • rsa - an old algorithm based on the difficulty of factoring large numbers. A key size of at least 2048 bits is recommended for RSA; 4096 bits is better. RSA is getting old and significant advances are being made in factoring. Choosing a different algorithm may be advisable. It is quite possible the RSA algorithm will become practically breakable in the foreseeable future. All SSH clients support this algorithm.
  • dsa - an old US government Digital Signature Algorithm. It is based on the difficulty of computing discrete logarithms. A key size of 1024 would normally be used with it. DSA in its original form is no longer recommended.
  • ecdsa - a new Digital Signature Algorithm standarized by the US government, using elliptic curves. This is probably a good algorithm for current applications. Only three key sizes are supported: 256, 384, and 521 (sic!) bits. We would recommend always using it with 521 bits, since the keys are still small and probably more secure than the smaller keys (even though they should be safe as well). Most SSH clients now support this algorithm.
  • ed25519 - this is a new algorithm added in OpenSSH. Support for it in clients is not yet universal. Thus its use in general purpose applications may not yet be advisable.

It should be noted that concerns over possible NSA tampering have been raised about the implementation of the NIST standardized P-curves used with ECDSA. EdDSA (Ed25519 which implements Curve25519 instead of P-curves) is purported to be faster than ECDSA in some cases. EdDSA became available in OpenSSH in 2014 and although we will use ECDSA for the purposes of this article due to its ubiquity, EdDSA is currently presumed to be as strong or stronger and you should feel free to use whichever you prefer. Take note that the maximum supported key size for ECDSA is 521 bits not 512. You may create additional keys using other algorithms to support older SSH daemons, however they should be updated if possible.

Use ssh-keygen to create the new key pair. The algorithm is specified by the -t flag and key size by -b:
ssh-keygen -t ecdsa -b 521 Generating public/private ecdsa key pair. Enter file in which to save the key (/home/user/.ssh/id_ecdsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/id_ecdsa. Your public key has been saved in /home/user/.ssh/id_ecdsa.pub. The key fingerprint is: SHA256:Z7HOerLL3vT2D5/Sj3AFk27eUaLtDCgWnViY26OhosY [email protected] The key's randomart image is: +---[ECDSA 521]---+ | o. | | o+ . . | | oo+ = .| | o.o+ + +.| | .So=.o +..| | . ...* * o.| | . . . + . B .| | E ..+...+ =.| | . .*=....+o=| +----[SHA256]-----+ Alternatively... ssh-keygen -t ed25519 ssh-keygen -t rsa -b 4096 ssh-keygen -t dsa

It is important that you protect your private key with a strong passphrase: if the file is compromised an adversary will immediately have access to any accessible accounts without further obstacles. This is especially important if you wish to use the same private key on multiple hosts (e.g. your phone).

If you chose the default key file name your private key will be located at ~/.ssh/id_ecdsa and your public key will be located at ~/.ssh/id_ecdsa.pub. You may configure any number of keys by changing the filename when prompted or using the -f ssh-keygen flag from the command line.

Your public key must now be copied to the remote host(s) you wish to authenticate with. You may specify either the private or public key to ssh-copy-id using the -i flag as .pub will automatically be added to the filename if it is missing:
ssh-copy-id -i ~/.ssh/id_ecdsa [email protected]
Alternatively you may directly paste the public key (in this example, ~/.ssh/id_ecdsa.pub) into the ~/.ssh/authorized_keys file on the remote host. Use a text editor to modify the file to avoid the key being logged (e.g. in ~/.bash_history). A host can accept any number of keys; place them each on an individual newline. If you are manually creating the authorized_keys file for the first time or copying it from another host it is important to ensure that the correct file permissions are configured:
chmod 600 ~/.ssh/authorized_keys ls -lsah ~/.ssh/authorized_keys 4.0K -rw------- 1 user group 270 Apr 28 04:07 /home/user/.ssh/authorized_keys

Every time you connect to a host that supports your key you will be asked to enter the key's passphrase. To avoid this such that you only need to enter the password once, one must add it to the ssh-agent daemon. First, see if your system is already configured to load the daemon automatically:
ps aux | grep ssh-agent user 836 0.0 0.0 5852 2504 ? Ss May06 0:01 /usr/bin/ssh-agent
If it is not running you can launch it in the background thus:
eval "$(ssh-agent -s)"
You may wish to add this line to your preferred autorun script (i.e. /etc/rc.local, /etc/conf.d/local.start, ~/.xinitrc, etc.)

You can now manually add your key to the agent by:
ssh-add -K ~/.ssh/id_ecdsa
However this must be performed every time you restart ssh-agent (every time you reboot). A more permanent method is to create a ~/.ssh/config file with the following:
Host * AddKeysToAgent yes ForwardAgent yes UseKeychain yes IdentityFile ~/.ssh/id_ecdsa
Note: only include the highlighted UseKeychain directive on OS X. It will fail on other operating systems.

You may specify multiple IdentifyFile directives for additional keys. They will be attempted in the order they are listed. This is an ideal way to support multiple key algorithms. To use different keys for different hosts you are encouraged to create separate Host configurations, replacing the wildcard (*) with their remote address. Keys with supported algorithms but no corresponding public key on the remote host will count against your maximum failure attempts and may temporarily or indefinitely lock you out or trigger tools like fail2ban to firewall you.

It is possible to take advantage of the agent forwarding capability to maintain your private keys only on your local host but shell out from a remote host to another remote host with a valid public key matching one of the identities loaded in your local ssh-agent. To view the list of currently registered identities run:
ssh-add -l 521 SHA256:Z7HOerLL3vT2D5/Sj3AFk27eUaLtDCgWnViY26OhosY [email protected] (ECDSA)
To enable forwarding ForwardAgent must be set to yes (the default when unspecified is 'no') in the global default ssh_config client configuration file (/etc/ssh/ssh_config) or your user's personal config file (~/.ssh/config) either under the default (wildcard, "*") Host block or individually for specific hosts. The AllowAgentForwarding directive must be set to yes in the remote host's sshd_config server configuration file (/etc/ssh/sshd_config), which is the default value.

Once key authentication has been configured for all necessary users it is important to disable password-based authentication outright on your remote host(s). Edit /etc/ssh/sshd_config to reflect:
PasswordAuthentication no ChallengeResponseAuthentication no
Additionally, if you are not using PAM (if you are only using key authentication you are not) you may wish to also set UsePAM to no.

Leave a shell session open to ensure you are able to modify the configuration if you are configuring sshd remotely and something goes wrong. Restart sshd to effect the new configuration. Test to ensure you are still able to log in. Attempting to connect from a host with no valid keys configured should now produce:
Permission denied (publickey).