SSH logins and keypairs


Secure Shell (SSH) is a UNIX-based command interface and protocol for securely getting access to a remote computer. SSH is really a set-up of three utilities – slogin, ssh, and scp – that are secure variants of the prior UNIX utilities, rlogin, rsh, and rcp. SSH orders are scrambled(encrypted) and secure in a few different ways. Both ends of the client/server connection are authenticated using a digital certificate, and passwords are protected by being encrypted. SSH permits you to interface with your server securely and perform Linux command-line operations.

There are various reasons why SSH falls flat. Here’s top notch with the greater part of the regular cases:

  • The server probably won’t be designed to acknowledge public key authentication. Ensure /etc/ssh/sshd_config on the server contains line PubkeyAuthentication yes. Make sure to restart the sshd process on the server. Use service sshd restart or systemctl restart network
  • While logging as root, the server probably won’t be configured to permit root logins. Ensure /etc/sshd_config incorporates PermitRootLogin yes, PermitRootLogin prohibit-password, or without-password. If it is set to forced-commands-only, the key must be manually configured to a forced command (see command= option in ~/.ssh/authorized_keys.
  • Ensure the client permits public key authentication. Watch /etc/ssh/config incorporates PubkeyAuthentication yes.
  • Try adding – v option to the ssh command utilized for the test. Peruse the yield to perceive what it says about whether the key is attempted and what authentication methods the server is happy to acknowledge.
  • OpenSSH just permits a limit of five keys to be attempted authomatically. On the off chance that you have more keys, you should indicate which key to utilize utilizing the -i option to ssh.
  • in messages log data about awful responsibility of authorized_keys. Changed consents for my /home/USERNAME/.ssh/authorized_keys to 0600 and that should fix it.
  • opened authorized_keys in vi and delete all of the line breaks – that could likewise help. Finally restart service: /etc/init.d/ssh restart or service sshd restart or systemctl restart network
  • Toward the end The entire reason for authenticating via key file is to evade password authentication, so really you should switch PasswordAuthentication to no
  • NOTE: You copy the key out of the PuTTYGen window as opposed to saving the file, the manner in which you paste may have huge effect on whether your key will work or not. A few editors will change the content as you paste, or accomplish something with newlines or something that makes the authorized_keys file invalid. It’s strongly advisable to use Sublime or Notepad++ for such sensitive cases
  • Likewise the correct sort of key for Putty is utilizing ppk file rather than pem. In the event that public key is made with PuttyGen it makes an enlarged key with pointless lines. If it’s not too much trouble strip it down to a single line ssh-rsa AAAAB…


Comment: "rsa-key-20200919"


ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEAhGF6GIuMY8FJ1RkhpdX1WNOZyy3Bb02Sb4q0hYtaVBUj61yiRFk8HaWtooxx4IEF6qjrxvEH+kmHyuQQKBgQCvjgZpFJiv/ApsUnZHbYXvnSdmNXKReR/TCtlKutsNFSnDY4O2W9ZBWbhaVELKkbQdzCqdV1pc860s5QZpEL2HWSBgBZP0IgXRT6D0aTqUhdKsAaoJxqb7PwuOOPVXrM3Ssho4beLIYUCZuo2qjzQV8wVz/iLMWgd3X2sLgiF9mw==

Ways to import Keys into server

ssh-copy-id installs a SSH key on a server as an authorized key. Its purpose is to arrange access without requiring a password for each login. This encourages automated, passwordless logins and single sign-on utilizing the SSH protocol.

The ssh-copy-id is essential for OpenSSH.

A SSH key is made utilizing ssh-keygen. In the least complex structure, simply run ssh-keygen and answer the questions. The accompanying model illustates this

# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa): newkey
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in newkey.
Your public key has been saved in
The key fingerprint is:
SHA256:GKW7DFSER1qkr1Cr9MhUwAbHbF2NrIPEgZXeOUOz3Us root@localhost
The key's randomart image is:
+---[RSA 2048]----+
|.*++ o.o.        |
|.+B + o.        |
| +++ *+.         |
| .o.Oo.+E        |
|    ++B.S.       |
| o * =.          |
|  + = o          |
| + = =   .       |
|  + o o          |

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/
 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 a6:7b:c7:7a:9d:3c:4d:sw:54:qd:5f:2c:58:b2:cb:76 ~/.ssh/id_rsa (RSA)

The output of this command shows the key size as the first column, the fingerprint as the subsequent section and after the file name, the type is appeared in brackets. In the example above, a 4096 piece RSA key.

The key files are typically stored in the ~/.ssh directory. You ought to never save the file with its contents beginning with —–BEGIN RSA PRIVATE KEY—– on the server, that is your private key. Rather, you should place the public key into the ~/.ssh/authorized_keys file. This public key has the .pub extension when produced utilizing ssh-keygen and its contents start with ssh-rsa AAAAB3…

The authorizations of ~/.ssh on the worker ought to be 700. The file ~/.ssh/authorized_keys (on the server) should have a mode of 600. The consents of the (private) key on the client-side ought to be 600.

On the off chance that the private key isn’t erased you can produce the public key from the private key whenever. You can do this basically with the accompanying command:

ssh-keygen -y -f newkey.pem >

Once the key has been copied, it is best to test it: ssh -i ~/.ssh/newkey 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.

Related posts