Matthew Vernon
2015-Mar-24 18:28 UTC
[Debian bug 781107] ssh-keygen -F return code has changed and is not documented
Hi, I tripped over the effects of commit 660854 [0] when moving some infrastructure from Debian 7 to 8 (openssh 6.0 to 6.7); our ansible module used "return 0, but no output" for 'host not found in known_hosts file', and now complains that ssh-keygen is returning an error status. I don't think this change in API was announced in the release notes? i.e. ssh-keygen -F foo.invalid -f ~/.ssh/known_hosts used to return 0 (and no output), and now returns 1 (and no output). Is the non-zero return code really helpful here? Much infrastructure will have to support the old API for the foreseeable future, and I'm not sure it's really an error condition for a host to not be in the known_hosts file. Less controversially, could the return values of ssh-keygen and their meanings be documented (and flagged when they change), please? Regards, Matthew [0] https://anongit.mindrot.org/openssh.git/commit/?id=660854859cad31d234edb9353fb7ca2780df8128
Damien Miller
2015-Mar-24 22:53 UTC
[Debian bug 781107] ssh-keygen -F return code has changed and is not documented
On Tue, 24 Mar 2015, Matthew Vernon wrote:> Hi, > > I tripped over the effects of commit 660854 [0] when moving some > infrastructure from Debian 7 to 8 (openssh 6.0 to 6.7); our ansible > module used "return 0, but no output" for 'host not found in known_hosts > file', and now complains that ssh-keygen is returning an error status. I > don't think this change in API was announced in the release notes? > > i.e. ssh-keygen -F foo.invalid -f ~/.ssh/known_hosts used to return 0 > (and no output), and now returns 1 (and no output). > > Is the non-zero return code really helpful here?Yes, it lets you tell whether the hostname is present in known_hosts.> Less controversially, could the return values of ssh-keygen and their > meanings be documented (and flagged when they change), please?Sure, someone has to do the work though. -d
Matthew Vernon
2015-Mar-25 14:32 UTC
[Debian bug 781107] ssh-keygen -F return code has changed and is not documented
On 24/03/15 22:53, Damien Miller wrote:> On Tue, 24 Mar 2015, Matthew Vernon wrote: > >> Hi, >> >> I tripped over the effects of commit 660854 [0] when moving some >> infrastructure from Debian 7 to 8 (openssh 6.0 to 6.7); our ansible >> module used "return 0, but no output" for 'host not found in known_hosts >> file', and now complains that ssh-keygen is returning an error status. I >> don't think this change in API was announced in the release notes? >> >> i.e. ssh-keygen -F foo.invalid -f ~/.ssh/known_hosts used to return 0 >> (and no output), and now returns 1 (and no output). >> >> Is the non-zero return code really helpful here? > > Yes, it lets you tell whether the hostname is present in known_hosts.Iff nothing else has gone wrong - ssh-keygen -F can return 1 in other cases, as well. So you're still left with relying on an absence of output, aren't you? Regards, Matthew
Matthew Vernon
2015-Mar-25 15:31 UTC
[Debian bug 781107] ssh-keygen -F return code has changed and is not documented
On 24/03/15 22:53, Damien Miller wrote:> On Tue, 24 Mar 2015, Matthew Vernon wrote:>> Less controversially, could the return values of ssh-keygen and their >> meanings be documented (and flagged when they change), please? > > Sure, someone has to do the work though.I had a look; ssh-keygen either exits 1 or 255 (via fatal). It's not clear to me from reading the code what the rationale is for picking 1 or 255; what is the intended difference in meaning between these two errors (or alternatively, how do you decide whether to call fatal or print and error and exit(1))? Thanks, Matthew