Tapestry incorrectly handles SFTP negotiation if the user's known_hosts file contains multiple entries for the same hostname.

[ZAdamMac]

Describe the bug
In a situation where ~/.ssh/known_hosts contains multiple keys for the same hostname (for example, if a given host the user has access to has sshd running on multiple ports via containerization), Tapestry will raise the SSHException indicating a mismatched hostkey was found, and SFTP transfer will fail. Files are, in this condition, retained locally as expected, and an alert is raised to the user that this has occurred.

To Reproduce
Reproduction is preconditioned on having the setup described above. This could be reproduced as simply as creating a dummy SFTP host listening on 2222/tcp on another host which already has SSH of its own on 22/tcp as normal

Steps to reproduce the behavior:

1. Run tapestry in network mode, with the network configuration pointing to the "secondary" port.
2. Error should raise after SFTP negotiation.

Expected behavior
This should work; checking known_hosts should take all host-keys for a given user into consideration.

Log/Console Output
Where possible, add the output of the Logs or Console when the problem occurs.

Desktop (please complete the following information):

• OS: Ubuntu 20.04
• Python Interpreter: 3.8
• Version: 2.1.1 (Current Release)

Additional context
This is probably a very unusual arrangement so I wouldn't be surprised if I am the only person to encounter this.

[ZAdamMac]

After doing some digging around in the codebase for pysftp and for its dependency, paramiko, I'm reasonably certain the issue is actually rooted in this method, originated in pysftp:

Because of this I suspect the solution will be to obviated pysftp (which appears to be abandonware) and implement the connection and other SFTP operations directly in Paramiko. This is gated work that cannot take place until workstation replacement, current ETA early Feburary 2021.

[ZAdamMac]

Adding the enhancement flag. The bug itself is a bug, but fixing it will require ripping a dependency out of the program and replacing that functionality with several new local classes and functions. Shouldn't be insurmountable, but will be more work than the usual bugfixes.

This will almost certainly go out with 2.2.0 unless someone has a pressing need for this use case besides me.

[ZAdamMac]

Removing the bug label and keeping as an enhancement for some nebulous 2.2 release; the functionality covered here is no longer desired.