| Summary: | ssh man page lists the -Q option as accepting a remote destination | ||
|---|---|---|---|
| Product: | Portable OpenSSH | Reporter: | trevor.hemsley |
| Component: | Documentation | Assignee: | Assigned to nobody <unassigned-bugs> |
| Status: | NEW --- | ||
| Severity: | enhancement | ||
| Priority: | P5 | ||
| Version: | 9.1p1 | ||
| Hardware: | Other | ||
| OS: | Linux | ||
man ssh on Fedora 36 (8.8p1)and Debian 12 (9.1p1) lists the -Q option as part of the same list as all other options and thus indicates that it takes a destination hostname. As far as I can see from experimentation `ssh -Q kex remotehost` and `ssh -Q kex` report exactly the same list and there are no packets show up in a tcpdump for 'remotehost' so it would appear that ssh -Q always queries the local system and never communicates remotely. Of course, it would be really really cool if it did take a remotehost name but I suspect the chances of getting that changed are slim to non-existent so a doc change seems like a better route. Seems to me that the man page should list a second way of running ssh with only -Q listed and no destination to better differentiate the one from the other. i.e ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface] [-b bind_address] [-c cipher_spec] [-D [bind_address:]port] [-E log_file] [-e escape_char] [-F configfile] [-I pkcs11] [-i identity_file] [-J destination] [-L address] [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port] [-R address] [-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]] destination [command [argument ...]] or ssh -Q query_option