Bug 39727
| Summary: | strange message in log | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Need Real Name <mal> |
| Component: | openssh | Assignee: | Tomas Mraz <tmraz> |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.0 | CC: | pekkas |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-02-03 09:04:06 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Need Real Name
2001-05-08 23:21:46 UTC
Depends on what kind of circumstance you got it in. It should contain the reason for disconnecting. Using: openssh-2.5.2p2-1.6.2 I've gotten e.g.: May 9 09:17:07 xxx sshd[26924]: Received disconnect from aaa.bbb.1.97: 11: Disconnect requested by Windows SSH Client. May 9 13:26:28 xxx sshd[23428]: Received disconnect from aaa.bbb.2.38: 13: Authentication cancelled by user. I do not have a reason. Just some garbage printed instead: Apr 30 12:02:11 xxx sshd[14539]: Received disconnect from 1.2.3.4: 11: XX^R It is sililar to yours (11: there, but no error message, just some random symbols). Also I tested this on two computers (both RedHat 7.0 will all updates). In both log I have same error messages with random data printed rpm -q openssh openssh-2.5.2p2-1.7.2 I checked few logs the strings printed there may be: XX^R ^\S^R X<FB>^R ^H<F7>^R The client is ssh 2.0.12 from DataFellows, seems some string from the data went directly to log. My logs show this happening once on a RHL62 system with 2.5.2p2. The connecting client is most probably some old Windows one; Data Fellows might not be a bad bet. The string there is printed from the packet by buffer_get_string function as intended. The client isn't just recording anything sane in there. I suspect a client-side bug, but I don't see this very interesting issue unless the client is acting so oddly that it hinders the normal use ;-) I suggest resolving this as NOTABUG. The only question I have: is this save to put a string read from a client directly to log. Should the string be escaped or something else done with it? The string is limited to 400 characters, normal format string attack methods don't work with it, and NULL is added at the end of it. It should be as safe as you can get. |