Secure Shell (SSH) is a UNIX-based command interface and protocol for securely getting access to a remote computer. SSH is actually a suite of three utilities – slogin, ssh, and scp – that are secure versions of the earlier UNIX utilities, rlogin, rsh, and rcp. SSH commands are encrypted and secure in several ways. Both ends of the client/server connection are authenticated using a digital certificate, and passwords are protected by being encrypted.SSH allows you to connect to your server securely and perform Linux command-line operations.
There are multiple reasons why SSH fails. Here’s a list with most of the common cases:
- The server might not be configured to accept public key authentication. Make sure /etc/ssh/sshd_config on the server contains line PubkeyAuthentication yes. Remember to restart the sshd process on the server. Use service sshd restart or systemctl restart network
- If trying to login as root, the server might not be configured to allow root logins. Make sure /etc/sshd_config includes PermitRootLogin yes, PermitRootLogin prohibit-password, or without-password. If it is set to forced-commands-only, the key must be manually configured to use a forced command (see command= option in ~/.ssh/authorized_keys.
- Make sure the client allows public key authentication. Check that /etc/ssh/config includes PubkeyAuthentication yes.
- Try adding -v option to the ssh command used for the test. Read the output to see what it says about whether the key is tried and what authentication methods the server is willing to accept.
- OpenSSH only allows a maximum of five keys to be tried authomatically. If you have more keys, you must specify which key to use using the -i option to ssh.
- in messages log information about bad ownership of authorized_keys. Changed permissions for my /home/USERNAME/.ssh/authorized_keys to 0600 and that should fix it.
- opened authorized_keys in vi and remove all of the line breaks – that could also help
Finally restart service: /etc/init.d/ssh restart or service sshd restart or systemctl restart network - At the end The whole purpose of authenticating via key file is to avoid password authentication, so actually you should reverse PasswordAuthentication to no
- NOTE: You copy the key out of the PuTTYGen window instead of saving the file, but after copying, the way you paste may have significant impact on whether your key will work or not. Some editors will alter the text as you paste, or do something with newlines or something that makes the authorized_keys file invalid.
It’s strongly advisable to use Notepad++ for such sensitive cases - Also the right type of key for Putty is using ppk file instead of pem. If public key is created with PuttyGen it creates a bloated key with unnecessary lines. Please strip it down to a single line ssh-rsa AAAAB…
From
---- BEGIN SSH2 PUBLIC KEY ---- Comment: "rsa-key-20121022" AAAAB3NzaC1yc2EAAAABJQAAA a6N1nFpBklz1+dsIMg4rcTLc tr7mmimiTjkoSCrJh1kqalPS ---- END SSH2 PUBLIC KEY ----
To:
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEAhGF6GIuMY8FJ1+CNApnSY1N2YSlkYz72Yvwua6N1nFpBklz1+dsIMg4rcTLcF34M/tW5Yz+NUDAw2AEbxQ32FPgw7sAOIXktkYOHtr7mmimiTjkoSCrJh1kqalPSpi8rglT/Bp67Ql2SZwvUFfMzHISryR0EZC4rXP/uvObrJe8= rsa-key-20190901
Ways to import Keys into server
ssh-copy-id installs an SSH key on a server as an authorized key. Its purpose is to provision access without requiring a password for each login. This facilitates automated, passwordless logins and single sign-on using the SSH protocol.
The ssh-copy-id tool is part of OpenSSH.
An SSH key is created using ssh-keygen. In the simplest form, just run ssh-keygen and answer the questions. The following example illustates this
# ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/me/.ssh/id_rsa): mykey Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in mykey. Your public key has been saved in mykey.pub. The key fingerprint is: SHA256:GKW7yzA1J1qkr1Cr9MhUwAbHbF2NrIPEgZXeOUOz3Us root@localhost The key's randomart image is: +---[RSA 2048]----+ |.*++ o.o. | |.+B + o. | | +++ *+. | | .o.Oo.+E | | ++B.S. | | o * =. | | + = o | | + = = . | | + o o | +----[SHA256]-----+ #
When you have an SSH key you need the public key to setup SSH passwordless login with SSH-key. But if you have lost the public key part but still have the private key, there is a way to regenerate the key.
With the public key missing, the following command will show you that there is no public key for this SSH key.
$ ssh-keygen -l -f ~/.ssh/id_rsa test is not a public key file.
The -l option instructs to show the fingerprint in the public key while the -f option specifies the file of the key to list the fingerprint for.
To generate the missing public key again from the private key, the following command will generate the public key of the private key provided with the -f option.
$ ssh-keygen -y -f ~/.ssh/id_rsa > ~/.ssh/id_rsa.pub Enter passphrase:
The -y option will read a private SSH key file and prints an SSH public key to stdout. The public key part is redirected to the file with the same name as the private key but with the .pub file extension. If the key has a password set, the password will be required to generate the public key.
To check the details of the generated public key execute the following command as shown above.
$ ssh-keygen -l -f ~/.ssh/id_rsa 4096 d6:7b:c7:7a:4f:3c:4d:29:54:62:5f:2c:58:b2:cb:86 ~/.ssh/id_rsa (RSA)
The output of this command shows the key size as the first column, the fingerprint as the second column and after the file name, the type is shown in brackets. In the example above, a 4096 bit RSA key.
The key files are usually stored in the ~/.ssh directory. You should never save the file with its contents starting with —–BEGIN RSA PRIVATE KEY—– on the server, that is your private key. Instead, you must put the public key into the ~/.ssh/authorized_keys file. This public key has the .pub extension when generated using ssh-keygen and its contents begin with ssh-rsa AAAAB3…
The permissions of~/.ssh on the server should be 700. The file ~/.ssh/authorized_keys (on the server) is supposed to have a mode of 600. The permissions of the (private) key on the client-side should be 600.
If the private key is not deleted you can generate the public key from the private key at any time. You can do this simply with the following command:
ssh-keygen -y -f key.pem > key.pub
Once the key has been copied, it is best to test it: ssh -i ~/.ssh/mykey user@host
Best practices for SSH keys
- SSH keys are very useful, but can lead to problems if they are not properly managed. They are access credentials just like user names and passwords. If they are not properly removed when people leave or systems are decommissioned, no-one may any longer know who really has access to which systems and data. Many large organizations have ended up having millions of SSH keys.
Use a passphrase when possible - It is recommended that keys used for single sign-on have a passphrase to prevent use of the key if it is stolen or inadvertatly leaked. The ssh-agent and ssh-add programs can be used to avoid having to enter the passphrase every time the key is used. Generally all keys used for interactive access should have a passphrase. Keys without a passphrase are useful for fully automated processes. They allow shell scripts, programs, and management tools to log into servers unattended. This is often used for backups and data transfers between information systems.
Add a command restriction when possible - The copy-id tool does not automatically add command restrictions to keys. Using command restrictions is highly recommended when the key is used for automating operations, such as running a report for fetching some files. A command restriction is basically a command=”” option added to the beginning of the line in the server’s authorized_keys file.
Managing SSH keys - Anyone having more than a few dozen servers is strongly recommended to manage SSH keys. Not managing the keys exposes the organization to substantial risks, including loss of confidentiality, insertion of fraudulent transactions, and outright destruction of systems.