Permissions needed to write to authorized

Pragma Systems Technical Forum

Back

Home
»
Community
»
FortressSSH
»
Permissions needed to write to authorized_keys2 file

Permissions needed to write to authorized_keys2 file

Author	Message
rmassart	rmassart posted 10 Years Ago Post Details
Group: Forum Members Posts: 21, Visits: 112	OK, I have sent an email to that address.
	Reply Like 3
Beth Redd	Beth Redd posted 10 Years Ago Post Details
Group: Administrators Posts: 81, Visits: 180	The files did not make it through. Can you please email me through our support email at support@pragmasys.com. Beth Redd
	Reply Like 4
rmassart	rmassart posted 10 Years Ago Post Details
Group: Forum Members Posts: 21, Visits: 112	OK, I have sent you an email with the requested log files. Regards, Robin
	Reply Like 4
Beth Redd	Beth Redd posted 10 Years Ago Post Details
Group: Administrators Posts: 81, Visits: 180	Robin, Thank you so much for your patience with this issue. With your help, we might be able to duplicate the issue and fixed it for everyone. :) I'd like you to do some server operation logging. On both server 1 and server 2. Go to the Logging page on the Local Server Configuration program. Turn on Server Operation Logging and set the level to 6. Configure a directory for the log files. Make sure that the ssh users have write access to the configured directory. Run a test with both user1 and user2 connecting to each server, for a total of 4 tests, then send me all the files. You can turn off logging after the tests are run. Beth Redd
	Reply Like 3
rmassart	rmassart posted 10 Years Ago Post Details
Group: Forum Members Posts: 21, Visits: 112	Our problem is more generic - I am having trouble getting the public keys to work using network drives. I do not want to use the Registry because the servers are load balanced. What I have managed to deduce is the following: We have two test users: UserA and UserB We have two servers: Server1 and Server2 Bother users have their public key stored in an appropriate location on a shared drive. UserA has a PAD entry in the Registry on Server1, but not on Server2 UserB has a PAD entry in the Registry on Server2, but not on Server1 Bother servers are now configured to not store the key in the registry. UserA can successfully connect using his key to Server1, but not Server2 UserB can successfully connect using his key to Server2, but not Server1 So they users can only connect to the server which have an appropriate PAD entry for them in the registry. Even though the servers are configured to use the network share for the key authentication. this leads me to believe that authentication is still involving the registry in some way. I will have a think about the other users issue you mentioned. I have also noticed that if the directory doesn't exist in advance it doesn't seem to work - but then this is possibly to be expected. it's not a problem for us to create these directories in advance. Thanks, Robin
	Reply Like 3
Beth Redd	Beth Redd posted 10 Years Ago Post Details
Group: Administrators Posts: 81, Visits: 180	Robin, You can download at www.pragmasys.com/dropbox/PragmaFortressDebug.zip. There is also a possible workaround that another customer shared with me yesterday. I'm not sure if it will work in your case, but it's worth a try. He connected with the username and passwordfirst. Then made sure he had store Passwords Always. Then reconnect with keys. He was having issues with only a single user and it appears that the problem was due to the authorized_keys2 configured directory did not exist prior to trying to store the key. We are still not able to duplicate the issue with even his setup, but we are still trying. If there is anything special about your user you can share with us that might help us duplicate the issue. Thanks again for your patience. Beth Redd
	Reply Like 4
rmassart	rmassart posted 10 Years Ago Post Details
Group: Forum Members Posts: 21, Visits: 112	OK, could you provide me the link to the debug version. We can then see about installing it here. Thanks, Robin
	Reply Like 4
Beth Redd	Beth Redd posted 10 Years Ago Post Details
Group: Administrators Posts: 81, Visits: 180	The debug version is actually compiled as a debug binary. There is nothing different in the operation of it, but the run times are more lenient with some of the calls. So instead of crashing, it will allow the operation to proceed. From our tracking the issue is occurring as part of the clean up, so allowing the call to proceed will not cause any other issues. This will be temporary until we are able to determine the exact cause of the issue and get a fix released. Beth Redd
	Reply Like 2
rmassart	rmassart posted 10 Years Ago Post Details
Group: Forum Members Posts: 21, Visits: 112	What is the effect of the debug version? This would be installed on our production servers that run our plain FTP services. Thanks.
	Reply Like 4
Beth Redd	Beth Redd posted 10 Years Ago Post Details
Group: Administrators Posts: 81, Visits: 180	I'm sorry for the not getting back to you. The developer has been unable to duplicate the issue. A workaround is to provide you with debug versions of the sshd binary and the pragmaauth.dll. This has worked for another cusotmer having a similar issue. Would you be willing to test with the debug versions? I can provide you a download link if you are interested. Beth Redd
	Reply Like 5