blocks|key|4682228|text|好吧，我的钥匙有一个小的打字错误。显然，在粘贴到文件时，第一个字母被截断，并以sh-rsa开头，而不是ssh-rsa。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4682229|nrathathaus+-你的回答非常有帮助，非常感谢，这个答案归功于你:)我照你说的做了，并在sshd_conf中设置了这个：|4682230|LogLevel+DEBUG3|code-block|syntax|javascript|4682231|通过查看日志，我意识到sshd正确地读取了密钥，但由于标识符不正确而拒绝了它。|4682232|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|O|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

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:

<pre><code>LogLevel DEBUG3
</code></pre>

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

blocks|key|176152|text|另一个原因可能是authorized_keys文件中的UTF-8+BOM。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|176153|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Byte_order_mark^0|8|F|R|9|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@$9|O|A|P|B|C]]|D|@$9|Q|A|R|1|S]]|E|$]]|$1|F|3|-4|5|6|7|T|8|@]|D|@]|E|$]]]|G|$H|$5|I|J|K|E|$L|M]]]]

Another reason could be <a href="http://en.wikipedia.org/wiki/Byte_order_mark" rel="nofollow">UTF-8 BOM</a> in the <code>authorized_keys</code> file.

blocks|key|4682293|text|对于那些从Windows+Server收到此错误的人，我也收到了同样的错误，这是一个用户帐户问题。对于许多组织，管理员的组策略可能不允许设置SSH服务器和连接。使用该类型的设置时，必须从本地管理员帐户执行此操作。如果您已确认公钥中没有任何拼写错误，则可能值得一查。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4682294|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|4682323|text|添加一些想法作为其他答案有所帮助，但并不完全符合。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4682324|首先，正如在接受答案中提到的，编辑|4682325|/etc/ssh/sshd_config|code-block|syntax|javascript|4682326|并设置日志级别：|4682327|LogLevel+DEBUG3|4682328|然后尝试身份验证，并在失败时查找日志文件：|4682329|/var/log/secure|4682330|它将包含您正在查找的错误。|4682331|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|W|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|X|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|Y|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|Z|8|@]|9|@]|A|$]]|$1|O|3|P|5|F|7|10|8|@]|9|@]|A|$G|H]]|$1|Q|3|R|5|6|7|11|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|T|$]]

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

First of all, as mentioned in accepted answer, edit

<pre><code>/etc/ssh/sshd_config
</code></pre>

and set log level:

<pre><code>LogLevel DEBUG3
</code></pre>

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

<pre><code>/var/log/secure
</code></pre>

It will have errors you are looking for.

blocks|key|4682383|text|在我的例子中，我不得不在Centos6.6上禁用SELinux才能让它工作:)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4682384|编辑/etc/selinux/config并设置以下内容，然后重新启动主机。|4682385|selinux=disabled|code-block|syntax|javascript|4682386|BTW...forgot提到我必须设置LogLevel=DEBUG3来识别问题。|4682387|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|O|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

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.

<pre><code>selinux=disabled
</code></pre>

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

blocks|key|4682435|text|我添加这个答案是为了帮助任何人，像我一样，花了几个小时在互联网上搜索，但没有成功。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4682436|您的主文件夹可能已加密。|4682437|或者任何嵌套你的"authorized_keys“文件的文件夹。伙计，那会节省我很多时间的。要进行检查，请执行|4682438|ls+-A|code-block|syntax|javascript|4682439|在您要确定其加密状态的目录上。如果文件夹包含名为".encryptfs“的文件夹，答案是，是的，该文件夹是加密的。这将阻碍您访问包含验证所需的公共ssh密钥的"authorized_keys“文件。|4682440|要解决此问题，请将"authorized_key“文件放在不包含加密的目录树中。|4682441|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|S|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|T|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

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

<pre><code>ls -A
</code></pre>

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.

blocks|key|4682491|text|我在solaris上也遇到了同样的错误，但在/var/adm/splunk-auth.log中找到了以下内容：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4682492|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|code-block|syntax|javascript|4682493|在/etc/shadow中，帐户被锁定：|4682494|weblogic:*LK*UP:16447::::::3|4682495|去掉"*LK*“部分：|4682496|weblogic:UP:16447::::::3|4682497|我可以像往常一样在authorized_keys中使用ssh。|4682498|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|U|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|W|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|X|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|Y|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

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

<pre><code>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
</code></pre>

In /etc/shadow the account was locked:

<pre><code>weblogic:*LK*UP:16447::::::3
</code></pre>

Removed the "*LK*" part:

<pre><code>weblogic:UP:16447::::::3
</code></pre>

and I could use ssh with authorized_keys as usual.

blocks|key|176381|text|我找到的简单解决方案是将authorized_keys文件从隐藏的.ssh目录中移出，并将其放入system+ssh目录中：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|176382|/etc/ssh/keys/authorized_keys|code-block|syntax|javascript|176383|一旦我这样做了，它就没有问题了。|176384|entityMap^0|C|F|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@$9|P|A|Q|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|R|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|S|8|@]|D|@]|E|$]]|$1|M|3|-4|5|6|7|T|8|@]|D|@]|E|$]]]|N|$]]

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

<pre><code>/etc/ssh/keys/authorized_keys
</code></pre>

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

blocks|key|176413|text|在我的例子中，我还必须将/home/user的权限从0755更改为0700。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|176414|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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

blocks|key|176459|text|多亏了nrathaus和/var/log/auth.log对调试级别的调查，结果如下。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|176460|另一个原因是您的主目录可能具有不同于755的权限。|176461|entityMap^0|C|H|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|N|8|@]|D|@]|E|$]]]|I|$]]

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

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

blocks|key|4682644|text|在我的例子中，它是由(/etc/ssh/sshd_config)引起的：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|4682645|PermitRootLogin+no|code-block|syntax|javascript|4682646|更改为yes，重启服务并正常进入。|4682647|entityMap^0|B|K|0|0|3|3|0^^$0|@$1|2|3|4|5|6|7|O|8|@$9|P|A|Q|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|R|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|S|8|@$9|T|A|U|B|C]]|D|@]|E|$]]|$1|M|3|-4|5|6|7|V|8|@]|D|@]|E|$]]]|N|$]]

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

<pre><code>PermitRootLogin no
</code></pre>

Changed to <code>yes</code>, restarted the service and got in normally.

blocks|key|4682667|text|在我的例子中，nfs上的home是777，需要750。这解决了这个问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4682668|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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

blocks|key|176635|text|在windows+server+2008+r2中也有同样的问题，并探索了很多需要解决的问题，最后通过以下方式解决：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|176636|使用textpad或任何其他文本编辑器打开C:\Program+Files+(x86)\OpenSSH\etc\sshd_config|176637|从下面的行中删除注释，删除后它们应该如下所示：|176638|RSAAuthentication+yes
PubkeyAuthentication+yes
AuthorizedKeysFile++.ssh/authorized_keys|code-block|syntax|javascript|176639|现在保存并尝试使用私钥登录。玩得开心。|176640|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Q|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|R|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

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:

<pre><code>RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
</code></pre>

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

blocks|key|176689|text|我有这个问题，sshd只从authorized_keys2读取。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|176690|复制或重命名文件为我解决了这个问题。|176691|cd++~/.ssh
sudo+cat+authorized_keys+>>+authorized_keys2|code-block|syntax|javascript|176692|附注:我正在使用Windows的Putty，并使用PuTTyKeygen生成密钥对。|176693|entityMap^0|D|G|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@$9|R|A|S|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|T|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|U|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|V|8|@]|D|@]|E|$]]|$1|O|3|-4|5|6|7|W|8|@]|D|@]|E|$]]]|P|$]]

I have this issue where sshd only reads from <code>authorized_keys2</code>.

Copying or renaming the file fixed the problem for me.

<pre><code>cd ~/.ssh
sudo cat authorized_keys &gt;&gt; authorized_keys2
</code></pre>

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

blocks|key|4682829|text|当我试图通过Mobaxterm登录时，我也遇到了类似的问题。私钥是通过puttygen生成的。重新生成密钥对我的情况很有帮助。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4682830|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|4682875|text|使用Cpanel时，您可以检查密钥是否在中授权|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4682876|SSH+Access+>>+Public+keys+>>+Manage+>>授权或取消授权。|4682877|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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

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

blocks|key|4682940|text|我今天遇到了这个问题，我的问题是，当从文件中复制公钥时，也会包含换行符。您可以使用vim中的":set+list“来查看所有隐藏的新行，并确保删除除最后一行之外的所有新行。此外，我的密钥在开始时缺少"ssh-rsa“。确保你也有这样的东西。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4682941|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|4682994|text|在我的例子中，问题是这样的，在生成ssh密钥的过程中，我故意更改了密钥的默认目录。因此，我没有使用~/.ssh/authorized_keys位置，而是选择使用~/home/user/folder1/.ssh/authorized_keys，为了让这些更改生效，我应该对这个文件/etc/ssh/sshd_config上的新位置进行相同的更改。但在我意识到这一点之前，我已经尝试了其他人提出的几种解决方案，包括将主文件夹的权限设置为700，将.ssh目录设置为600。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|4682995|entityMap^0|28|14|3V|K|60|3|6E|3|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]|$9|M|A|N|B|C]|$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|G|$]]

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 <code>~/home/user/folder1/.ssh/authorized_keys</code>, for these changes to work I was supposed to make the same changes of about the new location on this file <code>/etc/ssh/sshd_config</code>. 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 <code>700</code> and the .ssh directory to <code>600</code>.

blocks|key|4683022|text|检查您的密钥，这应该是rsa+(id_rsa.pub)密钥，而不再是dss+(id_dsa.pub)密钥，请使用puttygen+0.70并选择要生成的密钥类型的RSA，替换主机上的公钥~/..ssh/授权密钥|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4683023|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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

blocks|key|177003|text|添加密钥后，如果您使用的是Amazon+Linux计算机，请以ec2-user身份登录|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|177004|entityMap^0|V|8|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

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

blocks|key|177052|text|哦，天哪，我花了好几天的时间来解决这个问题。这就是对我有效的方法。我返回到根文件夹，如下所示:+cd+/+.ssh+/+mkdir+cd+.ssh+chmod700+.ssh+nano+-w+authorized_keys服务ssh重新启动，所以我使用根目录通过Putty记录日志，它起作用了。因此，尝试对要在putty中使用的用户执行相同的操作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|177053|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|4683139|text|在我的例子中，是一个错误的用户:组属性。我解决了设置正确的用户和组的问题：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4683140|sudo+chown+[user]:[group]+-R+/home/[user]|code-block|syntax|javascript|4683141|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

In the case of mine it was a wrong user:group attribution. I solved setting the right user and group:
<pre><code>sudo chown [user]:[group] -R /home/[user]
</code></pre>

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

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

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

<code>.ssh</code> 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 <code>'server refused our key'</code> and server asks for password. That's all. Nothing is logged to <code>/var/log/auth.log</code> 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.

Putty: Getting Server refused our key Error

Windows Server

身份验证

日志文件

服务器

Windows

Linux

我使用puttygen.exe创建了密钥对(客户端是Windows8)。在服务器(Ubuntu12.04.3LTS)上，我已经将我的公钥放在了~/.ssh/authorized_keys中。公钥如下：ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAopfM6RHOgnuc4Aftn3t4k5UI...

问Putty:获取服务器拒绝了我们的密钥错误
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Putty:获取服务器拒绝了我们的密钥错误EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Putty:获取服务器拒绝了我们的密钥错误
EN