Invalid(Tempered) PrivateKey also authenticates user

[JavaGuru-04]

trafficstars

SSHCLIENT.connect(host,port); SSHCLIENT.authPublickey(user, keyLocationArr);

It is okay if I give correct key but should not be working if key is invalid/tempered. Still it is working and Connected & Authenticated returning TRUE always.

1. Using Correct key and fetching remote file info
2. In next run, changing valid key with invalid/tempered one and still fetching remote file info

Is it BUG in library or any solution you can provide.

[hierynomus]

If you've really changed the key, it should no longer work. However there are multiple reasons why your scenario would work:

1. There is another key present in the locations that does allow access, you should be able to see from the log which key was used to authenticate.
2. The part of the key which you've changed is a comment field, or some other non-used part of the key file.

[JavaGuru-04]

Thanks for response but neither are the cases with me.Using putty/openssh generated public/private keys which come with the comments and works without any issue. Secondly providing/passing custom key location so no other key exist.Issue with key which is not part of SFTP server but still connected due to last run with valid SFTP key.Note:  Closing sshclient once done with operations so no chance of having last running session.Any clue or idea you can provide to fix this issue.Could you please try with such scenario?Add key into SFTP server then run : should workRemove first key and add another key then run with first key : should not work but it is working On Feb 24, 2022 2:36 PM, Jeroen van Erp @.***> wrote: If you've really changed the key, it should no longer work. However there are multiple reasons why your scenario would work: There is another key present in the locations that does allow access, you should be able to see from the log which key was used to authenticate.The part of the key which you've changed is a comment field, or some other non-used part of the key file.

—Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.Message ID: @.***>

[hierynomus]

Can you provide detailed trace level logging of both connection/authentication attempts, plus a reproducing piece of code?