You have to follow these properly.
Configure the Public Key in SSH Server
Copy the public key in to SSH Server via SFTP
put publicy_key
Login to SSH server verify the copied public key
ls -l public_key
Since the public key does not have any permissions, change it to 400 (for read)
chmod 400 public_key
Use ssh-keygen tool to create openSSH format public key
ssh-keygen -if public_key > public_key_openssh_format
Add the created openSSH public key to authorized_keys files
cat public_key_openssh_format >> ~/.ssh/authorized_keys
Check the permissions of .ssh folder and authorized_keys file for access permissions
ls -al ~/.ssh
Verify the Key Pairs with PuTTY
Now, the key based authentication can be verified with PuTTY.
Enter the host name and port
Select the private key (.ppk)
Confirm the Security alert
If the configuration is correct, the connection will be established successfully
If you are still stuck. Then you have to re-create the user and follow the steps and configure the public key again.
The user can be recreated using the following command:
Make a copy of the user folder and delete it before recreation.
yast2 users add username=userName cn=" User for test" password="password" gid=100 grouplist=dialout,video type=local
The private key doesn't appear to be in ssh.com format – its headers are a lie.
The first few letters, MII…, decode to bytes 30 82, which is the start of an DER format ASN.1 "sequence" – and SSH.com does not use ASN.1 in its key format, but OpenSSL/OpenSSH does, for unencrypted RSA keys.
(However, if the key had a passphrase, it wouldn't be recognizable this way. See also note at the end.)
In comparison, SSH.com keys are most likely to start with P2/56…, or bytes 3f 6f f9 eb …. This kind of thing is what the words "magic numbers" mean: many formats are recognizable by specific bytes at the beginning – sometimes defined in the format spec, sometimes just a side effect of the data structures.
So if you ignore the text headers and try to Base64-decode the main blob of data, you'll find an ASN.1 structure exactly like OpenSSL uses for its old "bare RSA" format private keys. This is the same format that OpenSSH uses for most private key types.
# cat key.txt | sed "/^---- /d; /^Comment:/d" | base64 -d > key.raw
# dumpasn1 key.raw
0 1212: SEQUENCE {
4 1: INTEGER 0
7 13: SEQUENCE {
9 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
20 0: NULL
: }
22 1190: OCTET STRING, encapsulates {
26 1186: SEQUENCE {
30 1: INTEGER 0
33 257: INTEGER
: 00 DE EC 64 74 20 D3 E8 2B 07 9D C2 AF 17 8D 80
: 91 3B FD 99 C2 5F 6C B1 18 F5 BE A8 85 E0 1B 54
: 74 FF 43 83 3E FD 81 92 28 68 E1 C6 2B 1B 53 8F
: 47 1E B0 19 1D 72 BB DB 53 9A C6 6E A8 9D 39 F9
[etc.]
294 3: INTEGER 65537
[etc.]
# openssl rsa -in key.raw -inform DER -noout -text
Private-Key: (2048 bit)
modulus:
00:de:ec:64:74:20:d3:e8:2b:07:9d:c2:af:17:8d:
80:91:3b:fd:99:c2:5f:6c:b1:18:f5:be:a8:85:e0:
[etc.]
publicExponent: 65537 (0x10001)
privateExponent:
22:4d:2d:12:da:67:48:f2:f0:0f:d4:20:55:87:32:
38:86:ca:d9:b1:39:36:34:14:f3:61:54:34:8f:5c:
[etc.]
[etc.]
As you can see, OpenSSL recognizes it as its own format, containing unencrypted RSA parameters.
You can "recover" this key by:
removing both ---- lines, and the Comment: line
adding -----BEGIN RSA PRIVATE KEY----- at the top
adding -----END RSA PRIVATE KEY----- at the bottom
telling PuTTYgen to import it as an OpenSSH private key
However, with encrypted keys, the headers that OpenSSL expects are somewhat different – in particular, the DEK-Info: header contains the encryption algorithm and the salt (or is it the IV?) that was used for encrypting the data. Without it, you cannot decrypt the key even if you know the passphrase.
So the above steps will work only if the key's passphrase is removed beforehand.
Best Answer
RFC 4716 format is what the "Save public key" command generates:
A public key in the RFC 4716 format looks like: