Bug 2234

Summary: ssh-add -l output aborts on unrecognized key, skips flush when stdout not tty
Product: Portable OpenSSH Reporter: Phil Pennock <phil.pennock>
Component: ssh-addAssignee: Assigned to nobody <unassigned-bugs>
Status: CLOSED FIXED    
Severity: normal CC: djm
Priority: P5    
Version: 6.6p1   
Hardware: All   
OS: All   
Bug Depends on:    
Bug Blocks: 2226    

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.