This tutorial will show you how to generate and secure SSH keys on macOS Sierra (10.12) and macOS High Sierra (10.13). SSH keys allow you to log into your server without a password. They increase convenience as well as security by being significantly more resistant to brute-force attacks.
SSH (Secure Shell) is a protocol most often used for remote management and for file transfer often denoted as sFTP (Secure File Transfer Protocol). When accessing a remote server such as a Vultr VPS, it is recommended to use SSH with PKE (Public Key Exchange) which uses a key-pair where the public key is provided to the server and the private key in stored on your machine.
How to set up an SSH key. When you want to gain SSH acccess to a server, you need to generate a public/private keypair on your local computer. The private key is stored on your local machine, and should not be shared, while the public key is what you add to your Webdock account, and then assign to your shell users on your servers. Aug 10, 2018 The default SSH public and private key names on a MacBook are idrsa.pub and idrsa. If you don’t see any keys in your SSH directory, then you can run the ssh-keygen command to generate one. You’ll be asked to enter a file name for the key pair. Oct 10, 2019 Generate Your Private/Public Key-pair $ ssh-keygen -t rsa -C 'foo@example.com' By default your private key will be stored in /.ssh/idrsa: This is your private key and it must be kept secret /.ssh/idrsa.pub: This is your public key, you can share it (for example) with servers as an authorized key for your account. You can change the location. However, you can follow the same process to use a private key when using any terminal software on Linux. Note: For information about using Secure Shell (SSH) private keys on Microsoft® Windows® operating systems, see Logging in with an SSH Private Key on Windows and Generate RSA keys with SSH by using PuTTYgen.
SSH Keys can be automatically added to servers during the installation process by adding your public keys in the Vultr control panel. You can manage your SSH keys on this page. It is important to remember that these are your public keys only (usually denoted with .pub), you should never expose your private keys.
There are several different key types that can be selected. Use the -t argument upon generation, such as ssh-keygen -t ed25519. The ED25519 key type, which uses an elliptic-curve signature, is more secure and more performant than DSA or ECDSA. Most modern SSH software (such as OpenSSH since version 6.5) supports the ED25519 key type, but you may still find software that is incompatible, thus the default key type is still RSA.
The default key type is 2048-bit RSA which offers good security and compatibility. For higher security, you can choose a larger key size using the -b argument on generation, such as ssh-keygen -b 4096 to create a 4096-bit RSA key pair.
To generate an SSH key, you will need to open Terminal.app found in 'Applications > Utilities > Terminal'.
To create a 4096-bit RSA key pair, enter:
Then you will see:
Pressing Enter/Return will save your new key pair to this default location, which is recommended. You will then have the option to create a passphrase, which will encrypt the key so that it cannot be used without authorization. Using a passphrase is also recommended.
At this point, your keypair has been created and stored in ~/.ssh/id_rsa. To make the key available to the system and store the passphrase in the system keychain, we will need to complete several additional steps. Note that this is only needed if you would rather not be prompted for the key passphrase each time it is used.
Enter ssh-add -K ~/.ssh/id_rsa. You will then be prompted for the passphrase and you will see the following:
If you would like to use this SSH key to log into a server that has already been created, you can use the ssh-copy-id tool to store the public key on the server you would like to access.
Using ssh-copy-id:
The console will request your login password since the remote server is not yet aware of your key. You will see the following:
You can now attempt to log into the remote server with ssh root@192.0.2.1 and you should be connected without a password prompt.
This guide will demonstrate the steps required to encrypt and decrypt files using OpenSSL on Mac OS X. The working assumption is that by demonstrating how to encrypt a file with your own public key, you'll also be able to encrypt a file you plan to send to somebody else using their private key, though you may wish to use this approach to keep archived data safe from prying eyes.
Assuming you've already done the setup described later in this document, that id_rsa.pub.pcks8 is the public key you want to use, that id_rsa is the private key the recipient will use, and secret.txt is the data you want to transmit…
OpenSSL makes it easy to encrypt/decrypt files using a passphrase. Unfortunately, pass phrases are usually 'terrible' and difficult to manage and distribute securely.
You can add -base64 if you expect the context of the text may be subject to being 'visible' to people (e.g., you're printing the message on a pbulic forum). If you do, you'll need to add it to the decoding step as well. You can choose from several cypers but aes-256-cbc is reasonably fast, strong, and widely supported. Base64 will increase the size of the encrypted file by approximately 30%
You will need to provide the same password used to encrypt the file. All that changes between the encrypt and decrypt phases is the input/output file and the addition of the -d flag. If you pass an incorrect password or cypher then an error will be displayed.
RSA encryption can only work with very short sections of data (e.g. an SHA1 hash of a file, or a password) and cannot be used to encrypt a large file. The solution is to generate a strong random password, use that password to encrypt the file with AES-256 in CBC mode (as above), then encrypt that password with a public RSA key. The encrypted password will only decrypt with a matching public key, and the encrypted file will require the unique password encrypted in the by the RSA key.
The copy of OpenSSL bundled with Mac OS X has several issues. Mac OS X 10.7 and earlier are not PCI compliant. It is best to replace it. See here for details: http://www.dctrwatson.com/2013/07/how-to-update-openssh-on-mac-os-x/
By default your private key will be stored in
The default format of id_rsa.pub isn't particularly friendly. If you are going to public your key (for example) on your website so that other people can verify the authorship of files attributed to you then you'll want to distribute it in another format. I find it useful to keep a copy in my .ssh folder so I don't have to re-generate it, but you can store it anywhere you like.
The passwords used to encrypt files should be reasonably long 32+ characters, random, and never used twice. To do this we'll generate a random password which we will use to encrypt the file.
This will generate 192 bytes of random data which we will use as a key. If you think a person may need to view the contents of the key (e.g., they're going to display it on a terminal or copy/paste it between computers) then you should consider base-64 encoding it, however:
There is a limit to the maximum length of a message that can be encrypted using RSA public key encryption. If you want to use very long keys then you'll have to split it into several short messages, encrypt them independently, and then concatinate them into a single long string. Decrypting the password will require reversing the technique: splitting the file into smaller chuncks, decrypting them independently, and then concatinating those into the original password key file.
Now that you have a good random password, you can use that to AES encrypt a file as seen in the 'with passwords' section
Decrypting the file works the same way as the 'with passwords' section, except you'll have to pass the key.
We used fast symetric encryption with a very strong password to encrypt the file to avoid limitations in how we can use asymetric encryption. Finally, we'll use asymetric encryption to encrypt the password. This solves the problem of 'how do I safely transmit the password for the encrypted file' problem. You can encrypt is using the recipients public key and they can decode it using their private key. Encrypt the password using a public key:
The recipient can decode the password using a matching private key:
There are a number of ways to do this step, but typically you'll want just a single file you can send to the recipent to make transfer less of a pain. Destiny the collection serial key generator. I'd recommend just making a tarball and delivering it through normal methods (email, sftp, dropbox, whatever). Though a secure method of exchange is obviously preferable, if you have to make the data public it should still be resistent to attempts to recover the information.
The file can be extracted in the usual way:
You may want to securely delete the unecrypted keyfile as the recipient will be able to decode it using their private key and you already have the unencrypted data.