Key Points

1. Ubuntu good for many purposes
2. IBM focuses on Red Hat
3. Alpine now used for Hyperledger

References

Key Concepts

Key Generation for access to remote services ( Github etc )

https://docs.gitlab.com/ee/ssh/

gitlab-ssh-keys-docs.gitlab.com-GitLab and SSH keys.pdf

Git is a distributed version control system, which means you can work locally but you can also share or “push” your changes to other servers. Before you can push your changes to a GitLab server you need a secure communication channel for sharing information.

The SSH protocol provides this security and allows you to authenticate to the GitLab remote server without supplying your username or password each time.

For a more detailed explanation of how the SSH protocol works, read this nice tutorial by DigitalOcean.

Requirements

The only requirement is to have the OpenSSH or Putty client installed on your system.

This comes pre-installed on GNU/Linux and macOS, but NOT on Windows.

Depending on your Windows version, there are different methods to work with SSH keys.

Windows 10: Windows Subsystem for Linux

Starting with Windows 10, you can install the Windows Subsystem for Linux (WSL) where you can run Linux distributions directly on Windows, without the overhead of a virtual machine. Once installed and set up, you’ll have the Git and SSH clients at your disposal.

Windows 10, 8.1, and 7: Git for Windows

The easiest way to install Git and the SSH client on Windows 8.1 and Windows 7 is Git for Windows. It provides a Bash emulation (Git Bash) used for running Git from the command line and the ssh-keygen command that is useful to create SSH keys as you’ll learn below.

Check the pre-reqs:  SSH and Git are installed on your client

Open a terminal window ( for Windows, this will be a Git Bash window ( from the Windows Subsystem for Linux )

Jim Mason@acer-jim MINGW64 ~
$ git --version && ssh -V
git version 2.16.2.windows.1
OpenSSH_7.6p1, OpenSSL 1.0.2n  7 Dec 2017

Here on Windows SBS for Linux in the Git Bash terminal you see the versions of GIT and OpenSSH I have installed.

I'm ready to create the PKI keys I need to access Github with secure connections

Types of SSH keys and which to choose

GitLab supports RSA, DSA, ECDSA, and ED25519 keys. Their difference lies on the signing algorithm, and some of them have advantages over the others. For more information, you can read this nice article on ArchWiki. We’ll focus on ED25519 and RSA here.

ED25519 SSH keys - NOT neccessary for Github or Gitlab access

Following best practices, you should always favor ED25519 SSH keys, since they are more secure and have better performance over the other types.

ED25519 SSH keys were introduced in OpenSSH 6.5, so any modern OS should include the option to create them. If for any reason your OS or the GitLab instance you interact with doesn’t support ED25519, you can fallback to RSA.

RSA SSH keys - recommended for Github or Gitlab access

RSA keys are the most common ones and therefore the most compatible with servers that may have an old OpenSSH version. Use them if the GitLab server doesn’t work with ED25519 keys.

The minimum key size is 1024 bits, defaulting to 2048. If you wish to generate a stronger RSA key pair, specify the -b flag with a higher bit value than the default.

Generating a new SSH key pair

Before creating an SSH key pair, make sure to understand the different types of keys.

To create a new SSH key pair:

1. Open a terminal on Linux or macOS, or Git Bash / WSL on Windows.

2. Generate a new ED25519 SSH key pair:

   ssh-keygen -t ed25519 -C "email@example.com"
   

   Or, if you want to use RSA:

   ssh-keygen -t rsa -b 4096 -C "email@example.com"
   

   The -C flag adds a comment in the key in case you have multiple of them and want to tell which is which. It is optional.

3. Next, you will be prompted to input a file path to save your SSH key pair to. If you don’t already have an SSH key pair and aren’t generating a deploy key, use the suggested path by pressing Enter. Using the suggested path will normally allow your SSH client to automatically use the SSH key pair with no additional configuration.

   If you already have an SSH key pair with the suggested file path, you will need to input a new file path and declare what host this SSH key pair will be used for in your ~/.ssh/config file.

4. Once the path is decided, you will be prompted to input a password to secure your new SSH key pair. It’s a best practice to use a password, but it’s not required and you can skip creating it by pressing Enter twice.

   If, in any case, you want to add or change the password of your SSH key pair, you can use the -p flag:

   ssh-keygen -p -f <keyname>
   

OpenSSH < v7.8

Pre OpenSSH 7.8, default password encoding for SSH private keys was insecure; it’s only a single round of an MD5 hash. For OpenSSH version 6.5 to version 7.8, you should use the -o option to ssh-keygen to encode your private key in a new, more secure format.

If you already have an RSA SSH key pair to use with GitLab, consider upgrading it to use the more secure password encryption format by using the following command on the private key:

ssh-keygen -o -f ~/.ssh/id_rsa

Or generate a new RSA key:

ssh-keygen -o -t rsa -b 4096 -C "email@example.com"

Adding an SSH key to your GitLab account

Now, it’s time to add the newly created public key to your GitLab account.

1. Copy your public SSH key to the clipboard by using one of the commands below depending on your Operating System:

   macOS:

   pbcopy < ~/.ssh/id_ed25519.pub
   

   WSL / GNU/Linux (requires the xclip package):

   xclip -sel clip < ~/.ssh/id_ed25519.pub
   

   Git Bash on Windows:

   cat ~/.ssh/id_ed25519.pub | clip
   

   You can also open the key in a graphical editor and copy it from there, but be careful not to accidentally change anything.

   Note: If you opted to create an RSA key, the name might differ.

2. Add your public SSH key to your GitLab account by:

   1. Clicking your avatar in the upper right corner and selecting Settings.
   2. Navigating to SSH Keys and pasting your public key from the clipboard into the Key field. If you:
      • Created the key with a comment, this will appear in the Title field.
      • Created the key without a comment, give your key an identifiable title like Work Laptop or Home Workstation.
   3. Click the Add key button.
   Note: If you manually copied your public SSH key make sure you copied the entire key starting with ssh-ed25519 (or ssh-rsa) and ending with your email.

Testing that everything is set up correctly

To test whether your SSH key was added correctly, run the following command in your terminal (replacing gitlab.com with your GitLab’s instance domain):

ssh -T git@gitlab.com

The first time you connect to GitLab via SSH, you will be asked to verify the authenticity of the GitLab host you are connecting to. For example, when connecting to GitLab.com, answer yes to add GitLab.com to the list of trusted hosts:

The authenticity of host 'gitlab.com (35.231.145.151)' can't be established.
ECDSA key fingerprint is SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'gitlab.com' (ECDSA) to the list of known hosts.

Once added to the list of known hosts, you won’t be asked to validate the authenticity of GitLab’s host again. Run the above command once more, and you should only receive a Welcome to GitLab, @username! message.

If the welcome message doesn’t appear, run SSH’s verbose mode by replacing -T with -vvvT to understand where the error is.

Working with non-default SSH key pair paths

If you used a non-default file path for your GitLab SSH key pair, you must configure your SSH client to find your GitLab private SSH key for connections to GitLab.

Open a terminal and use the following commands (replacing other_id_rsa with your private SSH key):

eval $(ssh-agent -s)
ssh-add ~/.ssh/other_id_rsa

To retain these settings, you’ll need to save them to a configuration file. For OpenSSH clients this is configured in the ~/.ssh/config file. In this file you can set up configurations for multiple hosts, like GitLab.com, your own GitLab instance, GitHub, Bitbucket, etc.

Below are two example host configurations using their own SSH key:

# GitLab.com
Host gitlab.com
Preferredauthentications publickey
IdentityFile ~/.ssh/gitlab_com_rsa

# Private GitLab instance

Host gitlab.company.com
Preferredauthentications publickey
IdentityFile ~/.ssh/example_com_rsa

Public SSH keys need to be unique to GitLab, as they will bind to your account. Your SSH key is the only identifier you’ll have when pushing code via SSH, that’s why it needs to uniquely map to a single user.

Per-repository SSH keys

If you want to use different keys depending on the repository you are working on, you can issue the following command while inside your repository:

git config core.sshCommand "ssh -o IdentitiesOnly=yes -i ~/.ssh/private-key-filename-for-this-repository -F /dev/null"

This will not use the SSH Agent and requires at least Git 2.10.

Multiple accounts on a single GitLab instance

The per-repository method also works for using multiple accounts within a single GitLab instance.

Alternatively, it is possible to directly assign aliases to hosts in ~.ssh/config. SSH and, by extension, Git will fail to log in if there is an IdentityFile set outside of a Host block in .ssh/config. This is due to how SSH assembles IdentityFile entries and is not changed by setting IdentitiesOnly to yes. IdentityFile entries should point to the private key of an SSH key pair.

# User1 Account Identity

Host <user_1.gitlab.com>
Hostname gitlab.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/<example_ssh_key1>

# User2 Account Identity

Host <user_2.gitlab.com>
Hostname gitlab.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/<example_ssh_key2>

Cloning the gitlab repository normally looks like this:

git clone git@gitlab.com:gitlab-org/gitlab.git

To clone it for user_1, replace gitlab.com with the SSH alias user_1.gitlab.com:

git clone git@<user_1.gitlab.com>:gitlab-org/gitlab.git

Fix a previously cloned repository using the git remote command.

The example below assumes the remote repository is aliased as origin.

git remote set-url origin git@<user_1.gitlab.com>:gitlab-org/gitlab.git

Puttygen for key generation 

https://the.earth.li/%7Esgtatham/putty/0.67/htmldoc/Chapter8.html#pubkey-puttygen

PuTTYgen is a key generator. It generates pairs of public and private keys to be used with PuTTY, PSCP, and Plink, as well as the PuTTY authentication agent, Pageant (see chapter 9). PuTTYgen generates RSA and DSA keys.

When you run PuTTYgen you will see a window where you have two choices: ‘Generate’, to generate a new public/private key pair, or ‘Load’ to load in an existing private key.

8.2.1 Generating a new key

This is a general outline of the procedure for generating a new key pair. The following sections describe the process in more detail.

• First, you need to select which type of key you want to generate, and also select the strength of the key. This is described in more detail in section 8.2.2 and section 8.2.3.
• Then press the ‘Generate’ button, to actually generate the key. Section 8.2.4 describes this step.
• Once you have generated the key, select a comment field (section 8.2.6) and a passphrase (section 8.2.7).
• Now you're ready to save the private key to disk; press the ‘Save private key’ button. (See section 8.2.8).

Your key pair is now ready for use. You may also want to copy the public key to your server, either by copying it out of the ‘Public key for pasting into authorized_keys file’ box (see section 8.2.10), or by using the ‘Save public key’ button (section 8.2.9). However, you don't need to do this immediately; if you want, you can load the private key back into PuTTYgen later (see section 8.2.11) and the public key will be available for copying and pasting again.

Section 8.3 describes the typical process of configuring PuTTY to attempt public-key authentication, and configuring your SSH server to accept it.

8.2.2 Selecting the type of key

Before generating a key pair using PuTTYgen, you need to select which type of key you need. PuTTYgen currently supports three types of key:

• An RSA key for use with the SSH-1 protocol.
• An RSA key for use with the SSH-2 protocol.
• A DSA key for use with the SSH-2 protocol.

The SSH-1 protocol only supports RSA keys; if you will be connecting using the SSH-1 protocol, you must select the first key type or your key will be completely useless.

The SSH-2 protocol supports more than one key type. The two types supported by PuTTY are RSA and DSA.

The PuTTY developers strongly recommend you use RSA. DSA has an intrinsic weakness which makes it very easy to create a signature which contains enough information to give away the private key! This would allow an attacker to pretend to be you for any number of future sessions. PuTTY's implementation has taken very careful precautions to avoid this weakness, but we cannot be 100% certain we have managed it, and if you have the choice we strongly recommend using RSA keys instead.

If you really need to connect to an SSH server which only supports DSA, then you probably have no choice but to use DSA. If you do use DSA, we recommend you do not use the same key to authenticate with more than one server.

8.2.3 Selecting the size (strength) of the key

The ‘Number of bits’ input box allows you to choose the strength of the key PuTTYgen will generate.

Currently 1024 bits should be sufficient for most purposes.

8.2.4 The ‘Generate’ button

Once you have chosen the type of key you want, and the strength of the key, press the ‘Generate’ button and PuTTYgen will begin the process of actually generating the key.

First, a progress bar will appear and PuTTYgen will ask you to move the mouse around to generate randomness. Wave the mouse in circles over the blank area in the PuTTYgen window, and the progress bar will gradually fill up as PuTTYgen collects enough randomness. You don't need to wave the mouse in particularly imaginative patterns (although it can't hurt); PuTTYgen will collect enough randomness just from the fine detail of exactly how far the mouse has moved each time Windows samples its position.

When the progress bar reaches the end, PuTTYgen will begin creating the key. The progress bar will reset to the start, and gradually move up again to track the progress of the key generation. It will not move evenly, and may occasionally slow down to a stop; this is unfortunately unavoidable, because key generation is a random process and it is impossible to reliably predict how long it will take.

When the key generation is complete, a new set of controls will appear in the window to indicate this.

8.2.5 The ‘Key fingerprint’ box

The ‘Key fingerprint’ box shows you a fingerprint value for the generated key. This is derived cryptographically from the public key value, so it doesn't need to be kept secret.

The fingerprint value is intended to be cryptographically secure, in the sense that it is computationally infeasible for someone to invent a second key with the same fingerprint, or to find a key with a particular fingerprint. So some utilities, such as the Pageant key list box (see section 9.2.1) and the Unix ssh-add utility, will list key fingerprints rather than the whole public key.

8.2.6 Setting a comment for your key

If you have more than one key and use them for different purposes, you don't need to memorise the key fingerprints in order to tell them apart. PuTTYgen allows you to enter a comment for your key, which will be displayed whenever PuTTY or Pageant asks you for the passphrase.

The default comment format, if you don't specify one, contains the key type and the date of generation, such as rsa-key-20011212. Another commonly used approach is to use your name and the name of the computer the key will be used on, such as simon@simons-pc.

To alter the key comment, just type your comment text into the ‘Key comment’ box before saving the private key. If you want to change the comment later, you can load the private key back into PuTTYgen, change the comment, and save it again.

8.2.7 Setting a passphrase for your key

The ‘Key passphrase’ and ‘Confirm passphrase’ boxes allow you to choose a passphrase for your key. The passphrase will be used to encrypt the key on disk, so you will not be able to use the key without first entering the passphrase.

When you save the key, PuTTYgen will check that the ‘Key passphrase’ and ‘Confirm passphrase’ boxes both contain exactly the same passphrase, and will refuse to save the key otherwise.

If you leave the passphrase fields blank, the key will be saved unencrypted. You should not do this without good reason; if you do, your private key file on disk will be all an attacker needs to gain access to any machine configured to accept that key. If you want to be able to log in without having to type a passphrase every time, you should consider using Pageant (chapter 9) so that your decrypted key is only held in memory rather than on disk.

Under special circumstances you may genuinely need to use a key with no passphrase; for example, if you need to run an automated batch script that needs to make an SSH connection, you can't be there to type the passphrase. In this case we recommend you generate a special key for each specific batch script (or whatever) that needs one, and on the server side you should arrange that each key is restricted so that it can only be used for that specific purpose. The documentation for your SSH server should explain how to do this (it will probably vary between servers).

Choosing a good passphrase is difficult. Just as you shouldn't use a dictionary word as a password because it's easy for an attacker to run through a whole dictionary, you should not use a song lyric, quotation or other well-known sentence as a passphrase. DiceWare (www.diceware.com) recommends using at least five words each generated randomly by rolling five dice, which gives over 2^64 possible passphrases and is probably not a bad scheme. If you want your passphrase to make grammatical sense, this cuts down the possibilities a lot and you should use a longer one as a result.

Do not forget your passphrase. There is no way to recover it.

8.2.8 Saving your private key to a disk file

Once you have generated a key, set a comment field and set a passphrase, you are ready to save your private key to disk.

Press the ‘Save private key’ button. PuTTYgen will put up a dialog box asking you where to save the file. Select a directory, type in a file name, and press ‘Save’.

This file is in PuTTY's native format (*.PPK); it is the one you will need to tell PuTTY to use for authentication (see section 4.21.8) or tell Pageant to load (see section 9.2.2).

8.2.9 Saving your public key to a disk file

RFC 4716 specifies a standard format for storing SSH-2 public keys on disk. Some SSH servers (such as ssh.com's) require a public key in this format in order to accept authentication with the corresponding private key. (Others, such as OpenSSH, use a different format; see section 8.2.10.)

To save your public key in the SSH-2 standard format, press the ‘Save public key’ button in PuTTYgen. PuTTYgen will put up a dialog box asking you where to save the file. Select a directory, type in a file name, and press ‘Save’.

You will then probably want to copy the public key file to your SSH server machine. See section 8.3 for general instructions on configuring public-key authentication once you have generated a key.

If you use this option with an SSH-1 key, the file PuTTYgen saves will contain exactly the same text that appears in the ‘Public key for pasting’ box. This is the only existing standard for SSH-1 public keys.

8.2.10 ‘Public key for pasting into authorized_keys file’

All SSH-1 servers require your public key to be given to it in a one-line format before it will accept authentication with your private key. The OpenSSH server also requires this for SSH-2.

The ‘Public key for pasting into authorized_keys file’ gives the public-key data in the correct one-line format. Typically you will want to select the entire contents of the box using the mouse, press Ctrl+C to copy it to the clipboard, and then paste the data into a PuTTY session which is already connected to the server.

See section 8.3 for general instructions on configuring public-key authentication once you have generated a key.

8.2.11 Reloading a private key

PuTTYgen allows you to load an existing private key file into memory. If you do this, you can then change the passphrase and comment before saving it again; you can also make extra copies of the public key.

To load an existing key, press the ‘Load’ button. PuTTYgen will put up a dialog box where you can browse around the file system and find your key file. Once you select the file, PuTTYgen will ask you for a passphrase (if necessary) and will then display the key details in the same way as if it had just generated the key.

If you use the Load command to load a foreign key format, it will work, but you will see a message box warning you that the key you have loaded is not a PuTTY native key. See section 8.2.12 for information about importing foreign key formats.

8.2.12 Dealing with private keys in other formats

Most SSH-1 clients use a standard format for storing private keys on disk. PuTTY uses this format as well; so if you have generated an SSH-1 private key using OpenSSH or ssh.com's client, you can use it with PuTTY, and vice versa.

However, SSH-2 private keys have no standard format. OpenSSH and ssh.com have different formats, and PuTTY's is different again. So a key generated with one client cannot immediately be used with another.

Using the ‘Import’ command from the ‘Conversions’ menu, PuTTYgen can load SSH-2 private keys in OpenSSH's format and ssh.com's format. Once you have loaded one of these key types, you can then save it back out as a PuTTY-format key (*.PPK) so that you can use it with the PuTTY suite. The passphrase will be unchanged by this process (unless you deliberately change it). You may want to change the key comment before you save the key, since OpenSSH's SSH-2 key format contains no space for a comment and ssh.com's default comment format is long and verbose.

PuTTYgen can also export private keys in OpenSSH format and in ssh.com format. To do so, select one of the ‘Export’ options from the ‘Conversions’ menu. Exporting a key works exactly like saving it (see section 8.2.8) - you need to have typed your passphrase in beforehand, and you will be warned if you are about to save a key without a passphrase.

Note that since only SSH-2 keys come in different formats, the export options are not available if you have generated an SSH-1 key.

8.3 Getting ready for public key authentication

Connect to your SSH server using PuTTY with the SSH protocol. When the connection succeeds you will be prompted for your user name and password to login. Once logged in, you must configure the server to accept your public key for authentication:

• If your server is using the SSH-1 protocol, you should change into the .ssh directory and open the file authorized_keys with your favourite editor. (You may have to create this file if this is the first key you have put in it). Then switch to the PuTTYgen window, select all of the text in the ‘Public key for pasting into authorized_keys file’ box (see section 8.2.10), and copy it to the clipboard (Ctrl+C). Then, switch back to the PuTTY window and insert the data into the open file, making sure it ends up all on one line. Save the file.
• If your server is OpenSSH and is using the SSH-2 protocol, you should follow the same instructions, except that in earlier versions of OpenSSH 2 the file might be called authorized_keys2. (In modern versions the same authorized_keys file is used for both SSH-1 and SSH-2 keys.)
• If your server is ssh.com's product and is using SSH-2, you need to save a public key file from PuTTYgen (see section 8.2.9), and copy that into the .ssh2 directory on the server. Then you should go into that .ssh2 directory, and edit (or create) a file called authorization. In this file you should put a line like Key mykey.pub, with mykey.pub replaced by the name of your key file.
• For other SSH server software, you should refer to the manual for that server.

You may also need to ensure that your home directory, your .ssh directory, and any other files involved (such as authorized_keys, authorized_keys2 or authorization) are not group-writable or world-writable. You can typically do this by using a command such as

chmod go-w $HOME $HOME/.ssh $HOME/.ssh/authorized_keys

Your server should now be configured to accept authentication using your private key. Now you need to configure PuTTY to attempt authentication using your private key. You can do this in any of three ways:

• Select the private key in PuTTY's configuration. See section 4.21.8 for details.
• Specify the key file on the command line with the -i option. See section 3.8.3.18 for details.
• Load the private key into Pageant (see chapter 9). In this case PuTTY will automatically try to use it for authentication if it can.

Putty SSH

copy and paste text in putty

To copy from Windows and paste into PuTTY, highlight the text in Windows, press "Ctrl-C," select the PuTTY window, and press the right mouse button to paste.

To copy from PuTTy and paste into Windows, highlight the information in PuTTY and press "Ctrl-V" in the Windows application to paste it.

sftp - secure ftp 

https://www.computerhope.com/unix/sftp.htm

login as a user to a remote host sending password

psftp homenet_dmx_internal@sftp.dmx.io -pw 7Au6XjArGV5w3JE1BqGkrO2EAtedFI

psftp> help

! run a local command

bye finish your SFTP session

cd change your remote working directory

chmod change file permissions and modes

close finish your SFTP session but do not quit PSFTP

del delete files on the remote server

dir list remote files

exit finish your SFTP session

get download a file from the server to your local machine

help give help

lcd change local working directory

lpwd print local working directory

ls list remote files

mget download multiple files at once

mkdir create directories on the remote server

mput upload multiple files at once

mv move or rename file(s) on the remote server

open connect to a host

put upload a file from your local machine to the server

pwd print your remote working directory

quit finish your SFTP session

reget continue downloading files

ren move or rename file(s) on the remote server

reput continue uploading files

rm delete files on the remote server

rmdir remove directories on the remote server

Potential Value Opportunities

Potential Challenges

Candidate Solutions

Step-by-step guide for Example

sample code block

Recommended Next Steps

Related articles