 |
|
|
 |
 |
Joined: 12/28/2011
Posts: 355
|
|
|
Stefan,
Just a thought about private keys...
Currently we have:
-
Connections stored in a shared document for multiple users or a personnal local document...
-
Credentials stored independently of connections, allowing their reusability for multiple connections...
-
Credentials stored in any document so "common credentials" for a team are in the shared document and "personnal credentials" in a non-shared document...
For private keys, we must have the same behaviour: some can be "common" (a key for a team) and "personnal" (for a named user)
I think you will have to change (or extend) the actual credentials system to make it typed (like variables) 
I don't really know what's better and/or doable:
-
Create new credentials' types specifically for each protocol and add options depending on authentication capabilities
-
Extend the actual system to choose its type (Login/Pass, Login/Key, Cert) and keep it "universal"
Authentication modes availables by services types:
|
|
Login & Password |
Login & Private Key (+ optional Passphrase) |
X509 Certificate |
|
RDP |
 |
 |
|
|
Web page |
|
|
|
|
SSH |
|
|
|
Of course, if you plan to implement other protocols (e.g. VNC) this table will be updated accordingly!
If you need more infos, tell me 
|
|
|
|
 | |
|
|
 |
 |
Joined: 8/11/2008
Posts: 2299
|
|
|
Thank you for the input.
In general this seems to be a good idea but in order to make a decision, I still have some open questions:
Right now, an SSH connection object can have a credential assigned (with username and password) and additionally you can also provide a private key file and a passphrase (!= password from the credential) right? In your table you write login + private key + passphrase. Does that mean you do not need a password if you have the private key and the passphrase?
I'm also not sure how to work with X509 certificates and if there's anything I can do to make that work?
I agree, for the private key and passphrase configuration it would make sense to make separate object types (similar to credentials) and provide a way to assign that the same way you would assign credentials. Wouldn't that be enough. This way you could assign credentials and/or a private key.
cheers,
Stefan
|
|
|
|
| |
|
|
|
|
Joined: 12/28/2011
Posts: 355
|
|
|
StefanKoell wrote:
Right now, an SSH connection object can have a credential assigned (with username and password) and additionally you can also provide a private key file and a passphrase (!= password from the credential) right? In your table you write login + private key + passphrase. Does that mean you do not need a password if you have the private key and the passphrase?
In fact, when you connect to a SSH server, you can provide a login and the corresponding password or a login and a private key with a passphrase...
When you use a private key, you don't need to use a password as the authentication is splitted in 2 parts: the public key (stored in the user's home directory into the autorized_keys' file) and the private key on the client-side that is already passphrase protected...
User accounts can be "password-less" as it can ben randomly generated by the admin or login with password can be disabled. In this case the user only have a kay pair ... (I know it can be very complicated  )
You also can assign both but if it fails with private key (not found because on a removable drive for security, lost passphrase, ...) it would be a big security hole to have the password saved and used to authenticate
I'm also not sure how to work with X509 certificates and if there's anything I can do to make that work?
Don't worry, X509 Certificates are not widely used for RDP authentication nor SSH authentication, it just good to know it can be asked to implement sooner or later
At my work, my team manage approximately 150/200 Windows Servers and 100/200 Unix/Linux servers but the company count nearly 800 Windows Server and 500 Unix/Linux servers ... X509 certificates based authentication is not enabled even if we have a Certificate Authority configured in our national Active Directory infrastructure !
I agree, for the private key and passphrase configuration it would make sense to make separate object types (similar to credentials) and provide a way to assign that the same way you would assign credentials. Wouldn't that be enough. This way you could assign credentials and/or a private key.
Yes that would be enough that way! The user can choose between a "standard" credential (login/password) or a "key" credential (login/private key/passphrase) to assign to its connection.
I hope I could clear things up
Good night !
|
|
|
|
| |
|
|
|
|
Joined: 12/28/2011
Posts: 355
|
|
|
You can keep the password as a fall back solution for private keys.
User always provide a login for the private key, so if authentication fail with the key, you can prompt for the password and send the login and password provided to the server
|
|
|
|
| |
|
|
 |
|
Joined: 1/17/2012
Posts: 79
|
|
|
It would be nice if a SSH key agent (eg. PuTTY's pageant) could also be used - this way, I can keep my private keys encrypted, while needing to only enter the passphrase once (and without having to keep that passphrase stored anywhere).
|
|
|
|
| |
|
|
|
|
Joined: 12/28/2011
Posts: 355
|
|
|
Hi Ender,
An agent (additionnal software) isn't really necessary for this...
PuTTY agent is used to store all private keys we want to use with PuTTY and it manage the passphrase once for each key as needed to prevent PuTTY to ask for it on each connection.
RoyalTS already offer something like this for its encrypted documents: it ask for the password on load and by default keep it as long as RoyalTS run.
If Stefan implement a new object type for the private keys (like for credentials), he probably can use the same mechanism to ask the key's passphrase on the first use and store it temporally until RoyalTS exits.
If the user has no passphrase for his key, it can be set in the options of the object (e.g.: a 'key without passphrase' checkbox), and to keep the same philosphy as for RPD connections, if the user want to store the passphrase in the document (if encrypted of course or else it's not secure at all!) an option can be added as well (let say 'key with a passphrase' + a textbox to enter it).
Wait and see what's new in the next build
|
|
|
|
| |
|
|
|
|
Joined: 8/11/2008
Posts: 2299
|
|
|
Good discussion, guys! I think we're making progress.
Sorry for the late reply but I was busy releasing 2.0.3 and my machine broke which resulted in a complete reinstall 
After further discussion with other SSH users, your input and investigation of different possible implementations, we came up with one solution which isn't too expensive (in terms of effort) and might (hopefully) fulfill all requirements.
Before I get my hands dirty, I wanted to post the proposed solution here in order to get your feedback and view on this.
Credential Object Enhancements
The credential object in Royal TS is right now a very generic object allowing you to configure a username/password pair. Those objects can be assigned to RDP, Web, SSH and future connection types. The easiest way to get the expected behavior into Royal TS and at the same time keep the credential object generic is to extend the existing object with a couple of additonal properties/options.
|
Current Credemtial Properties |
|
Username |
string used for username/login |
|
Password |
encrypted string for the password information |
|
Notes/Custom Fields |
strings for notes and custom fields |
Additional Properties in Royal TS 2.1 (in a seperate configuration page)
The configuration is optional! |
|
PrivateKeyFile |
string containing the path to the private key file |
|
Passphrase |
encrypted string containing the passphrase for the private key |
Connection types which aren't interested in the private key or passphrase properties (such as rdp or web connections) will just ignore those settings if set.
Connection types which can handle the new properties will use them accordingly:
|
Current SSH Properties |
|
Server, Port, Proxy |
all the ssh settings and configuration properties |
|
Credentials |
assigned using the credential object or specified with username/password (exactly the same as now) |
|
PrivateKeyFile |
string containing the path to the private key file |
|
Passphrase |
encrypted string containing the passphrase for the private key |
As you can see, I would leave the two properties private key file and passphrase also in the SSH connection as an optional configuration setting. This way you could either use the connection based setting or define it on a global scope within the credential. The SSH connection setting would be "stronger" as the credential settings and would override the private key file and passphrase passed on from the credential if it is configured on the connection level. This way you could provide a shared credential with all the necessary information but if needed you can configure your connection to use different credential (including different private key) setting by changing the properties in the connection.
Since the private key/passphrase config is stored in a standard credential, folder inheritance would also work that way.
First question: would that make sense?
Second question: what would be the desired behavior matrix?
|
Username |
Password |
PrivateKeyFile |
Passphrase |
Action |
|
- |
- |
- |
- |
Ask for username and password |
|
x |
- |
- |
- |
Ask for password |
|
x |
x |
- |
- |
login using username and password |
|
x |
- |
x |
- |
ask for passphrase |
|
x |
- |
x |
x |
login using username, key and passphrase |
|
x |
x |
x |
x |
login using username, key and passphrase and ignore password |
- = not set
x = set
As mentioned above, private key file and passphrase is used from the credential, if configured. In case the private key file and passphrase is set on the connection level, it will ignore those from the credential and use the connection settings.
On another note: the credential page has a checkbox: Automatic Logon. The above matrix is only valid if Automatic Logon is true. If not true, Royal TS will always ask for username and password.
I also like to implement the (optional) password caching as mentioned before. This seems to be a handy feature ;-)
Anything missing? 
|
|
|
|
| |
|
|
|
|
Joined: 1/17/2012
Posts: 79
|
|
|
gringrin wrote:
RoyalTS already offer something like this for its encrypted documents: it ask for the password on load and by default keep it as long as RoyalTS run.
This assumes that I only use one thing that uses the keys - I actually use several programs (PuTTY, FAR/WinSCP, FileZilla, a bunch of scripts that use PuTTY's command-line tools), which can all use authentication through Pageant. Additionally, I'm using pageant from PuTTY-CAC project and store some keys on my smartcard.
|
|
|
|
| |
|
|
|
|
Joined: 12/28/2011
Posts: 355
|
|
|
Hi Stefan!
Hope you don't loose anything important with this crash Computers always do that when you have a lot to do 
Good discussion, guys! I think we're making progress.
That's what a forum and a community is for
[...]
Credential Object Enhancements
The credential object in Royal TS is right now a very generic object allowing you to configure a username/password pair. Those objects can be assigned to RDP, Web, SSH and future connection types. The easiest way to get the expected behavior into Royal TS and at the same time keep the credential object generic is to extend the existing object with a couple of additonal properties/options.
[...]
That would be the best way, another separate object will be confusing for users...
Connection types which aren't interested in the private key or passphrase properties (such as rdp or web connections) will just ignore those settings if set.
Connection types which can handle the new properties will use them accordingly:
[...]
As you can see, I would leave the two properties private key file and passphrase also in the SSH connection as an optional configuration setting. This way you could either use the connection based setting or define it on a global scope within the credential. The SSH connection setting would be "stronger" as the credential settings and would override the private key file and passphrase passed on from the credential if it is configured on the connection level. This way you could provide a shared credential with all the necessary information but if needed you can configure your connection to use different credential (including different private key) setting by changing the properties in the connection.
Since the private key/passphrase config is stored in a standard credential, folder inheritance would also work that way.
First question: would that make sense?
Humm... Unlike a certificate which namely identify a person (as a login or username) and also act "as a password", a private key can be used with any account but you need to specify for which account you want to use it. So if you keep the private key definition in the connection properties, you have to add a username field.
Currently, in the "Credentials" page of SSH connections, thier is a combo. If you add a choice "Specify username, private key and passphrase" like for "Specify username and password", you can add the username/private key file path/passphrase.
Users can also choose "Use an existing credential" or "Specify credential name" to pick a credential object and if this object had a private key then use it...
Doing this, there is no more setting "stronger" than the other and it's much more like RDP connections
Second question: what would be the desired behavior matrix?
|
x |
x |
x |
x |
login using username, key and passphrase and ignore password |
As mentioned above, private key file and passphrase is used from the credential, if configured. In case the private key file and passphrase is set on the connection level, it will ignore those from the credential and use the connection settings.
On another note: the credential page has a checkbox: Automatic Logon. The above matrix is only valid if Automatic Logon is true. If not true, Royal TS will always ask for username and password.
I also like to implement the (optional) password caching as mentioned before. This seems to be a handy feature ;-)
Anything missing?
Your matrix seems ok.
About the last row, it's ok to ignore the password. If password is also configured and in case the login with the private key/passphrase fail, you can retry with the username/password and if it still fail then stop here ...
I think you're almost done with the theorical part on this
|
|
|
|
| |
|
|
|
|
Joined: 12/28/2011
Posts: 355
|
|
|
ender wrote:
gringrin wrote:
RoyalTS already offer something like this for its encrypted documents: it ask for the password on load and by default keep it as long as RoyalTS run.
This assumes that I only use one thing that uses the keys - I actually use several programs (PuTTY, FAR/WinSCP, FileZilla, a bunch of scripts that use PuTTY's command-line tools), which can all use authentication through Pageant. Additionally, I'm using pageant from PuTTY-CAC project and store some keys on my smartcard.
You're right if you use a bunch of services with the same private key, this would be a missing feature ...
As I don't have used PuTTY/winSCP for a long time now (as I use another solution providing the both) and only use private key for shell login and SCP/SFTP an agent isn't helpful for me
Maybe it'll be another feature added in a future version of Royal TS... But I don't think that Stefan will have time to focus on this for now
|
|
|
|
| |
|
|
|
|
Joined: 8/11/2008
Posts: 2299
|
|
|
gringrin wrote:
Maybe it'll be another feature added in a future version of Royal TS... But I don't think that Stefan will have time to focus on this for now
Babysteps
Once we have the basic feature set, I'm sure we can look into all the other stuff (like SCP/Pageant/etc.) to further enhance Royal TS...
|
|
|
|
| |
|
|
|
|
Joined: 8/11/2008
Posts: 2299
|
|
|
Hope you don't loose anything important with this crash Computers always do that when you have a lot to do
nothing is lost (as far as I can tell) but it's always a lot of work to get up to speed again...
Humm... Unlike a certificate which namely identify a person (as a login or username) and also act "as a password", a private key can be used with any account but you need to specify for which account you want to use it. So if you keep the private key definition in the connection properties, you have to add a username field.
yes, I would have two separate pages: one for the credential and one for the private key/passphrase.
So, if you select a credential which also has it's private key/passphrase set, it would be used unless you define private key/passphrase at the connection level.
Currently, in the "Credentials" page of SSH connections, thier is a combo. If you add a choice "Specify username, private key and passphrase" like for "Specify username and password", you can add the username/private key file path/passphrase.
Users can also choose "Use an existing credential" or "Specify credential name" to pick a credential object and if this object had a private key then use it...
I guess I do not need to add the "Specify username, private key and passphrase" option then. if the used credential has the properties set, it will be used. if the connection has the private key and passphrase set, it would use the one from the connection but it will use the login (username) from the credential - regardless if it's specified on the connection or it comes from an assigned credential.
About the last row, it's ok to ignore the password. If password is also configured and in case the login with the private key/passphrase fail, you can retry with the username/password and if it still fail then stop here ...
sounds reasonable.
Monday I will start right away with the implementation and will update the beta as soon as possible...
|
|
|
|
| |
|
|
|
|
Joined: 12/28/2011
Posts: 355
|
|
|
Monday I will start right away with the implementation and will update the beta as soon as possible...
Ok it's cool!
We'll test this when the new build come out and help you adjust if needed
|
|
|
|
| |
|
|
|
|
Joined: 8/11/2008
Posts: 2299
|
|
|
I really appreciate your time and feedback on this. You guys rock. Expect to get a beer or two when it's done 
|
|
|
|
| |
|
|
|
|
Joined: 8/11/2008
Posts: 2299
|
|
|
I've just uploaded a new build (#10326) which should (hopefully) handle authentication correctly. Let me know if there are still issues. I have to admit, I haven't tested it very well but I wanted to give you access to the latest build as soon as possible.
Btw, the colors can now be configured 
http://www.code4ward.net/main/forums/...
cheers,
Stefan
|
|
|
|
| |
|
|
|
|
Joined: 12/28/2011
Posts: 355
|
|
|
StefanKoell wrote:
I've just uploaded a new build (#10326) which should (hopefully) handle authentication correctly. Let me know if there are still issues. I have to admit, I haven't tested it very well but I wanted to give you access to the latest build as soon as possible.
Btw, the colors can now be configured
http://www.code4ward.net/main/forums/...
cheers,
Stefan
Whaou, already available?!  *You* definetly rock :)
So, I'm sorry, but can't stay here without givin' it a try:
In the properties' pages for private keys, the key's path textbox is masked with dots like passwords and passphrase's textbox is clear text :p (both in credentials and connections properties)
Test with no separate credential (username, password, private key and passphrase provided in the connection's properties):
|
Username |
Password |
PrivateKeyFile |
Passphrase |
Action |
Tested? |
|
- |
- |
- |
- |
Ask for username and password |
|
|
x |
- |
- |
- |
Ask for password |
 Crash RTS |
|
x |
x |
- |
- |
login using username and password |
|
|
x |
- |
x |
- |
ask for passphrase |
Crash RTS if passphrase is protected |
|
x |
- |
x |
x |
login using username, key and passphrase |
|
|
x |
x |
x |
x |
login using username, key and passphrase and ignore password |
Don't know what is used behind but it works |
Test with a separate credential (username, password, private key and passphrase provided in the credential's properties):
|
Username |
Password |
PrivateKeyFile |
Passphrase |
Action |
Tested? |
|
- |
- |
- |
- |
Ask for username and password |
|
|
x |
- |
- |
- |
Ask for password |
|
|
x |
x |
- |
- |
login using username and password |
|
|
x |
- |
x |
- |
ask for passphrase |
Crash RTS if passphrase is protected |
|
x |
- |
x |
x |
login using username, key and passphrase |
|
|
x |
x |
x |
x |
login using username, key and passphrase and ignore password |
Don't know what is used behind but it works |
[EDIT] I only used PuTTY Private Key files, I'll test with OpenSSH key later ... [/EDIT]
[EDIT²] Using OpenSSH private key file crash Royal TS :-( [/EDIT²]
[ -- OFF Topic but linked to the new build :p -- ]
I've see you have added a configuration key "SSHMouseWheelSpeed" in the Royal TS's config file Set the value to 10 and now scrolling is perfect !! Thanks you so much
For the colors, a little bug appear when you choose a color with the color picker: when closing it, the corresponding textbox has 2 sharp sign (#) so an error message is shown on validation asking for valid colors but it works when manually corrected!
[ -- /OFF Topic -- ]
|
|
|
|
| |
|
|
|
|
Joined: 8/11/2008
Posts: 2299
|
|
|
So, I'm sorry, but can't stay here without givin' it a try
great! I really appreciate your time testing those builds!
In the properties' pages for private keys, the key's path textbox is masked with dots like passwords and passphrase's textbox is clear text :p (both in credentials and connections properties)
ok, I've fixed that.
I cannot reproduce the crash when only the username is provided in the connection properties. I get the authentication form and even if I enter the correct or wrong password, it doesn't crash. When I enter the correct password it's connecting, when I enter the wrong password, it's asking me again for authenticaton.
I'm also not able to test using private keys since my SSH test server does not require me to have one and I have no idea how to set that up...
The two crash reports you've send me made sense and would explain the two crashes when no passphrase was entered but required. I've changed the code now in a way that it first tries to create a private key object and if that's failing you will again get the authentication prompt.
EDIT²] Using OpenSSH private key file crash Royal TS :-( [/EDIT²]
I'm not sure if those crash reports I got were caused by the private key file or by the missing passphrase. I couldn't identify the crash report.
I've see you have added a configuration key "SSHMouseWheelSpeed" in the Royal TS's config file Set the value to 10 and now scrolling is perfect !! Thanks you so much
I wanted to update the forum post but it seems you figured it out already
For the colors, a little bug appear when you choose a color with the color picker: when closing it, the corresponding textbox has 2 sharp sign (#) so an error message is shown on validation asking for valid colors but it works when manually corrected!
also fixed. thanks for the hint
I've still not uploaded the new build with the fixes because I hope I get some more into the build in the next couple of hours. I suggest you watch or subscribe to changes for the blog post (if not already done): http://www.code4ward.net/main/forums/...
cheers,
Stefan
|
|
|
|
| |
|
|
|
|
Joined: 8/11/2008
Posts: 2299
|
| |
| |
|
|
|
|
Joined: 12/28/2011
Posts: 355
|
|
|
Stefan,
I've made some tests with the new build:
-
The crash with only login provided is gone
-
The crash with passphrase needed but not provided is gone
-
The crash with an OpenSSH key is always here, I should have received a bug report for this... It's an "Invalid Key Format" error (I didn't noticed yesterday). I saw on the Rebex doc that they support this kind of key, but perhaps it need additionnal infos when creating the object
For other remaining little issues, I'll use other threads
P.S.: I'll write a little doc to help you configure a private key on your test server and send it to you on your email at codeforward.net I've sent you the little Howto on your email at codeforward.net 
|
|
|
|
| |
|
|
|
|
Joined: 8/11/2008
Posts: 2299
|
|
|
Last info I got was that the private key files from OpenSSH and Putty are working fine in the later builds.
Thanks again for helping me out here!
|
|
|
|
| |