By rmassart - 6/16/2014 4:50:48 AM
I don't seem to be able to get fortress to update or createe the authorized_keys2 file. If the file already contains the user's public key, authentication works. But if a new user supplies their public key for the first time and file does not exist and authenticates using their domain password I get errors like this in the fortress log:
Server Fatal error: recv from socket failed: No such file or directory
And like this in the event log:
Unable to stat() authorized keys file [path to file]
It also does not work if the file exists and is empty.
I suspect I am missing a permission, but it's not clear which. Or is there something else wrong?
The fortress version is: Version: 5.0 Build 9 Revision 2031
Thanks.
|
By bethredd - 6/16/2014 6:32:46 AM
Hello,
The authorized_keys2 file is modified under the user context of the user trying to store the key. The user should have read/write access to the authorized_keys2 file as well as the configured directory location for authorized_keys. The socket error is not related to the authorization. This error could be from the client disconnecting while trying to authorize. You can try a verbose connection on the client side to see if it is closing after the authentication fails.
|
By rmassart - 6/16/2014 8:50:37 PM
I can no longer authenticate using my public key either. I get these messages in the application event logs and I am seeing these error messages:
Faulting application name: sshd64.exe, version: 5.0.9.2031, time stamp: 0x50b66b5c
Faulting module name: PragmaAuth.dll, version: 5.0.9.2031, time stamp: 0x50b6696c
Exception code: 0xc0000417
Fault offset: 0x000000000000578c
Faulting process id: 0x6b8
Faulting application start time: 0x01cf8a003d383c9c
Faulting application path: C:\Program Files\Pragma\Fortress\sshd64.exe
Faulting module path: C:\Program Files\Pragma\Fortress\PragmaAuth.dll
Report Id: 7cf9fc5d-f5f3-11e3-8327-00237dd085be
Can you help?
Thanks,
Robin
|
By bethredd - 6/17/2014 1:57:07 AM
Hello,
You will need to update to the latest build for a fix fore this issue. Please go to http://www.pragmasys.com/ssh-server/download to get the latest version. You will be able to install directly over your existing installation. Please make sure that all sessions are closed and all configuration programs are closed. You should reboot after the update.
|
By rmassart - 7/1/2014 1:28:50 AM
I am still struggling with this.
I have these two errors in the event log:
=========================
Faulting application name: sshd64.exe, version: 5.0.9.2696, time stamp: 0x539a6b15
Faulting module name: ntdll.dll, version: 6.1.7601.22436, time stamp: 0x521eb03f
Exception code: 0xc0000374
Fault offset: 0x00000000000c4322
Faulting process id: 0x1c7c
Faulting application start time: 0x01cf947349aad1b6
Faulting application path: C:\Program Files\Pragma\Fortress\sshd64.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: 8da2df76-0066-11e4-b191-00237dd06bb8
==========================
Faulting application name: sshd64.exe, version: 5.0.9.2696, time stamp: 0x539a6b15
Faulting module name: PragmaAuth.dll, version: 5.0.9.2696, time stamp: 0x539a6937
Exception code: 0xc0000417
Fault offset: 0x000000000000579c
Faulting process id: 0x1a54
Faulting application start time: 0x01cf9504aa240e7e
Faulting application path: C:\Program Files\Pragma\Fortress\sshd64.exe
Faulting module path: C:\Program Files\Pragma\Fortress\PragmaAuth.dll
Report Id: e9901c9b-00f7-11e4-b191-00237dd06bb8
=========================
The first mentions ntdll.dll and the second is PragmaAuth.dll.
What I can't get to work is the initial registration of a user without using the registry to store keys. I cannot get the system to update the authorized_keys2 file. If I have the registry enabled, it works *sometimes*. ie eventually I see the new public key in the authorized_keys2 file, but I do not know how it got updated. You mentioned above that the user who is loging on is the account that needs access to the file, but I don't see that. Login only seems to work if I give "Everyone" read access. Am I missing another account that needs read access?
Once the public key is stored in this file, I can connect from both our load balanced servers and read the key stored on our fileserver.
I have also manually removed the Keys from the PAD folder in the registry. I know this is bad practice, but I want to make sure the system is not authenticating from there. This however has caused problems and might be the cause of the errors about. I am not sure. Is there a documented way of removing the keys stored in the registry?
At the moment I can't help feeling there is some dependency between storing keys in registry and in the authorized_keys2 file.
Thanks for your help...
Robin
|
By bethredd - 7/1/2014 4:50:52 AM
Hello,
I'm sorry that you are having such issues. Please make sure that you have Auto store keys in the registry and Authenticate from the registry off. There is no need to have either of these on to use authentication from file. Also make sure you have Always or "Only when autoloading keys" selected on the Password Options page. Lastly, you will need to reboot if you have not already. The passwordless authentication library requires a reboot. If you continue to have issues, please turn on Server Operation Logging. 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 where the user fails to logon, then send me the file.
|
By rmassart - 7/3/2014 4:10:20 AM
What I have been able to deduce so far is that when there is an entry in the PAD folder in the registry, the user can logon with their public key and it will be stored correctly in their authorized_keys2 file. When there is no such entry, the error below occurs.
Help!
Attached is a log file as requested. There seems to be a problem loading the user profile?
The error message in the event viewer i:
Faulting application name: sshd64.exe, version: 5.0.9.2696, time stamp: 0x539a6b15
Faulting module name: PragmaAuth.dll, version: 5.0.9.2696, time stamp: 0x539a6937
Exception code: 0xc0000417
Fault offset: 0x000000000000579c
Faulting process id: 0x13f4
Faulting application start time: 0x01cf96cf54ea95bc
Faulting application path: C:\Program Files\Pragma\Fortress\sshd64.exe
Faulting module path: C:\Program Files\Pragma\Fortress\PragmaAuth.dll
Report Id: 936fbdbc-02c2-11e4-bbb5-00237dd06bb8
|
By bethredd - 7/7/2014 5:22:33 AM
I've forwarded all of this information to the developer. He is looking into the issue now.
I will get back to you as soon as I hear something from him.
|
By rmassart - 7/20/2014 7:39:29 PM
Is there any feedback from the developer?
|
By bethredd - 7/21/2014 1:01:29 AM
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.
|
By rmassart - 7/21/2014 2:31:49 AM
What is the effect of the debug version? This would be installed on our production servers that run our plain FTP services.
Thanks.
|
By bethredd - 7/22/2014 4:31:04 AM
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.
|
By rmassart - 7/23/2014 8:10:59 PM
OK, could you provide me the link to the debug version. We can then see about installing it here.
Thanks,
Robin
|
By bethredd - 7/24/2014 4:21:39 AM
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.
|
By rmassart - 7/24/2014 7:47:02 PM
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
|
By bethredd - 7/25/2014 4:47:45 AM
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.
|
By rmassart - 7/28/2014 4:18:30 AM
OK, I have sent you an email with the requested log files.
Regards,
Robin
|
By bethredd - 7/28/2014 4:22:08 AM
The files did not make it through. Can you please email me through our support email at support@pragmasys.com.
|
By rmassart - 8/4/2014 3:42:46 AM
OK, I have sent an email to that address.
|