Ssh Generate Public Key Authorized_keys
Mar 31, 2018 Generate public key and store into a file. It is a simple one liner command to generate a public key from a private key, so lets say our private key is named ‘user@myserver.key’ and we want to generate the public key and name it ‘authorizedkeys’. Below is the command to do this. Apr 15, 2020 SSH (Secure Shell) allows secure remote connections between two systems. With this cryptographic protocol, you can manage machines, copy, or move files on a remote server via encrypted channels. There are two ways to login onto a remote system over SSH – using password authentication or public key authentication (passwordless SSH login). In this tutorial, you will find out how to set up.
Add comment to existing SSH public key. Ask Question Asked 7 years, 3 months ago. Active 1 year, 5 months ago. The man page for sshd has a section on the authorizedkeys format, where it states that the comment extends to the end of the line. While I haven't tried it, you should be able to put spaces into the comment. Create a public. If you don't have the ssh-copy-id command (for example, if you are using Windows), you can instead SSH in to your server and manually create the.ssh/authorizedkeys file so it contains your public key. May 06, 2018 mkdir /.ssh touch /.ssh/authorizedkeys In that file, you must add the contents of your local /.ssh/idrsa.pub. SSH then uses this public key to verify that your client machine is. The public key should be stored in the authorizedkeys file within the user's.SSH folder. Use FTP in binary mode to move the public key into the user's.SSH directory.
Below is a quick how-to for implementing public / private key authentication for SSH. This is by no means an exhaustive examination of the subject. *nix distributions vary slightly and further research may be needed.
- 3Setup Procedures
Why use Public Key Authentication?
Public key authentication is considered a more secure methods of authenticating the Secure Shell than the simple password challenge routine, a method often broken by brute-force attacks. In addition, public key authentication allows for automated login routines between machines, thus enabling a range of scripted jobs (think rsync or port tunneling). It can also simplify the login process without compromising password security.
How does it work?
Public key authentication uses a pair of computer generated keys - one public and one private – to authenticate between a host and a client. The public key is derived from the private key. When authenticating, the host machine compares the public key to the private key in order to verify the veracity of the public key. If the two match, access is granted. Security of the system is predicated on the security of the private key.
Setup Procedures
- Generate the needed Public and Private keys on the host.
- Transfer / append the public key to the authorized_keys file on the client.
- Login via Public Key Authentication.
Step by Step Example
The below setup description assumes that you are able to run terminal or a terminal application like Putty, and that you are familiar with basic commands. It doesn't take much.
Let's setup SSH public key authentication between your home computer (hereafter referred to as the “Host”) and your QNAP device (hereafter referred to as the “Client').
1. Login to the Host via SSH using your preferred terminal application and generate the public / private key pair. In terminal type the following at the command prompt:
Note: the -C switch is not required. It allows you to insert a comment that will appear in the authorized_keys file. It is helpful for identifying and managing keys within the authorized_keys file on the Client in the event that you have multiple key logins. Replace 'server comment field' with a machine name, IP address, date, or task name so that you can easily identify where and why a given key was created.
2. Execute the command and you should see the following output:
Note: “UserName” is the user account that you have logged into via SSH. Also note that the actual suggested path may vary slightly depending your system. You should accept the suggested location unless you have reason to do otherwise.
You will then be prompted for a passphrase that will be associated with this key.
The passphrase can be thought of as a password for the private key - it serves as an extra layer of protection as described below. If you leave this field blank you will generate keys that do not prompt for a passphrase. In other words, you will be logged in automatically via the secure public / private key handshake that you are in the process of setting up. It is highly recommended that you enter a passphrase unless you are setting up automated routines that require automatic login. See more detail below in “Security Notes.”
The keys have now been generated and are stored in the .ssh folder associated with the user account on the Host machine.
3. The final steps are to copy the public key to the Client and append it to the authorization_keys file. There are a number of ways to do this – you can copy the file to the Client and then append it (I like this method being the relative noob that I am. It involves more steps but is the easiest to complete without error. Those proficient with terminal commands will do it all in one step from the Host). Alternatively, you can open the id_rsa.pub file via a text editor like iv and copy the key text - then open the authorized_keys file on the Client and paste the text directly into the file. I will walk you through the noob method.
In the terminal navigate to the folder that contains the newly created keys – cd /User/UserName/.ssh and use the 'ls' list comand to see what is in that directory. You should see the following files:
- id_rsa
- id_rsa.pub
- known_hosts.
Type the following at the command prompt:
admin@ClientIPAddress is the address of your QNAP NAS (the Client) followed by the path on the Client where the public key needs to reside. You will be ask you for the password of the 'admin' account to login to the Client.
Enter the password to complete secure copy.
4. On the Client (QNAP NAS) navigate to the /etc/config/ssh folder and 'ls' to reveal the contents of the directory. You should see your id_rsa.pub file.
5. Now let's append this file to the authorized_keys file which needs to reside in this directory. Do not worry if authorized_keys file is not present. We will create it.
Type the following at the command prompt:
Ssh Generate Public Key Authorized_keys Windows 10
Note: You have to cut the key in the file to one line, and add ssh-rsa in at the very beginning.
Example
Set correct permissions
SSH daemon is really peacky about permissions. Create a .ssh folder within your home folder, copy /etc/config/ssh/authorized_keys to this folder and then make sure you have set your permissions as follows:
That's it. You should now be able to login using key authentication. Logout of the Client and attempt to login. If you created a passphrase for your id_rsa private key then you will be prompted for the passphrase. If you left the passphrase field blank when generating the keys then you will be logged in automatically.
The first time you login you may encounter a promoted message like below.
Type 'yes' to continue. After you accept the authenticity of the RSA key, the Client information is saved in the /Users/UserName/.ssh/known_hosts file. You will not be prompted again unless you remove this file.
Important
If the destination Client is a x86 series model, please execute the following command on the destination Client (TS-509) to make sure the folder permission has been set correctly. Because there might be a permission problem in earlier firmware versions in x86 model (e.g. TS-509)
Note
The procedure is the same when setting up key authentication between two NAS boxes. Simply follow the steps above substituting a NAS device for the Host and Client as per the above example.
Trouble Shooting
O'Reilly provides an excellent reasource for troubleshooting.
Security Notes
You must keep your private key secure! Security of public key authentication is dependent on your ability to secure the private key. You should avoid generating a key without a passphrase. If you have an unencrypted private key (no passphrase) stored on your workstation and if your workstation is compromised, your Client machines have been compromised too! If a hacker can obtain the private key they will have access to any client machines accessible with the public key. Further, in the event that your machine is compromised you should consider strongly the possibility that your keystrokes are being logged and therefore any private keys that ar protected by passphrases have likely been compromised.
In addition, you should never allow root-to-root trust between systems. Unfortunately, the firmware version of the QNAP NAS series is hardwired with a variant of OpenSSH that only permits ssh login by the root (admin) user. You are strongly encourage to update the SSH Daemon With OpenSSH as per How To Replace_SSH Daemon With OpenSSH. You can then setup named accounts for users or roles, granting as little root access as possible via sudo. You should also limit the 'from' access of the public keys, and if possible only allow specific public keys to run specific commands.
Original Example
Here is an example which tells you how to set up authorized_keys between two QNAP NAS units. For example, we have one TS-209 (10.8.12.209) & a TS-509 (10.8.12.33), and now I want to make it possible to SSH login to TS-509 from TS-209 without password.
1. SSH login to TS-209 with a console application (e.g. Putty)
2. Execute the following command, secure copy the id_rsa.pub from TS-209 to TS-509, and save it as 'authorized_keys'.
3. You might see a promoted message like below if this is the first time you are trying to access one NAS from another. Simply type 'yes' and go to the next step.
4. And it will ask you for the password of the 'admin' account to login the destination host (10.8.12.33), just enter it and finish the secure copy command.
5. That's it! Now you should be able to SSH login to the TS-509 from TS-209 without password, the authorized_keys has been saved in the destination host (TS-509) under /etc/config/ssh/authorized_keys
Note
If the destination host is a x86 series model, please execute the following command in the destination host (TS-509) to make sure the folder permission has been set correctly. Because there might be a permission problem in earlier firmware versions in x86 model (e.g. TS-509)
If you interact regularly with SSH commands and remote hosts, you may find that using a key pair instead of passwords can be convenient. Instead of the remote system prompting for a password with each connection, authentication can be automatically negotiated using a public and private key pair.
The private key remains secure on your own workstation, and the public key gets placed in a specific location on each remote system that you access. Your private key may be secured locally with a passphrase. A local caching program such as ssh-agent or gnome-keyring allows you to enter that passphrase periodically, instead of each time you use the key to access a remote system.
Generating a key pair and propagating the public key
Generating your key pair and propagating your public key is simpler than it sounds. Let’s walk through it.
Generating the key
The minimum effort to generate a key pair involves running the ssh-keygen command, and choosing the defaults at all the prompts:
The default location to store the keys is in the ~/.ssh directory, which will be created if it does not exist:
Allowing this command to create the directory also ensures that the owner and permissions are set correctly. Some applications will not use keys if the permissions to the private key are too open.
The file ending in .pub is the public key that needs to be transferred to the remote systems. It is a file containing a single line: The protocol, the key, and an email used as an identifier. Options for the ssh-keygen command allow you to specify a different identifier:
After generating the key pair, the ssh-keygen command also displays the fingerprint and randomart image that are unique to this key. This information can be shared with other people who may need to verify your public key.
Later you can view these with:
The -l option lists the fingerprint, and the -v option adds the ASCII art.
Propagating the public key to a remote system
If password authentication is currently enabled, then the easiest way to transfer the public key to the remote host is with the ssh-copy-id command. If you used the default name for the key all you need to specify is the remote user and host:
Following the instructions from the output, verify that you can connect using the key pair. If you implemented a passphrase, you will be prompted for the passphrase to use the private key:
Examine the resulting authorized key file. This is where the public key was appended. If the directory or file did not exist, then it was (or they were) created with the correct ownership and permissions. Each line is a single authorized public key:
To revoke access for this key pair, remove the line for the public key.
There are many other options that can be added to this line in the authorized key file to control access. These options are usually used by administrators placing the public keys on a system with restrictions. These restrictions may include where the connection may originate, what command(s) may be run, and even a date indicating when to stop accepting this key. These and more options are listed in the sshd man page.
Changing the passphrase
If you need to change a passphrase on your private key or if you initially set an empty passphrase and want that protection at a later time, use the ssh-keygen command with the -p option:
You can add additional options to specify the key (-f), and the old (-P) or new (-N) passphrases on the command line. Eset nod32 antivirus 10 key generator. Remember that any passwords specified on the command line will be saved in your shell history.
See the ssh-keygen man page for additional options.
Rotating keys
While the public key by itself is meant to be shared, keep in mind that if someone obtains your private key, they can then use that to access all systems that have the public key. These key pairs also do not have a period of validity like GNU Privacy Guard (GPG) keys or public key infrastructure (PKI) certificates.
If you have any reason to suspect that a private key has been stolen or otherwise compromised, you should replace that key pair. The old public key has to be removed from all systems, a new key has to be generated with ssh-keygen, and the new public key has to be transferred to the desired remote systems.
If you are rotating keys as a precaution and without any concern of compromise, you can use the old key pair to authenticate the transfer of the new public key before removing the old key.
Is using empty passphrases ever a good idea?
There are several things to think about when considering an empty passphrase for your SSH private key.
How secure is the private key file?
If you tend to work from multiple client systems and want to either have multiple copies of your key or keep a copy on removable media, then it really is a good idea to have a passphrase on the private key. This practice is in addition to protecting access to the key file with encrypted media.
However, if you have only one copy of the private key and it is kept on a system that is well secured and not shared, then having a passphrase is simply one more level of protection just in case.
Remember that changing the passphrase on one copy does not change the passphrase on other copies. The passphrase is simply locking access to a specific key file.
Why do think you need an empty passphrase?
There are cases for keys with empty passphrases. Some utilities that need to automatically transfer files between systems need a passwordless method to authenticate. The kdump utility, when configured to dump the kernel to a remote system using SSH, is one example.
Another common use is to generate a key pair for a script that is designed to run unattended, such as from a cron job.
How about a middle ground alternative?
By itself, a passphrase-protected private key requires the passphrase to be entered each time the key is used. This setup does not feel like passwordless SSH. However, there are caching mechanisms that allow you to enter the key passphrase once and then use the key over and over without reentering that passphrase.
Public Key Definition
More Linux resources
OpenSSH comes with an ssh-agent daemon and an ssh-add utility to cache the unlocked private key. The GNOME desktop also has a keyring daemon that stores passwords and secrets but also implements an SSH agent.
The lifetime of the cached key can be configured with each of the agents or when the key is added. In many cases, it defaults to an unlimited lifetime, but the cache is cleared when the user logs out of the system. You will be prompted for the passphrase only once per login session.
If there is a scheduled application that needs to run outside of a user login session, it may be possible to use a secret or other password manager to automate the unlocking of the key. For example, Ansible Tower stores credentials in a secure database. This database includes an SSH private key used to connect to the remote systems (managed nodes), and any passphrases necessary for those private keys. Once those credentials are stored, a job can be scheduled to run a playbook on a regular schedule.
Automating propagation
A centralized identity manager such as FreeIPA can assist with key propagation. Upload the public key to the server as an attribute of a user account, and then propagate it to the hosts in the domain as needed. FreeIPA can also provide additional host-based access control for where a key may be used.
Windows 10 Ssh Authorized Keys
Keys can also be distributed using Ansible modules. The openssh_keypair module uses ssh-keygen to generate keys and the authorized_key module adds and removes SSH authorized keys for particular user accounts.
Wrapping up
SSH key pairs are only one way to automate authentication without passwords. Using the Generic Security Services Application Program Interface (GSSAPI) authentication is also common when trying to reduce the use of passwords on a network with centralized user management. SSH key pairs are the easier option to implement when single sign-on (SSO) is not already available.
Many source code repositories grant access using SSH keys. You can upload a public key to an account in the hosting organization such as the Fedora Account System, GitLab, or GitHub sites and use that key pair to authenticate when pulling and pushing content to repositories.
Free Event: Red Hat Summit 2020 Virtual Experience
Ssh Generate Authorized_keys
Attend the Red Hat Summit 2020 virtual experience, April 28-29.