Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Select pref key #900

Closed
wants to merge 4 commits into from
Closed

Select pref key #900

wants to merge 4 commits into from

Conversation

kasdoe
Copy link

@kasdoe kasdoe commented Feb 20, 2017

Using Paramiko I've come across an impracticality.

Resent OpenSSH clients have a preference towards ECDSA keys, and therefore, such keys tend to end up in the known_hosts files. Paramiko on the other hand, tend to end up using RSA key types after initial negotiation., and as a result Paramiko is likely to fail host key verification even though a valid host key has previously been added to the known_hosts file by OpenSSH.

I've added functionality to the SSHClient.connect method to indicate preference towards a given type of key. Loading the know host keys prior to the call to connect enables you to identify a key type which is already in the known_hosts (if any) and instruct Paramiko to use this key type:

host = 'myserver.com'
ssh = paramiko.SSHClient()
ssh.load_host_keys(os.path.expanduser('~/.ssh/known_hosts'))

keys_of_all_known_hosts = ssh.get_host_keys()
pref_hkey_type = None
if host in keys_of_all_known_hosts:
pref_hkey_type = keys_of_all_known_hosts[host].keys()[0]

ssh.connect(host, username='eddie', password='murphy', pref_key_type=pref_hkey_type)

During the process of developing this I've come across an issue in relation to setting of key_types through the SecurityOptions object. Getting the key_types from the SecurityOptions and setting the same values again directly afterwards would raise an exception. I have proposed a fix for this issue too.

I hope you'll find this useful, and please don't hesitate to contact me for further comments.

BR / Kasper Døring

Setting the same key_types as one would be able to
get directly from key_types used to raise an exception
because _key_info didn't hold the same keys as
_preferred_keys

Added unit test also.
…he ecdsa keys

Resent versions of OpenSSH prefers to use ecdsa
keys for the host key verification, and therefore,
ecdsa keys tend to end up in the known_hosts file.
Paramiko on the other hand tend to end up using
rsa keys. This often causes Paramiko to fail the
host key verification despite the fact that the host
is known to OpenSSH. This simple change reduces the
risk of this happening.
@coveralls
Copy link

Coverage Status

Coverage increased (+0.06%) to 74.247% when pulling d360f75 on kasdoe:select-pref-key into 72be58b on paramiko:master.

4 similar comments
@coveralls
Copy link

Coverage Status

Coverage increased (+0.06%) to 74.247% when pulling d360f75 on kasdoe:select-pref-key into 72be58b on paramiko:master.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.06%) to 74.247% when pulling d360f75 on kasdoe:select-pref-key into 72be58b on paramiko:master.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.06%) to 74.247% when pulling d360f75 on kasdoe:select-pref-key into 72be58b on paramiko:master.

@coveralls
Copy link

coveralls commented Feb 20, 2017

Coverage Status

Coverage increased (+0.06%) to 74.247% when pulling d360f75 on kasdoe:select-pref-key into 72be58b on paramiko:master.

@ploxiln
Copy link
Contributor

ploxiln commented Feb 20, 2017

see also #899

@bitprophet
Copy link
Member

and see also #387 and the rest of the keys label. Thanks for this, will take a closer look when I have time to try smashing through all this keys related stuff!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants