OpenSSH fixes for NetWare 6.5 SP8
This document (5089630) is provided subject to the disclaimer at the end of this document.
patches this patch supersedes
| File | Product | Status | Patch |
|---|---|---|---|
| NWsshd8a.zip | NetWare 6.5 SP8 | Active | OpenSSH patch for NW65SP8 |
patches that supersede this patch
patch attributes
document
abstract
This update fixes certain SFTP and SCP transfer problems (including a potential abend) which can occur when the current working directory of the session is a "remote volume" -- a volume on a Novell NCP server other than the server directly connected to by the SFTP or SCP client. It also carries forward previous patch updates which allow successful downloading of files greater than 2 Gigabytes, eliminate memory leaks, and tighten security policy for public key authentication.
details
System Requirements:
NetWare 6.5 SP8
Installation:
Unzip the contents of NWsshd8b.zip so that the new NLMs are extracted into the SYS:SYSTEM directory. (Or unzip to a temporary location and copy the NLMs to SYS:SYSTEM.)
Technical Support Information:
[Bug 561788]
Corrects the following issue: An SCP client is attempting to download a file via NetWare SERVER1. However, the file actually resides on Novell SERVER2. (This is possible because of Novell's server-to-server NCP capability.) The file exists, but no data is transferred to the client. The session closes without error and a zero-byte file now exists on the client.
[Bug 542422]
Corrected a buffering problem with file uploads over 10 MB. The problem was typically seen during SFTP uploads from a WinSCP client, though conceivably it could occur with other clients as well. Some SFTP clients throttle their upload speed and thereby avoid the issue.
The scenario is as follows: A WinSCP client is uploading a file to NetWare SERVER1, but the current working (destination) directory actually resides on SERVER2. The client-to-server1 communication is rapid, but the server1-to-server2 communciation is slow (for whatever reason). This causes a 10 MB data-handling buffer in SSHD to be exceeded. SERVER1 aborts the process and sometimes SERVER1 abends.
The upload will now complete. However, it is important to understand the new expected behavior in this speed-differential situation. The first 10 MB of the file will still transfer to SERVER1 quickly. Then the transfer speed with throttle down, as new data can only be accepted as data is delivered to SERVER2 and space in the buffer is freed. After the rest of the data is sent, the client may seem to stall and may even indicate that the server is not responding for a short time (possibly 30 - 40 seconds). During this delay, SERVER1 is sending the remaining bufferred data to SERVER2. Once this is finished, the client will be told that the transfer is complete.
Fixes also present, previously released in NWsshd8a.zip:
[Bug 493078]
Switched to 64-bit calls to support large file downloads. Previous to this patch, upon attempting to exceed 2 GB during download, the session would fail and the SFTP client would show the error:
Couldn't read from remote file "/server1/vol1/file1" : No such file or directory
Note: Support for large *uploads* was added previously
[Bug 353967]
Tightened the requirement that SSHD verify the user's eDir password during the first public key authentication, to finalize the public key authentication setup for that user.
Note: In rare cases, updating to this fix could result in a one-time need for some users to submit their password again, upon their next attempt at public-key authentication. Even in those rare cases, this should have rather minimal impact, except in cases where the login is part of an automated process. Automated processes using public-key authentication will not be accustomed to supplying a password, and could fail. To correct this, manually do a public key authentication as that user, and when prompted, supply the password. If a list of users in a server's ssh public key user list is desired, go to the NetWare server console, load bash, go to the bash prompt, and give the command: ssh-pubulist
[Bug 487028]
Corrected a resource clean-up problem which would cause the following NLMs to grow in memory usage over time, because of SSHD activity:
CONNMGR
DSLOADER
LIBC
NCPIP
TCP
WS2_32
WSPIP
XMGR
XENGEXP
Some of the memory leakage was due to SSHD changes made in NW 6.5 SP8, although the XMGR and XENGEXP memory issues existed already.
Known limitations:
There may still be some memory growth in XMGR.NLM and XENGEXP.NLM, depending on the environment and the severity of SSH client load on the server. This growth will be slower than the growth seen in these NLMs while using NetWare 6.5 SP7 or prior, but could still be noticable and build up over time to unacceptable levels, making reboot necessary.
file contents
Compressed File Name: NWsshd8b.zip
| Files Included | Size | Date |
|---|---|---|
| NWsshd8b/ssh-kgen.nlm | 546.8 KB (559924) | 2011-03-07 10:57:54 |
| NWsshd8b/ssh-pubu.nlm | 3.5 KB (3594) | 2011-03-07 10:57:54 |
| NWsshd8b/ssh-pubulist.nlm | 68.7 KB (70385) | 2011-03-07 10:57:54 |
| NWsshd8b/scp.nlm | 521.1 KB (533650) | 2011-03-07 10:57:54 |
| NWsshd8b/ssh.nlm | 771.4 KB (789950) | 2011-03-07 10:57:54 |
| NWsshd8b/sshlogd.nlm | 21.7 KB (22306) | 2011-03-07 10:57:54 |
| NWsshd8b/dbtelnet.nlm | 340.2 KB (348371) | 2011-03-07 10:57:54 |
| NWsshd8b/nwterm.nlm | 74.7 KB (76545) | 2011-03-07 10:57:54 |
| NWsshd8b/ssh-pubuadd.nlm | 93.1 KB (95401) | 2011-03-07 10:57:54 |
| NWsshd8b/sshd.nlm | 798.0 KB (817211) | 2011-03-07 10:57:54 |
| NWsshd8b/sftp-svr.nlm | 506.2 KB (518446) | 2011-03-07 10:57:54 |
| NWsshd8b/sftp.nlm | 566.4 KB (580033) | 2011-03-07 10:57:54 |
| NWsshd8b/sshjni.nlm | 3.4 KB (3551) | 2011-03-07 10:57:54 |
| NWsshd8b/ssh-pubudel.nlm | 74.2 KB (76081) | 2011-03-07 10:57:54 |
| NWsshd8b/telnet.nlm | 12.8 KB (13143) | 2011-03-07 10:57:54 |
| license_agreement.txt | 2.8 KB (2909) | 2011-03-15 18:43:00 |
| readme_5089630.html | N/A | 2011-03-16 13:56:28 |
| README_NWsshd8b.html | N/A | 2011-03-16 13:56:28 |
disclaimer
The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information. Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.
Novell is a registered trademark of Novell, Inc. in the United States and other countries. SUSE is a registered trademark of SUSE Linux AG, a Novell business. *All third-party trademarks are the property of their respective owners.
© 2007 Novell, Inc. All Rights Reserved.