Welcome to the VanDyke Software Forums

Join the discussion today!


Go Back   VanDyke Software Forums > Secure Shell

Reply
 
Thread Tools Display Modes
  #1  
Old 04-17-2007, 11:29 AM
tcarey tcarey is offline
Registered User
 
Join Date: Apr 2007
Posts: 3
VShell stops authenticating on Windows 2000 DC Server

Hi all.
I have been having this problem for years and figured I would check in these forums for something to resolve it other then rebooting the server.
After some time of running VShell will stop authenticating with the DC.
I am using VShell Version 2.6.1 (build 410) - Official Release - April 25, 2006however the issue did not resolve on these Domain Controllers.
The issue has been occurring since VShell 2.3 and was resolved on many other servers after upgrading to 2.6.1
I have tried to connect both by using my public keys and by using another id and manually typing password and receive the same errors in the logs.
Quote:
12:18:48,auth,00040: password for user userid accepted.
12:18:48,conn,00040: Session channel open request accepted.
12:18:48,conn,00040: OnWrite: The pipe has been ended.

12:18:48,conn,00040: Session channel has been closed (pid: 5540).
12:18:48,conn,00040: Connection closed.
Quote:
12:25:01,dbg ,00042: Using home directory "C:\Documents and Settings\UserID\My Documents" for user UserID.
12:25:01,dbg ,00042: Received request to start C:\WINNT\system32\CMD.EXE via Scraper.exe.
12:25:01,dbg ,00042: started user process (6284)
12:25:01,dbg ,00042: Received EOF on stdout from running program.
12:25:01,conn,00042: OnWrite: The pipe has been ended.

12:25:01,dbg ,00042: Process 6284 has exited, exit-status: 128
12:25:01,dbg ,00042: Initiating close on session channel.
12:25:01,conn,00042: Session channel has been closed (pid: 6284).
12:25:01,dbg ,00042: [LOCAL DEBUG] RECV: TCP/IP close
12:25:01,dbg ,00042: [LOCAL DEBUG] Changing state from STATE_CONNECTION to STATE_CLOSED.
12:25:01,dbg ,00042: [LOCAL DEBUG] Connected for 1 seconds, 2297 bytes sent, 2526 bytes received
12:25:01,conn,00042: Connection closed.
If I restart the VShell Service I still have the same issues.
If I reboot the server itself I can authenticate fine by keys and by passwords.
I know that VShell has ties into the LSASS process and I believe this is what causes my issues.
Is there a way to restart VShell Completely without rebooting the server?

Last edited by tcarey; 04-17-2007 at 11:33 AM.
Reply With Quote
  #2  
Old 04-17-2007, 07:01 PM
miked's Avatar
miked miked is offline
Registered User
 
Join Date: Feb 2004
Posts: 2,040
Hi tcarey,

Thanks for providing an excellent problem description.

The problem is not with authentication, because the password is accepted and VShell tries to start a process. It's when VShell tries to start CMD.EXE that the problem occurs.

The 128 exit-status code listed in the VShell log is returned by the Windows OS when VShell attempts to launch CMD.

Microsoft provides a list of error codes and 128 indicates "ERROR_WAIT_NO_CHILDREN". One possible cause of this problem is described in this Microsoft KB article. When VShell users have seen this problem in the past it is often because the Windows OS is running low on "desktop heap".

Microsoft Windows has a desktop resource limitation of 48-MB.

The Microsoft KB article listed above also includes a possible workaround in which the amount of memory allocated for each non-interactive desktop (what VShell uses to launch CMD) can be allocated in smaller chunks, therefore allowing more non-interactive desktops to be created concurrently.

If you specify a value of 128 for the third "SharedSection" value in the registry key mentioned as part of the above KB article, VShell should be able to successfully launch CMD for more simultaneously connected users.

There will still be a limitation, but with a smaller per non-interactive desktop help allocation, the limit will be higher.

The system reboot solved the problem because active shell connections using non-interactive desktop heap were closed.

How many individuals do you typically have connected at any given time?

Have you noticed how many are typically connected when this problem occurs?
__________________
Mike
VanDyke Software
Technical Support
[http://www.vandyke.com/support]
Reply With Quote
  #3  
Old 04-18-2007, 07:35 AM
tcarey tcarey is offline
Registered User
 
Join Date: Apr 2007
Posts: 3
miked,
Thanks for the response.
I will give it that a shot but am not sure that this is the actual issue.
I had stated that this was a VShell issue since it used to happen on about 50% of my servers and resolved itself on all of them except these DC's when we upgraded to 2.6.1.
I have no idea how many users are connected at the time that this stops working. After this issue is reported, there are no active connections. Nobody can connect to the servers. It almost seems as though something is being cached and needs to be flushed before it will work again.
Since these are DC's we do not have many people connecting to Windows itself.
The DC's are only used due to a cluster that runs SQL.
There may be SQL connections at the time but there are no actual Windows connections.
There was also one discrepency I saw in the KB Article.
The KB Article has 3 values after SharedSection:
SharedSection=1024,3072,512
My server has 4 values:
SharedSection=1024,3072,2048,512
I will attempt the change from the 512 to 128 and will let you know but I am very skeptical about this being the fix for the issue.

Last edited by tcarey; 04-18-2007 at 07:37 AM.
Reply With Quote
  #4  
Old 04-18-2007, 11:49 AM
miked's Avatar
miked miked is offline
Registered User
 
Join Date: Feb 2004
Posts: 2,040
I can see why you're a little bit skeptical about the cause in light of a similar problem in other servers being fixed by upgrading to VShell 2.6. Experience is a pretty convincing teacher! I appreciate your willingness to try.

In case it wasn't clear in the article, after changing the 512 value to 128 you'll need to reboot.

From what I have found on the Internet, the fourth value you found seems to be related to the terminal services heap size.

Regarding your previous experience with upgrading VShell fixing a problem, without VShell log file information from the previous problem we can't see what the problem was and can't know why an upgrade helped. But, there was a problem in earlier versions of VShell (prior to 2.3.7) in which the LSA module would occassionally stop working properly. This would prevent authentication with public key. It would appear similar to the end user in that they could never acquire a shell.

The problem you're experiencing this time is related to starting a shell process, and is not an authentication problem, according to the VShell log.

As previously mentioned, the workaround in the KB article is not a solution so much as a way to give you some breathing room. You will still hit the desktop heap ceiling if enough connections are made.

How many individuals do you typically have connected to VShell at any given time?

Have you noticed how many are typically connected to VShell when this problem occurs?
__________________
Mike
VanDyke Software
Technical Support
[http://www.vandyke.com/support]
Reply With Quote
  #5  
Old 04-18-2007, 12:10 PM
tcarey tcarey is offline
Registered User
 
Join Date: Apr 2007
Posts: 3
miked,
You are right.
That was the issue in the older versions. I forgot that I could authenticate with passwords with the older version and it was only my Keys that would not authenticate.
It seemed like the same issue but yes you are correct that the logs show it is authenticating now.

We rarely have more then 2 or 3 connections through VShell simultaneously. It does seem as though something within Windows or VShell is still holding onto the Desktop even after disconnecting from VShell.
The last time it had stopped allowing the shell to start there were no users logged in but 1 user was logged in and had logged off right before the issue occurred.
I have set the registry change and will try to schedule a reboot with our customer. I will let you know if this does resolve the issue but my skepticism is more that it is only going to delay the issue and not resolve because as I mentioned, it seems like something is holding onto the cached Desktop even after logging off from Vshell sessions.
Reply With Quote
  #6  
Old 04-19-2007, 09:47 AM
miked's Avatar
miked miked is offline
Registered User
 
Join Date: Feb 2004
Posts: 2,040
Quote:
it seems like something is holding onto the cached Desktop even after logging off from Vshell sessions.
With so few users logged on when the problem occurs, I think you're right about something holding onto the cache. Or, maybe some program we've not cosidered at much length is taking up desktop heap (SQL uers, or something else). I tthink we desparately need more data and I'm not sure how to get the data.

I just found a Desktop Heap Monitor program at Microsoft's website. I haven't had a chance to test it yet, but if it works it should give us a better idea of whether the desktop heap memory consumption is a problem at the time the problem occurs, assuming as we both seem to be that the problem is going to happen again.
There are system requirements for the desktop heap monitor. Which Windows operating system are you using (2000, 2003, etc.)?

Do you think you could try the desktop heap monitor and let us know what you observe?
__________________
Mike
VanDyke Software
Technical Support
[http://www.vandyke.com/support]
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -6. The time now is 01:51 AM.