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
Seemingly Similar Threads
- bug or feature with ssh-keygen and user CAs?
- ssh-keygen listing fingerprints little unclear
- [Bug 2591] New: ssh-keygen -R is case-sensitive, but should not be
- [Bug 2145] New: ssh-keygen -R doesn't work when there are entries for "proxycommand" keys
- ssh-keygen key length mismatch?