107

I created key pair using puttygen.exe (client is windows 8). On server (Ubuntu 12.04.3 LTS), I have put my public key in ~/.ssh/authorized_keys. The public key is this:

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAopfM6RHOgnuc4Aftn3t4k5UIAT3StCAbn/vg/IMbphbXadshC+79sIlRq3P4zGzMjFTP4hKnzu6ehLV5lmj/qorq3SKT+bPO5Qrac3VbIlrGvuBFDDjP82I2Hwg3HzlsFTstqk++KToapaTYZ7jENEYyPl2wnzITJnt//+4U1o6juoXTKgdNE02hHnRZyHOV/bnkZyJJCEwJv5U0eXSThQnhmXtUxGT8U0HQNFiXfqIIVllhWiCnyrhhIaKz/CIJNAd2VmzyJzQtJtTQX8aWSNVrZju6Sv2/RncTNvsACdNgjjh/FH8PQXaep00jlJ3MOdsC8vz6VSPFbh6iKy1oLQ== rsa-key-20131231

So it's correct (one line, no comments, starts with ssh-rsa, etc.)

.ssh dir permission level is 700, authorized_keys file permission is 600. Both directory and file owned by the actual user that I try to log in.

When I try connecting I'm getting 'server refused our key' and server asks for password. That's all. Nothing is logged to /var/log/auth.log when attempting to log in with the key.

I've looked everywhere and all articles and tips mention setting chmod 600 and 700 for the file/directory and formatting the key correctly. I've done all this still getting 'refused our key' error and I'm out of ideas.

PawelRoman
  • 6,122
  • 5
  • 30
  • 40
  • 2
    Did you tell Putty to use the same key? are you logging in with the same user? is this a default SSH installation, or did you modify sshd_config? – Noam Rathaus Jan 01 '14 at 06:41
  • Puttygen generates 3 keys: private, public and it's own version of private key with .ppk extension. I'm of course using .ppk with putty.exe and pasted public key into .ssh/authorized_keys on server. It's default SSH installation/configuration, I have not modified sshd_config. – PawelRoman Jan 01 '14 at 10:08
  • BTW, I had to create .ssh directory and auhtorized_keys, because it's fresh Ubuntu installation and it wasn't there. Maybe this has something to do with the issue? – PawelRoman Jan 01 '14 at 10:09
  • Yes, I'm loging in with the same user (the one where ~/.ssh/authorized_keys is) – PawelRoman Jan 01 '14 at 10:11
  • 4
    Make sure sshd_config is configured to use public keys, it might not be – Noam Rathaus Jan 01 '14 at 10:52
  • Also, are you trying to access as root? by default Root login is not allowed – Noam Rathaus Jan 01 '14 at 10:53
  • From what I see sshd_config is configured to use puclic keys by default: RSAAuthentication yes PubkeyAuthentication yes This is sshd_config on a fresh Ubuntu server installation. I'm trying to log in using my username (pawel), and I have my key in /home/pawel/.ssh/authorized_keys – PawelRoman Jan 01 '14 at 16:21
  • 2
    Do you see anything in /var/log/auth.log? increase SSH's logs' LogLevel to `DEBUG` and see if you can see any issues logged, if it still doesn't show you accessing you are looking in the wrong log file – Noam Rathaus Jan 01 '14 at 21:54
  • Thanks for help. See my ansewer below. +1 to you mate. – PawelRoman Jan 04 '14 at 16:00
  • This workaround helped for Putty client: https://askubuntu.com/a/1409528/142864 – snorbi Sep 15 '22 at 18:02

38 Answers38

67

OK, there was a small typo in my key. Apparently when pasting to file the first letter was cut off and it started with sh-rsa instead of ssh-rsa.

nrathathaus - your answer was very helpful, thanks a lot, this answer is credited to you :) I did like you said and set this in sshd_conf:

LogLevel DEBUG3

By looking at the logs I realized that sshd reads the key correctly but rejects it because of the incorrect identifier.

PawelRoman
  • 6,122
  • 5
  • 30
  • 40
  • Which logs did you check and where are they? What is the identifier, you are talking about? – user1046647 Apr 18 '14 at 12:40
  • 4
    @user1046647 `LogLevel` is defined in `/etc/ssh/sshd_config`. The default log is `/var/log/auth.log` unless defined otherwise in `sshd_config`. – Axel Kemper Feb 08 '15 at 15:10
  • There must be something with the key generator because I had the same exact problem! – Kevin Aug 13 '16 at 00:42
  • 4
    If you open authorized_key in vim and immediately try to paste the first 's' from the 'ssh_rsa" is treated as vim command after which vim will switch to the insert mode and the remaining text is being pasted. If you enter the insert mode before pasting (e.g. using `i`) the leading 's' won't be cut. – Pawel Aug 22 '16 at 19:34
  • 2
    ! `sudo service ssh restart` for the changes to take effect. Otherwise there was nothing in my auth log-file. – hogan Nov 18 '16 at 20:02
  • I enabled LogLevel and restarted ssh service but couldn't find auth.log file in /var/log folder. (I am using CentOs 6.9 and OpenSSH_5.3p1, OpenSSL 1.0.1e-fips) I have another user except root and that is working fine. Only root is getting above error. Other folder and file permissions are correct. – Chaminda Bandara Feb 02 '18 at 10:24
  • Same problem. This usually happens if you paste your key into vim without being in insert mode first. – BugHunterUK Aug 29 '18 at 12:27
38

Adding a few thoughts as other answers helped, but were not exact fit.

First of all, as mentioned in accepted answer, edit

/etc/ssh/sshd_config

and set log level:

LogLevel DEBUG3

Then restart sshd on the server to have it use the changed log level, e.g.:

sudo service ssh restart

Then try to authenticate, and when it fails, look for log file:

/var/log/secure

It will have errors you are looking for.

Abdull
  • 26,371
  • 26
  • 130
  • 172
Ranty
  • 3,333
  • 3
  • 22
  • 24
  • `/var/log/` exists, but `secure` does not exist. How do I discover which log is being written to? – aliteralmind Aug 09 '14 at 17:23
  • 13
    The default is `/var/log/auth.log`, at least in my Ubuntu 14.04.1. – Axel Kemper Feb 08 '15 at 15:12
  • YES! thank you! turns out my pub key file had an invisible \n at the end – alextsil Jan 22 '18 at 20:21
  • 1
    Linux/Ubuntu is so frustrating. Spent a good 20 minutes trying to figure out why there was no `secure` file before reading @axel comments here. – JYelton Jul 02 '18 at 15:04
  • I couldn't find any ubuntu log file, I eventually read the logs using "journalctl -t sshd -b0 -r" as mentioned in https://serverfault.com/a/1054725/698635 – Nir Feb 14 '23 at 18:48
23

In my case I had to change the permissions of /home/user from 0755 to 0700 as well.

Atif
  • 821
  • 2
  • 10
  • 15
22

In my case, is a permission problem.

I changed the log level to DEBUG3, and in /var/log/secure I see this line:

Authentication refused: bad ownership or modes for directory

Googled and I found this post:

https://www.daveperrett.com/articles/2010/09/14/ssh-authentication-refused/

chmod g-w /home/$USER
chmod 700 /home/$USER/.ssh
chmod 600 /home/$USER/.ssh/authorized_keys

Basically, it tells me to:

  • get rid of group w permission of your user home dir
  • change permission to 700 of the .ssh dir
  • change permission to 600 of the authorized_keys file.

And that works.

Another thing is that even I enabled root login, I cannot get root to work. Better use another user.

Smart Manoj
  • 5,230
  • 4
  • 34
  • 59
WesternGun
  • 11,303
  • 6
  • 88
  • 157
  • 4
    This answer was under-voted. The overlooked permissions of the home directory may cost you a whole day to troubleshoot. – chingNotCHing Aug 21 '18 at 10:14
  • Thanks for voting up for me. I just share what I got. – WesternGun Aug 21 '18 at 10:28
  • For anyone coming here trying to understand where the `'bad ownership or modes for directory'` error comes from, I'm posting here because it took me quite a bit of searches to find it myself. This is enforced by the [`StrictModes`](https://man.openbsd.org/sshd_config#StrictModes) setting in `sshd_config`. It's not recommended to disable, but it is helpful for troubleshooting. – Lockszmith Dec 31 '21 at 16:50
9

Running Windows 8.1 I ran into the server refused our key problem.

Following the guide: https://winscp.net/eng/docs/guide_windows_openssh_server It was easy to make a connection using the Windows login username and password. However, authenticating with the username in combination with a private key, the response was server refused our key.

Getting it to work with a public key came down to the permissions on the file: C:\ProgramData\ssh\administrators_authorized_keys

This is a helpful page: https://github.com/PowerShell/Win32-OpenSSH/wiki/Troubleshooting-Steps

Stop the two OpenSSH services, then open a command prompt with admin permissions. Then run: C:\OpenSSH-Win32>c:\OpenSSH-Win32\sshd.exe -ddd

Note: specify the full path to the exe otherwise sshd complains. This creates a one-time use connection listener. The -ddd is verbose level 3.

After making a connection, scanning the logs revealed:

debug1: trying public key file __PROGRAMDATA__/ssh/administrators_authorized_keys
debug3: Failed to open file:C:/ProgramData/ssh/administrators_authorized_keys error:2
debug1: Could not open authorized keys '__PROGRAMDATA__/ssh/administrators_authorized_keys':
        No such file or directory

Had to create the file: C:\ProgramData\ssh\administrators_authorized_keys And copy the public key text into it, e.g: ssh-rsa AAAA................MmpfXUCj rsa-key-20190505 And then save the file. I saved the file as UTF-8 with the BOM. Didn't test ANSI.

Then running the one-time command line again, in the logs showed:

debug1: trying public key file __PROGRAMDATA__/ssh/administrators_authorized_keys
debug3: Bad permissions. Try removing permissions for user: S-1-5-11 on file C:/ProgramData/ssh/administrators_authorized_keys.
        Authentication refused.

S-1-5-11 is the name given to the System.

To fix the Bad permissions, right click on the administrators_authorized_keys file, goto the Security Tab , click the Advanced button and remove inherited permissions. Then delete all Group or user names: except for the Windows login username, e.g: YourMachineName\username The permissions for that username should be Read Allow, Write Deny everything else is unchecked. The owner of the file should also be YourMachineName\username

This fixed the problem.

Other Useful links:

Download OpenSSH-Win32.zip from: https://github.com/PowerShell/Win32-OpenSSH/releases

C# example of how to use the WinSCPnet.dll to make a connection to the OpenSSH server: https://winscp.net/eng/docs/library#csharp

Here is the code snippet to make a connection using the WinSCPnet.dll:

static void WinSCPTest() {
    SessionOptions ops = new SessionOptions {
        Protocol = Protocol.Sftp, 
        PortNumber = 22,
        HostName = "192.168.1.188", 
        UserName = "user123",
        //Password = "Password1",
        SshHostKeyFingerprint = @"ssh-rsa 2048 qu0f........................ddowUUXA="
    };

    ops.SshPrivateKeyPath = @"C:\temp\rsa-key-20190505.ppk";

    using (Session session = new Session()) {
        session.Open(ops);
        MessageBox.Show("success");
    }
}

Replace SshHostKeyFingerprint and SshPrivateKeyPath with your own values.

Edit: added screenshot of administrators_authorized_keys file permissions: enter image description here

When OpenSSH SSH Server is running as a Service, then only System should have permission. However, if running sshd.exe from the command prompt, then the current user should be the only one listed (read allow, write deny).

Loathing
  • 5,109
  • 3
  • 24
  • 35
  • 3
    You have done many things here that helped. First running sshd with debug flag on command line. Windows Service System logs showed very little and was totally useless to debug. Second, the main fact that as an Administrator there is a bug that only looks in the administrators_authorized_keys file and not the expected Users .ssh folder for authorized_keys (everybody's point of grief running sshd on Windows). Finally the 'ssh' folder in ProgramData! I was wondering where it was putting the server certs etc. So only your information here helped me after scratching my head for a day or so. Thanks! – Master James May 25 '19 at 22:56
  • this answer was the only one which worked for me on a fresh ec2 instance windows 2019 free tier. – yolob 21 Jul 05 '20 at 20:27
4

The simple solution i found was to move the authorized_keys file away from the hidden .ssh directory and put it in the system ssh directory:

/etc/ssh/keys/authorized_keys

As soon as I did this it worked with no problems.

abatishchev
  • 98,240
  • 88
  • 296
  • 433
mrbronz
  • 41
  • 1
4

having same issue in windows server 2008 r2 and explored a lot to solve, finally did that by following:

open C:\Program Files (x86)\OpenSSH\etc\sshd_config with textpad or any other text editor

remove comment from following lines, after removing they should look like following:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

save it and try to login with private key now. have fun.

Ravi Anand
  • 5,106
  • 9
  • 47
  • 77
  • ssh sometimes is installed w/ the authorizedkeysfile line commented out so it doesn't know where to look for the authorized keys file :-( – kenyee Aug 26 '18 at 18:28
  • What are the permissions needed for the authorized_keys file? And does it have to be in the user directory or in the directory of OpenSSH? – GarfieldKlon Oct 09 '18 at 07:30
  • It should be on OpenSSH directory or where you installed your OpenSSH. you should be able to find it – Ravi Anand Oct 09 '18 at 09:04
  • Make sure, you are setting it up using Admin account. – Ravi Anand Oct 09 '18 at 09:05
4

If you run Putty in a version before 0.75, then updating Putty should solve the problem.

Newer version of openSSH (as in Ubuntu 22.04) have deprecated the use of the SHA1 hashing algorithm during the login, but Putty used SHA1 until version 0.74.

If sshd log file on the server shows

$ sudo grep 'sshd' /var/log/auth.log
sshd[113232]: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]

then this in fact is causing the error, and it should be gone after Putty has been updated.

not2savvy
  • 2,902
  • 3
  • 22
  • 37
3

I'm adding this answer to help anyone, like me, who spent hours scouring the internet without success.

YOUR HOME FOLDER MIGHT BE ENCRYPTED.

Or for that matter any folder in which your "authorized_keys" file is nested. Man, that would have saved me a lot of time. To check, go perform

ls -A

on the directory whose encryption status you would like to determine. If the folder contains a folder named ".encryptfs" the answer is, yes, that folder is encrypted. This will impede your ability to access the "authorized_keys" file containing the public ssh key needed for verification.

To fix this, place the "authorized_key" file in a directory tree that contains no encryption.

Mackie Messer
  • 1,126
  • 2
  • 8
  • 22
3

After adding key, login as ec2-user if you are using an Amazon Linux machine

If its ubuntu machine then use ubuntu

sachin_ur
  • 2,375
  • 14
  • 27
2

Thanks to nrathaus and /var/log/auth.log investigation on debug level comes the following.

Another reason is that your home directory may have permissions different than 755.

Stefan Ferstl
  • 5,135
  • 3
  • 33
  • 41
Intel83
  • 21
  • 2
2

In my case it was caused by (/etc/ssh/sshd_config):

PermitRootLogin no

Changed to yes, restarted the service and got in normally.

Alex Fortuna
  • 1,223
  • 12
  • 16
2

I have solved this problem,puttygen is a third-party software, ssh key which generated by it didn't be used directly, so you must make some changes. For example, it look like this

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20170502"
AAAAB3NzaC1yc2EAAAABJQAAAQEAr4Ffd3LD1pa7KVSBDU+lq0M7vNvLp6TewkP7
*******C4eq1cdJACBPyjqUCoz00r+LqkGA6sIFGooeVuUXTOxbYULuNQ==
---- END SSH2 PUBLIC KEY ---- 

I omit some of the alphabets in the middle, replaced by *, if not, StackOverflow told me that the code format is wrong, do not let me post。

this is my ssh key generated by puttygen, you must change to this

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAr4Ffd3LD1pa7KVSBDU+lq0M7vNvLp6TewkP7wfvKGWWR7wxA8GEXJsM01FQw5hYWbNF0CDI7nCMXDUEDOzO1xKtNoaidlLA0qGl67bHaF5t+0mE+dZBGqK7jG9L8/KU/b66/tuZnqFqBjLkT+lS8MDo1okJOScuLSilk9oT5ZiqxsD24sdEcUE62S8Qwu7roVEAWU3hHNpnMK+1szlPBCVpbjcQTdiv1MjsOHJXY2PWx6DAIBii+/N+IdGzoFdhq+Yo/RGWdr1Zw/LSwqKDq1SmrpToW9uWVdAxeC4eq1cdJACBPyjqUCoz00r+LqkGA6sIFGooeVuUXTOxbYULuNQ== yourname@hostname

In my case, I have deleted some comments, such as

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20170502"
---- END SSH2 PUBLIC KEY ----

and add ssh-rsa at the beginning, add yourname@hostname at the last. note: not delete== in the last and you must change "yourname" and "hostname" for you, In my case, is uaskh@mycomputer,yourname is that you want to log in your vps .when all these things have done,you could to upload public-key to uaskh's home~/.ssh/authorized_keys by cat public-key >> ~/.ssh/authorized_keys then sudo chmod 700 ~/.ssh sudo chmod 600 ~/.ssh/authorized_keys then you must to modify /etc/ssh/sshd_config, RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys my operating system is CentOS 7,This is my first time to anwser question,I will try my efforts to do ,Thank you!

The Hungry Dictator
  • 3,444
  • 5
  • 37
  • 53
nuclear
  • 3,181
  • 3
  • 19
  • 38
  • 1
    @Ronak Bhatt, Thank you efforts for me, I tried to make codes clearer, for all this code I used ctrl + K, but StackOverflow told me "your answer appeal contain codes, please use correct format", and I don't why it's different between written and submitted, I cannot submit my answer, which leads me to have to add codes in 'code' line by line. I will learn markdown format, thinks. – nuclear May 03 '17 at 05:29
  • 1
    In the current version PuttyGen will show the public key in the correct format for copy&paste. So there is no need anymore to manually convert the putty pub key to the correct format. – Erik Kalkoken Aug 19 '19 at 13:11
  • @ErikKalkoken yes, the copy-paste of the public key worked for me. I don't know why save public key is not in the correct format. I saved the public key using save public key button and copied it to server. But the format was not working as mentioned by nuclear in his answer. The sad part is I didn't scroll down to this answer before figuring out myself. But thanks for this answer and your comment. – Vivek Agrawal Jun 07 '21 at 08:15
2

I encountered this problem today and my issue was that when copying the public key from file, new line characters are included as well. You can use ":set list" in vim to see all the hidden new lines and make sure to delete all the new lines except for the last one. Also, my key was missing "ssh-rsa " in the beginning. Make sure you have that as well.

hyeuc
  • 47
  • 3
  • 1
    Similar here: when copying from PuttyGen, I had new lines after "ssh-rsa " and after the key. After removing them, it worked. – Lucian P. Jul 28 '18 at 09:13
2

The equivilent of an SSH command:

ssh -i <path_to_pem_file> ec2-user@calendar.com

In Windows, first use PuTTYGen to convert the pem file to a ppk file.

  1. Open PuTTYGen
  2. File/Load the private pem key (or an OpenSSH key)
  3. In the Open FileDialog, use the drop down to select "All files" (it only shows ppk file formats not pem, also OpenSSH key files that can be converted like pem files don't have a file extension)
  4. File/Save private key (*.ppk)

The same settings in Putty as the SSH command:

  1. Open Putty
  2. Session/Hostname: calendar.com
  3. Connection/Data/Auto-login username: ec2-user
  4. Connection/SSH/Auth/PrivateKeyFile Path: the file path to the PPK file
Jeremy Thompson
  • 61,933
  • 36
  • 195
  • 321
2

OpenSSH disable the ssh-rsa signature scheme by default in the next release.

In the SSH protocol, the "ssh-rsa" signature scheme uses the SHA-1 hash algorithm in conjunction with the RSA public key algorithm. It is now possible1 to perform chosen-prefix attacks against the SHA-1 algorithm for less than USD$50K.

Source

So, update the key.

Smart Manoj
  • 5,230
  • 4
  • 34
  • 59
2

This helps to me:

# /etc/ssh/sshd_config
PubkeyAuthentication yes
PubkeyAcceptedKeyTypes=+ssh-rsa

# temporarily added:
LogLevel DEBUG3
# gentoo
# tail -n 50 /var/log/messages

and restart sshd

/etc/init.d/sshd restart
  • Debug3 showed "userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms", fixed by adding "PubkeyAcceptedKeyTypes=+ssh-rsa". More info https://bbs.archlinux.org/viewtopic.php?id=270005 – bubu Oct 01 '22 at 16:19
1

For those receiving this error from Windows Server, I received this same error and it was a user account issue. With many organizations, group policy for Administrators may not allow setting up SSH Server and connections. With that type of setup, this must be done from Local Admin account. Might be worth looking into if you have confirmed there are not any typos in the public key.

Andrew Campbell
  • 17,665
  • 2
  • 16
  • 25
1

In my case, I had to disable SELinux on Centos6.6 to get it working :)

Edit /etc/selinux/config and set the following and then reboot the host.

selinux=disabled

BTW...forgot to mention that I had to set the LogLevel=DEBUG3 to identify the issue.

sagaya
  • 11
  • 1
  • 1
    Rather than disabling SELinux you can change the security context on the .ssh folder. chcon -R -t ssh_home_t .ssh – palehorse Jul 23 '15 at 15:27
1

I had the same error on solaris but found in /var/adm/splunk-auth.log the following:

sshd: [auth.debug] debug1: PAM conv function returns PAM_SUCCESS
sshd: [auth.notice] Excessive (3) login failures for weblogic: locking account.
sshd: [auth.debug] ldap pam_sm_authenticate(sshd-kbdint weblogic), flags = 1
sshd: [auth.info] Keyboard-interactive (PAM) userauth failed[9] while authenticating: Authentication failed

In /etc/shadow the account was locked:

weblogic:*LK*UP:16447::::::3

Removed the "*LK*" part:

weblogic:UP:16447::::::3

and I could use ssh with authorized_keys as usual.

1

I have this issue where sshd only reads from authorized_keys2.

Copying or renaming the file fixed the problem for me.

cd  ~/.ssh
sudo cat authorized_keys >> authorized_keys2

P.S. I'm using Putty from Windows and used PuTTyKeygen for key pair generation.

Pang
  • 9,564
  • 146
  • 81
  • 122
Chad Liu
  • 11
  • 1
1

I was facing similar issue when trying to logon through Mobaxterm. The private key was generated through puttygen. Regenerating the key helped in my case.

Prada
  • 11
  • 2
1

As my experience, I suggest you should generate keys from putty, should not generate from linux side. Because the key will be old PEM format. Anyway, just my suggestion. I did as steps below and worked fine with me and with my team.

  1. Generate a key pair with PuTTYGen.exe on your local (type: RSA, length: 2048 bits).

  2. Save private/public key as "id_rsa.ppk/id_rsa.pub" files on your local.

  3. Create "authorized_keys" file on your local, then enter the public key in "id_rsa.pub" to "authorized_keys". Remember content has to begin with "ssh-rsa" and one line only.

enter image description here

  1. Use WinScp (or putty command) to copy "authorized_keys & id_rsa.pub" from your local to your linux-user-home "/home/$USER/.ssh/".

enter image description here

  1. Run these commands:

    chmod 700 .ssh

    chmod 600 .ssh/authorized_keys

    chown $USER:$USER .ssh -R

  2. Test your connect setting by load the private key "id_rsa.ppk" in the PuTTY.exe profile, then click open (put your passphrase if have).

enter image description here

enter image description here

m.nguyencntt
  • 935
  • 13
  • 19
1

check your key, this should be a rsa (id_rsa.pub) key today and no longer a dss (id_dsa.pub) key, use puttygen 0.70 and choose RSA on type of key to generate, replace the public key on host ~/.ssh/authorized_keys

Don Matteo
  • 85
  • 1
  • 8
1

Oh my God I spent days trying to fix this. So here is what worked for me. I went back to the root fold like this: cd /root/ mkdir .ssh cd .ssh chmod 700 .ssh nano -w authorized_keys service ssh restart So I used root to logging via Putty and it worked. so try to do the same with the user you want to use in putty.

1

In the case of mine it was a wrong user:group attribution. I solved setting the right user and group:

sudo chown [user]:[group] -R /home/[user]
Fede
  • 11
  • 1
1

I was running putty 0.70 and had to upgrade to the newest version. It worked correctly for ubuntu 18, but when running version 22 it threw the above error.

0

I'm using a PUTTYgen file with psftp, and I encountered this problem on my Windows Server when we were required to create new keys for a client. The private_key_name.ppk file and the open_ssh.txt file must be in the same directory for the connection to work.

0

In my case home on nfs was 777, needed to be 750. That fixed the issue.

dghadge
  • 11
0

When using Cpanel you can check if the key is authorized in

SSH Access >> Public keys >> Manage >> Authorize or Deauthorize.

Tomás Cot
  • 992
  • 1
  • 8
  • 18
0

if you get this error in /var/log/secure

error: key_read: key_from_blob AA
AAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswD

it means your key is having space, if you generated key through puttgen when you view .ppk file, it will look like this:

AAAAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswD
al74MLaJyhQD0pE23NS1izahbo1sJGnSJu2VJ//zxidSsba6xa6OvmeiKTwCz0E5
GMefdGVdpdbTlv99qjBl1+Nw1tDnHIC0+v9XmeZERQfCds9Kp1UivfReoYImntBC
gLtNyqRYrSu8csJCt7E1oY8QK6WP1vfYgAQ2taGyS9+g7FHyyf5VY2vH3oWzzbqz
xjsSLAv3zEQSm1LzSw9Pvc8iwasFyUMBOPj31CKQYTXyX8KpJTr0Zb7oqMauBE5L
VwxZhlcJHbj0FsMbF/+GRjvgexymCi3bHmwGQ6FEADNd0RkhdQ==

and when you try to paste it you will get an error in reading key, so try to edit key and make it one line and try it

this should look like something

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswDal74MLaJyhQD0pE23NS1izahbo1sJGnSJu2VJ//zxidSsba6xa6OvmeiKTwCz0E5GMefdGVdpdbTlv99qjBl1+Nw1tDnHIC0+v9XmeZERQfCds9Kp1UivfReoYImntBCgLtNyqRYrSu8csJCt7E1oY8QK6WP1vfYgAQ2taGyS9+g7FHyyf5VY2vH3oWzzbqzxjsSLAv3zEQSm1LzSw9Pvc8iwasFyUMBOPj31CKQYTXyX8KpJTr0Zb7oqMauBE5LVwxZhlcJHbj0FsMbF/+GRjvgexymCi3bHmwGQ6FEADNd0RkhdQ== username@domainname

Shayki Abramczyk
  • 36,824
  • 16
  • 89
  • 114
0

What works for me is that:

  • Stopped the ec2 instance
  • detach the volume
  • attach the volume with the old instance using the same key and was able to SSH
  • mount the volume in some temp folder
  • checked the file in the directory mount_point/home/ec2-user/.ssh/authorized_keys
    • Ideally, this file needs to have our key information but for me this file was empty
  • copied the old instance authorized_keys file to the newly mounted volume
  • unmount the device
  • reattach to the original ec2 instance
  • start it and let it pass the health checks

This time it works for me. But I don't know why it doesn't have my key file information at first when the instance was launched. Check this link too https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html#TroubleshootingInstancesConnectingMindTerm

0

On my case the problem was like this, during the generation of ssh keys I intentionally changed the default directories of the keys. So instead of using the location ~/.ssh/authorized_keys I chose to use ~/home/user/folder1/.ssh/authorized_keys, for these changes to work I was supposed to make the same changes of about the new location on this file /etc/ssh/sshd_config. But until I am realising this I had already tried several solutions suggested by other people here including setting the permission of home folder to 700 and the .ssh directory to 600.

0

Steps to fix Root mount (That i followed as i changed permission with ec2-user folder and the authorization key file) This process will be similar to detach and attach a pen-drive

Below are some other scenarios you may encounter -

  1. You're using an SSH private key but the corresponding public key is not in the authorized_keys file.
  2. You don't have permissions for your authorized_keys file.
  3. You don't have permissions for the .ssh folder.
  4. Your authorized_keys file or .ssh folder isn't named correctly.
  5. Your authorized_keys file or .ssh folder was deleted.

Steps to fix them

  • Stop the problematic Ec2 instance
  • Detach the root volume (/dev/sda1)
  • Create an ec2 instance or use an running one
  • Mount the detached volume (/dev/sdvf) to new ec2 instance

Now after you login to new ec2 run below steps

  • Lsblk command - list all available mounts
  • Pick the mount value that you unmount from the problematic instance
  • As ec2-user run “sudo mount /dev/mapper/rootvg-home /mnt” sudo mount /dev/mapper/rootvg-home /mnt
  • Then change directory to /mnt
  • Make all necessary changes

Now we have fixed our volume with the issue that we faced. Mostly it could be user permission issue - Umount /mnt to unmounts it - Now go to the console and point to the volume attached to new instance and detach it - After detached, attached it to your new volume as /dev/sda1

With that said you should be able to login successfully

0

I just updated Putty since I could connect with WinSCP. Now it works with Putty as well

0

Before trying all of the answers one by one, try updating your Putty. Putty 0.74 had this problem. If you are sure your settings are correct, first try updating Putty to at least 0.77

Gökhan Mete ERTÜRK
  • 3,378
  • 2
  • 19
  • 23
0

In my case I did the following things to make it work (Using Windows 10 with PuTTY and Raspberry Pi 4b running Ubuntu Desktop 22.10 x64):

I'd been at war with this issue for two days and nothing seemed to work until I tried these simple steps.

  1. Use latest available version of PuTTY
  2. Right click on the public key string in PuTTYgen and pick "Select All" before copying it
  3. When creating the ".ssh" directory, "authorized_keys" file and running chmod command make sure not to use the sudo command
  4. Remember also to always edit the authorized_key file as the currently logged in user and not with sudo command

Worked like a charm

dexcaped
  • 1
  • 2
-1

Another reason could be UTF-8 BOM in the authorized_keys file.

TN.
  • 18,874
  • 30
  • 99
  • 157