bugzilla-daemon at mindrot.org
2024-Oct-23 02:01 UTC
[Bug 3746] New: ssh-keyscan output format is not compatible with ssh-keygen -s
https://bugzilla.mindrot.org/show_bug.cgi?id=3746 Bug ID: 3746 Summary: ssh-keyscan output format is not compatible with ssh-keygen -s Product: Portable OpenSSH Version: 9.2p1 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: ssh-keyscan Assignee: unassigned-bugs at mindrot.org Reporter: pmk.64k84 at lgosys.com Created attachment 3840 --> https://bugzilla.mindrot.org/attachment.cgi?id=3840&action=edit Test case showing syntactic differences and resulting error Using scp (or some other direct-copy method) to fetch a host public key (in this case ed25519) results in a syntactic structure which could be described as "ssh-ed25519 key root at host". Using ssh-keyscan to fetch the same host public key results in the syntactic structure "host ssh-ed25519 key" where "host" is the mechanism used to identify the host on the command (IP address, host name, FQDN). When used as an input to `ssh-keygen -s` the presence of the "host" portion causes ssh-keygen to complain "No such file or directory" even though the file is there. Editing the ssh-keyscan download (eg piping to `cut -d " " -f 2-3`) cures the problem, at least for certificate generation. I'm presenting this as an enhancement request because it seems to me that the least disruptive way of ensuring compatibility between ssh-keyscan outputs and ssh-keygen's requirements is to add an option to ssh-keyscan which removes the "host" portion, reducing it to just "ssh-ed25519 key". The absence of the "root at hostname" portion does not seem to matter to `ssh-keygen -s`. I suppose the alternative would be to treat this as a bug in ssh-keygen, where it should be ignoring the "host" portion of the ssh-keyscan output. I have tested this on both macOS 14.6.1 (SSH-2.0-OpenSSH_9.7) and a variety of Debian-based systems (SSH-2.0-OpenSSH_8.4p1 Debian-5+deb11u3 and SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u3). I see the same behaviour on all systems, irrespective of whether the system is where ssh-keyscan is running, or is the target of the operation. Although my focus is on ed25519 keys, the same pattern is evident with rsa keys. I was really surprised that I was unable to find an existing bug report mentioning this problem. -- You are receiving this mail because: You are watching the assignee of the bug.