Python Paramiko AuthenticationException 问题
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/4135261/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Paramiko AuthenticationException issue
提问by waffleman
I am having a problem connecting to a device with a Paramiko (version 1.7.6-2) ssh client:
我在使用 Paramiko（版本 1.7.6-2）ssh 客户端连接到设备时遇到问题：
$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import paramiko
>>> ssh = paramiko.SSHClient()
>>> ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
>>> ssh.connect("123.0.0.1", username="root", password=None)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/pymodules/python2.6/paramiko/client.py", line 327, in connect
self._auth(username, password, pkey, key_filenames, allow_agent, look_for_keys)
File "/usr/lib/pymodules/python2.6/paramiko/client.py", line 481, in _auth
raise saved_exception
paramiko.AuthenticationException: Authentication failed.
>>>
When I use ssh from the command line, it works fine:
当我从命令行使用 ssh 时，它工作正常：
ssh [email protected]
BusyBox v1.12.1 (2010-11-03 13:18:46 EDT) built-in shell (ash)
Enter 'help' for a list of built-in commands.
#
Anyone seen this before?
有人见过这个吗？
Edit 1
编辑 1
Here is the verbose output of the ssh command:
这是 ssh 命令的详细输出：
:~$ ssh -v [email protected]
OpenSSH_5.3p1 Debian-3ubuntu4, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 123.0.0.1 [123.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/waffleman/.ssh/identity type -1
debug1: identity file /home/waffleman/.ssh/id_rsa type -1
debug1: identity file /home/waffleman/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1
debug1: match: OpenSSH_5.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '123.0.0.1' is known and matches the RSA host key.
debug1: Found key in /home/waffleman/.ssh/known_hosts:3
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentication succeeded (none).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.utf8
Edit 2Here is the python output with debug output:
编辑 2这是带有调试输出的 python 输出：
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import paramiko, os
>>> paramiko.common.logging.basicConfig(level=paramiko.common.DEBUG)
>>> ssh = paramiko.SSHClient()
>>> ssh.load_system_host_keys()
>>> ssh.load_host_keys(os.path.expanduser('~/.ssh/known_hosts'))
>>> ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
>>> ssh.connect("123.0.0.1", username='root', password=None)
DEBUG:paramiko.transport:starting thread (client mode): 0x928756cL
INFO:paramiko.transport:Connected (version 2.0, client OpenSSH_5.1)
DEBUG:paramiko.transport:kex algos:['diffie-hellman-group-exchange-sha256', 'diffie-hellman-group-exchange-sha1', 'diffie-hellman-group14-sha1', 'diffie-hellman-group1-sha1'] server key:['ssh-rsa', 'ssh-dss'] client encrypt:['aes128-cbc', '3des-cbc', 'blowfish-cbc', 'cast128-cbc', 'arcfour128', 'arcfour256', 'arcfour', 'aes192-cbc', 'aes256-cbc', '[email protected]', 'aes128-ctr', 'aes192-ctr', 'aes256-ctr'] server encrypt:['aes128-cbc', '3des-cbc', 'blowfish-cbc', 'cast128-cbc', 'arcfour128', 'arcfour256', 'arcfour', 'aes192-cbc', 'aes256-cbc', '[email protected]', 'aes128-ctr', 'aes192-ctr', 'aes256-ctr'] client mac:['hmac-md5', 'hmac-sha1', '[email protected]', 'hmac-ripemd160', '[email protected]', 'hmac-sha1-96', 'hmac-md5-96'] server mac:['hmac-md5', 'hmac-sha1', '[email protected]', 'hmac-ripemd160', '[email protected]', 'hmac-sha1-96', 'hmac-md5-96'] client compress:['none', '[email protected]'] server compress:['none', '[email protected]'] client lang:[''] server lang:[''] kex follows?False
DEBUG:paramiko.transport:Ciphers agreed: local=aes128-ctr, remote=aes128-ctr
DEBUG:paramiko.transport:using kex diffie-hellman-group1-sha1; server key type ssh-rsa; cipher: local aes128-ctr, remote aes128-ctr; mac: local hmac-sha1, remote hmac-sha1; compression: local none, remote none
DEBUG:paramiko.transport:Switch to new keys ...
DEBUG:paramiko.transport:Trying discovered key b945197b1de1207d9aa0663f01888c3c in /home/waffleman/.ssh/id_rsa
DEBUG:paramiko.transport:userauth is OK
INFO:paramiko.transport:Authentication (publickey) failed.
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/pymodules/python2.6/paramiko/client.py", line 327, in connect
self._auth(username, password, pkey, key_filenames, allow_agent, look_for_keys)
File "/usr/lib/pymodules/python2.6/paramiko/client.py", line 481, in _auth
raise saved_exception
paramiko.AuthenticationException: Authentication failed.
>>>
采纳答案by JimB
The ssh server on the remote device denied your authentication. Make sure you're using the correct key, the public key is present in authorized_keys, .sshdirectory permissions are correct, authorized_keyspermissions are correct, and the device doesn't have any other access restrictions. It hard to say what's going on without logs from the server.
远程设备上的 ssh 服务器拒绝了您的身份验证。确保您使用正确的密钥，公钥存在于 中authorized_keys，.ssh目录权限正确，authorized_keys权限正确，并且设备没有任何其他访问限制。如果没有来自服务器的日志，很难说发生了什么。
[EDIT] I just looked back through your output, you are authenticating using Noneauthentication. This usually isn't ever permitted, and is used to determine what auth methods are allowed by the server. It's possible your server is using host based authentication (or none at all!).
[编辑] 我刚刚回顾了您的输出，您正在使用None身份验证进行身份验证。这通常是不允许的，用于确定服务器允许哪些身份验证方法。您的服务器可能正在使用基于主机的身份验证（或根本没有！）。
Since auth_none()is rarely used, it's not accessible from the SSHClientclass, so you will need to use Transportdirectly.
由于auth_none()很少使用，因此无法从SSHClient类中访问它，因此您需要Transport直接使用。
transport.auth_none('root')
回答by SilentGhost
paramiko's SSHClienthas load_system_host_keysmethod which you could use to load user specific set of keys. As example in the docs explain, it needs to be run before connecting to a server.
paramiko 的 SSHClient有一个load_system_host_keys方法，你可以用它来加载用户特定的密钥集。作为文档中的示例解释，它需要在连接到服务器之前运行。
回答by anibal
I get similar error, when the server uses AD authentication. I think this is a bug of paramiko. I have learned that I have to set ssh keys before use paramiko.
当服务器使用 AD 身份验证时，我收到类似的错误。我认为这是paramiko的一个错误。我了解到我必须在使用 paramiko 之前设置 ssh 密钥。
回答by David Johnson
Make sure that the permissions on the public and private key files (and possibly the containing folder) are set to very restrictive (i.e. chmod 600 id_rsa). It turns out this is required (by the Operating System?) to use the files as ssh keys. Found this out from my helpful colleague :) Also make sure that you are using the correct username for the given ssh key.
确保对公钥和私钥文件（以及可能包含的文件夹）的权限设置为非常严格（即 chmod 600 id_rsa）。事实证明，这是（操作系统？）将文件用作 ssh 密钥所必需的。从我乐于助人的同事那里发现了这一点 :) 还要确保您为给定的 ssh 密钥使用了正确的用户名。
回答by edsion zhang
I have tried remove the folder ~./ssh,then it's working well
我已经尝试删除文件夹 ~./ssh，然后它运行良好
回答by user5417363
As a very late follow-up on this matter, I believe I was running into the same issue as waffleman, in a context of a confined network.
作为对此事的非常晚的跟进，我相信在受限网络的背景下，我遇到了与 waffleman 相同的问题。
The hint about using auth_noneon the Transportobject turned out quite helpful, but I found myself a little puzzled as to how to implement that. Thing is, as of today at least, I can't get the Transportobject of an SSHClientobject until it has connected; but it won't connect in the first place...
auth_none关于在Transport对象上使用的提示非常有用，但我发现自己对如何实现这一点感到有些困惑。事情是，至少到今天为止Transport，在SSHClient对象连接之前我无法获取对象的对象；但它首先不会连接......
So In case this is useful to others, my work around is below. I just override the _authmethod.
因此，如果这对其他人有用，我的解决方法如下。我只是覆盖了该_auth方法。
OK, this is fragile, as _authis a private thing. My other alternatives were - actually still are - to manually create the Transportand Channelobjects, but for the time being I feel like I'm much better off with all this still under the hood.
好吧，这很脆弱，因为这_auth是一件私人的事情。我的其他选择是 - 实际上仍然是 - 手动创建Transport和Channel对象，但就目前而言，我觉得这一切仍然在幕后我感觉好多了。
from paramiko import SSHClient, BadAuthenticationType
class SSHClient_try_noauth(SSHClient):
def _auth(self, username, *args):
try:
self._transport.auth_none(username)
except BadAuthenticationType:
super()._auth(username, *args)
回答by Tagar
There could be different reasons on serverside (sshd where you're connecting to), so it might be hard to debug on client side.
服务器端（您连接到的 sshd）可能有不同的原因，因此可能很难在客户端进行调试。
For example, tail -f /var/log/secure:
例如tail -f /var/log/secure：
Oct 9 15:50:26 pc1udatahgw04 sshd[27501]: Authentication refused: bad ownership or modes for directory /home/testuser
10 月 9 日 15:50:26 pc1udatahgw04 sshd[27501]：身份验证被拒绝：目录 /home/testuser 的所有权或模式不正确
If you run ls -lad /home/testuserto see permissions, you'll see for example in our case:
如果您运行ls -lad /home/testuser以查看权限，您将在我们的示例中看到：
$ ls -lad /home/testuser
drwxrwxr-x 16 testuser testgroup 57344 Oct 9 15:23 /home/testuser
Notice second wbit. Home directory was opened up for group writes. sshdrefuses key based authentication in this case.
注意第二w位。主目录已打开用于组写入。sshd在这种情况下拒绝基于密钥的身份验证。
Again, check sshd log on serverside. There could be other issues like already mentioned
再次检查服务器端的sshd 日志。可能还有已经提到的其他问题
- /home/user/.ssh directory is too open
- /home/user/.ssh/id_rsa file is too open
- /home/user/.ssh/id_rsa.pub file is too open
- /home/user/.ssh/id_ecdsa file is too open
- /home/user/.ssh/id_ecdsa.pub file is too open
- /home/user/.ssh 目录太开放
- /home/user/.ssh/id_rsa 文件太开放
- /home/user/.ssh/id_rsa.pub 文件太开放
- /home/user/.ssh/id_ecdsa 文件太开放
- /home/user/.ssh/id_ecdsa.pub 文件太开放
etc..
等等..
