GNU/Linux Desktop Survival Guide by Graham Williams
Desktop Survival Project Home Preface Advocacy History Distributions Installing GNU/Linux Basic Survival Wajig Applications AI, Machine Learning, Data Science Android - GNU/Linux Devices Audio Backup Booting CD Chinese ChRoot Clock Cloud Computing Command Line Databases DIA Directories Disks Emacs EcoSysL Email Evolution Files File Systems Firewalls Floppy Disks FreedomBox Fonts Ghemical Glade GNOME Graphics, Images, Photos Hardware Initialisations on Booting Installation Examples IOT Java KDE Kernels Keyboard Konqueror KVM Switch LaTeX Log System Login Magellan MATE Mathematics Memory Modems Mounting Devices MS/Windows Music MySQL Nautilus Networks NFS NT File System Oracle Packages Partitions Passwords PDF Power Management PPP Presentations Printing Python R Remote Desktops Rsync Samba Scanning Science Screens Security Sketch Spell SPlus Spruce Spreadsheet SSH SUDO Swap Teradata Data Warehouse Themes TV Unity USB Version Control Video Virtualization Voice over IP World Wide Web WebCam WordPress Web Sites Word Processing and Printing X XML Troubleshooting Index

CLICK HERE TO VISIT THE UPDATED SURVIVAL GUIDE

Public and Private Keys

2018-04-22 Devious means can be used to create a Trojan remote host that pretends to be the remote host you are attempting to connect to through ssh (using IP spoofing, DNS spoofing or routing spoofing). Such a Trojan intercepts your communications and to obtain your password, and can then even connect through to the actual remote host so that you may not even notice.

A more secure approach using ssh employs a public-key mechanism. Here you create a key (essentially just a sequence of bits or a string of random characters) that consists of a public part and a private part. You copy the public key on to your account on the remote host and the private part never leaves your local host. The remote host can use the public key to encrypt a message such that only with your private key can the message be decrypted. This is then a very secure mechanism to ensure the connects are private whilst protecting your password. Indeed, the password is never used and some remote hosts actually turn off password login through the configuration of the ssh sever.

You can generate a private/public key pair with ssh-keygen, storing the private and public keys as separate files in /home/kayon/.ssh. A passphrase will be asked for so that the private key will be encrypted on your local file system so as to avoid any loss of the key if there is a local breech of security (or to protect the private key from the administrator). The passphrase is optional but if supplied will be used to unlock your private key whenever you need to use it. The public key needs to be communicated to your remote host and to do so we can use ssh-copy-id.

Finally, we have a choice between using a DSA or an RSA authentication key. Generally RSA is the suggested option today.

The steps are simple:

  $ ssh-keygen -t rsa
  Generating public/private rsa key pair. 
  Enter file in which to save the key (/home/kayon/.ssh/id_rsa): 
  Enter passphrase (empty for no passphrase): 
  Enter same passphrase again: 
  Your identification has been saved in /home/kayon/.ssh/id_rsa. 
  Your public key has been saved in /home/kayon/.ssh/id_rsa.pub. 
  The key fingerprint is:
  cc:50:d4:85:86:56:b8:8a:77:57:61:51:63:89:46:09 kayon@inx
  
  $ ssh-copy-id kayon@alpine.togaware.com

This will add the public key to the authorised keys file in /home/kayon/.ssh/authorized_keys on the remote host. Multiple keys can appear in the one file.

Be sure the protections on the files do not permit others to access them. In particular ssh will exit if the /home/kayon/.ssh/authorized_keys is writable by anyone other than the user. This should all be handled automatically with the relevant ssh commands.

Now when you connect to the remote host using ssh your public key on that host will be used to send an encrypted message (a random number in fact) back to your local host. The local host decrypts the message using the private key stored only on the local host and decrypted using the passphrase (if any). The decrypted message is returned to the remote host for verification.

To reiterate, this method using public keys does not send passwords (or passphrases) over the network. A passphrase (if any) is used on the local host only to unlock the local private key.