Quantcast
Channel: sshnet Issue Tracker Rss Feed
Viewing all articles
Browse latest Browse all 1026

Commented Unassigned: Stack Overflow if PartialSuccess is during Authentication [2399]

$
0
0
TryAuthenticate gets stuck in an infinite recursive loop if the authentication passes partially but requires a 2nd part. This happens whether a single or multiple authentication methods are provided as part of the ConnectionInfo constructor.

TryAuthenticate calls itself to pass the next authentication method to the server, but the list of authentication methods it passes in doesn't exclude the authentication methods already completed. As such, the same authentication method is tried over and over again without ever moving to the next authentication method.

Taking a specific example, suppose that password and privateKey methods are used. Password passes the initial Authenticate call and the result is PartialSuccess. TryAuthenticate is called, and the new list of authenticated methods is still { password, privateKey }. Password is verified again with a result of PartialSuccess. This continues until stack overflow.

Duped with ServU SFTP Server and SSH.NET Changeset 35920

__Recommended solution__: Filter the passed authentication methods down exclude those which have already passed. This needs to be done by authentication method type to ensure that, for example, for a given password authentication returning partial success that we do not attempt any other password authentications but we do attempt all non-failed private keys.

If we want to be able to try different username/auth method combinations then we'd also have to track the difference between failedAuthenticationMethods at the top level and failedAuthenticationMethods found during a PartialSuccess state since I believe it may be possible to fail authentication during PartialSuccess state but succeed from the root level. Not sure how SFTP or SSH.NET responds to switching user names after a PartialSuccess though. Maybe multiple usernames with a single ConnectionInfo is just a weird case that we don't need/want to support.

I've attached a suggested change for the basic fix based on ConnectionInfo.cs Changeset 35920
Comments: ** Comment from web user: CharlesFelish **

What you described is what I observed. I agree that 3 returning just "privatekey" would be more intuitive. That does appear to be in line with the RFC for SFTP ([https://filezilla-project.org/specs/rfc4252.txt](https://filezilla-project.org/specs/rfc4252.txt) page 5), but some might interpret the server filtered list as optional:[0A][0A]> It is RECOMMENDED that servers only include those 'method name' values in the name-list that are actually useful. However, it is not illegal to include 'method name' values that cannot be used to authenticate the user.[0A]>[0A]> Already successfully completed authentications SHOULD NOT be included in the name-list, unless they should be performed again for some reason.[0A][0A]I'm not sure whether this is an SFTP Server implementation specific issue, but we've observed it with more than just ServU. Unfortunately I don't have the name of the other SFTP Server.


Viewing all articles
Browse latest Browse all 1026

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>