Make PrivateKeyFile an implementation of IPrivateKeySource to make room for other key sources #577
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 6 commits
August 11, 2019 19:54
|
Since the library is portable via .Net Standard and Core and used in mobile platforms and other platforms like Mac OS and Linux would this provide problems in those?
…Sent from my iPhone
On Aug 11, 2019, at 7:55 AM, Sad Lame Developer ***@***.***> wrote:
Hello,
I am planning to add support for TPM/SmartCard-based private key authentication to SSH.NET (please see #576).
TPM/SmartCard-based private key authentication is a new authentication method in which the private key is stored in a special hardware (outside of the filesystem), reinforcing client-side security by preventing anyone (even intruders w/o certain privileges) from stealing the private key.
This PR does not involve the functionality itself, but it includes the only breaking change to the API, which is why I opened this PR.
Specifically, I want to create a new interface IPrivateKeySource which is implemented by PrivateKeyFile so that in the future, PrivateKeyCng (which represents a private key stored somewhere else) could be handled transparently.
The rest of the changes required to implement TPM/SmartCard authentication is not going to impact the public API at all, just adding new classes and new files.
If this change is deemed unacceptable, I will try to come up with another way to pass the new kind of private keys to the API.
Thank you in advance.
You can view, comment on, or merge this pull request online at:
#577
Commit Summary
PrivateKeyFile is an implementation of IPrivateKeySource
Added missing IPrivateKeySource.cs to Rensi.SshNet.csproj
Fixed typo in PrivateKeyConnectionInfo.cs
Replaced reference to PrivateKeyAuthenticationMethod.KeyFiles wth KeySources
Changed keyFiles to keySources
Removed unnecessary usings from IPrivateKeySource.cs
File Changes
M src/Renci.SshNet.NET35/Renci.SshNet.NET35.csproj (5)
M src/Renci.SshNet.Silverlight/Renci.SshNet.Silverlight.csproj (3)
M src/Renci.SshNet.Silverlight5/Renci.SshNet.Silverlight5.csproj (3)
M src/Renci.SshNet.Tests/Classes/ScpClientTest.cs (16)
M src/Renci.SshNet.UAP10/Renci.SshNet.UAP10.csproj (3)
M src/Renci.SshNet.WindowsPhone/Renci.SshNet.WindowsPhone.csproj (3)
M src/Renci.SshNet.WindowsPhone8/Renci.SshNet.WindowsPhone8.csproj (3)
A src/Renci.SshNet/IPrivateKeySource.cs (15)
M src/Renci.SshNet/NetConfClient.cs (16)
M src/Renci.SshNet/PrivateKeyAuthenticationMethod.cs (32)
M src/Renci.SshNet/PrivateKeyConnectionInfo.cs (54)
M src/Renci.SshNet/PrivateKeyFile.cs (2)
M src/Renci.SshNet/Renci.SshNet.csproj (1)
M src/Renci.SshNet/ScpClient.cs (16)
M src/Renci.SshNet/SftpClient.cs (16)
M src/Renci.SshNet/SshClient.cs (16)
Patch Links:
https://github.com/sshnet/SSH.NET/pull/577.patch
https://github.com/sshnet/SSH.NET/pull/577.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@darkoperator I'm sorry I forgot to clarify that. This feature is going to be exclusively available to .NET 3.5 due to the use of P/Invoke. I must think of a way to perform tests without problems, but apart from the changes in this PR, users on the other platforms will not notice any changes in the API. |
ghost
mentioned this pull request
|
If anyone is interested, I posted a link to a repo in #576 which contains a demo in which a private key from TPM/Smartcard is used to log in to a remote host. |
|
Please provide a small text fragment that describes this change, so that we can include it in the release notes. Thx! |
|
@drieseng I'm new and I am not sure if I'm doing this right, does this suffice? Thank you.
|
|
What about alternatively just replace all usages of PrivateKeyFile with HostAlgorithm? The only accessible field in PrivateKeyFile is the HostAlgorithm anyways, and HostAlgorithm is already extensible. |
Merged
|
@sadlame #794 has been merged, can you please check if this PR can be closed. |
|
@sadlame PR needs refreshing. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello,
I am planning to add support for TPM/SmartCard-based private key authentication to SSH.NET (please see #576).
TPM/SmartCard-based private key authentication is a new authentication method in which the private key is stored in a special hardware (outside of the filesystem), reinforcing client-side security by preventing anyone (even intruders w/o certain privileges) from stealing the private key.
This PR does not involve the functionality itself, but it includes the only breaking change to the API, which is why I opened this PR.
Specifically, I want to create a new interface IPrivateKeySource which is implemented by PrivateKeyFile so that in the future, PrivateKeyCng (which represents a private key stored somewhere else) could be handled transparently.
The rest of the changes required to implement TPM/SmartCard authentication is not going to impact the public API at all, just adding new classes and new files.
If this change is deemed unacceptable, I will try to come up with another way to pass the new kind of private keys to the API.
Thank you in advance.