| Summary: | Overly verbose partial authentication | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Portable OpenSSH | Reporter: | cgallek | ||||
| Component: | ssh | Assignee: | Assigned to nobody <unassigned-bugs> | ||||
| Status: | CLOSED FIXED | ||||||
| Severity: | enhancement | CC: | dtucker | ||||
| Priority: | P5 | ||||||
| Version: | 7.2p1 | ||||||
| Hardware: | Other | ||||||
| OS: | Linux | ||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 2543 | ||||||
| Attachments: |
|
||||||
These things are going to stderr, right? Which tools are parsing ssh's stderr and for what purpose? They do indeed go to stderr. Sorry, I didn't mean to imply something was parsing them. But things like `rsync --quiet ...` and `git fetch --quiet ...` are no longer quiet in this configuration. This is particularly annoying in cron invocations that send stderr in an email. (In reply to cgallek from comment #2) > They do indeed go to stderr. Sorry, I didn't mean to imply > something was parsing them. But things like `rsync --quiet ...` and > `git fetch --quiet ...` are no longer quiet in this configuration. > This is particularly annoying in cron invocations that send stderr > in an email. Any reason you can't set the tool in question to invoke "ssh -q" or put "LogLevel quiet" or "LogLevel error" in the ssh_config or ~/.ssh/config for the relevant Host? Those are certainly valid work-arounds to the issues I'm having, but I would argue that this message is not useful even in the interactive path with the default logging level. It's not an error and it doesn't solicit user interaction. All of the other uses of the INFO level in this file fall into one of those categories. It's certainly useful for development and debugging, but not to the end user. It may even be worth arguing that this message should be part of one of the DEBUG levels. The following examples from sshconnect2.c seem like valid precedent:
line 399:
debug("Authentication succeeded (%s).", authctxt.method->name);
line 556:
debug("Authentications that can continue: %s", authlist);
line 1888:
debug("Next authentication method: %s", name);
That's a reasonable point :-) Patch applied and will be in the 7.3 release. Thanks. Close all resolved bugs after 7.3p1 release |
Created attachment 2856 [details] quiet-log.patch When connecting to a server which requires multiple authentication methods (eg AuthenticationMethods publickey,password publickey,keyboard-interactive) the following message is displayed after the first authentication succeeds: "Authenticated with partial success." This message is a bit too verbose especially in the context of other tools (git, rsync, etc) which use ssh as the underlying protocol. The attached patch moves this message from the INFO log level to VERBOSE.