Bug 2234 - ssh-add -l output aborts on unrecognized key, skips flush when stdout not tty
Summary: ssh-add -l output aborts on unrecognized key, skips flush when stdout not tty
Status: CLOSED FIXED
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: ssh-add (show other bugs)
Version: 6.6p1
Hardware: All All
: P5 normal
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks: V_6_7
  Show dependency treegraph
 
Reported: 2014-04-19 14:50 AEST by Phil Pennock
Modified: 2014-10-08 09:01 AEDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Phil Pennock 2014-04-19 14:50:58 AEST
Under SSH Agent Forwarding, when using an ssh-agent with keys loaded for key-types not recognized by the remote host, running "ssh-add -l" on the remote host will abort with fatal() when it sees the unrecognized key-type.

If stdout is a tty, then stdio is line-buffered and the first seen SSH keys will have their fingerprints emitted.  If stdout is not a tty, then the stdio is never flushed and only the stderr output will be emitted.  The fingerprints are lost.

"ssh-add -L" emits a line for every key loaded, without aborting, and unhandled key-types can be detected by checking if the line begins with whitespace.

The current behaviour working as well as it does is based on only one set of keys being loaded and the most portable keys being loaded first.

The current behaviour can be made agnostic of tty/non-tty by inserting a `setlinebuf(stdout);` call into `list_identities()`.

A more reliable approach might be to give `key_fingerprint()` a flag to avoid calling fatal and to return an error some other way?
Comment 1 Damien Miller 2014-07-03 13:15:38 AEST
I just committed a change to make ssh-add's output line-buffered. This will be in OpenSSH-6.7 -- thanks!
Comment 2 Damien Miller 2014-10-08 08:00:59 AEDT
Close all bugs left open from 6.6 and 6.7 releases.
Comment 3 Phil Pennock 2014-10-08 09:01:15 AEDT
Just to re-emphasize: the current fix only makes sure that the behaviour is independent of whether or not stdout is a tty.

The `ssh-add -L` aborting on the first unhandled key type remains; if two sets of keys are loaded, but a key in the first set is unhandled by the remote agent, then the handled keys from the second set will never be listed.  So this bug still remains.