https://github.com/vyos/vyos-1x/pull/2363

$ show ssh fingerprints
SSH server public key fingerprints:

1024 SHA256:EyT+ladQR7yL2uzCi9p7U3CjMmSrL+vpv7bVew3ie0I root@vyos (DSA)
+---[DSA 1024]----+
|      . . .oo    |
|     . o . o.    |
|      . o o ..   |
|      o..+oo.    |
|     o .S+.o .   |
|      + .oE o    |
|     . +.B.. o   |
|    oo.o* =.o .  |
|   o*BO=.=+=     |
+----[SHA256]-----+

256 SHA256:6hgo7Uhxo6UORWnvhKo9n+0V0ssMTfK96V8dd2dVJV0 root@debian (ECDSA)
+---[ECDSA 256]---+
|              ..E|
|   .           .o|
|  +   . .       .|
| o o   * .      .|
| .o+o o S .    .=|
| +*+.  * o o   o=|
|++o o . = o   . .|
|==.  * . .   .   |
|o.oo+.+   ...    |
+----[SHA256]-----+

3072 SHA256:Dy9PXHuLIy1TB7EnlzorU3Cq3YSNiBja8ICRTMghwxU root@debian (RSA)
+---[RSA 3072]----+
|O+oE.            |
|==          .    |
| o           o . |
|. o .     . = +  |
|   * o .S. B.*   |
|  . + . .=+.B..  |
|        .o=*.+.  |
|        .+B =o . |
|          .*...  |
+----[SHA256]-----+

256 SHA256:FpsnnJeuqlacYHwC7uz2rVxipG3znDn+Wu1xh7dxQx8 root@debian (ED25519)
+--[ED25519 256]--+
|                 |
|  .              |
| . o    .        |
|  . = .. = .     |
| o ..= .S +    E |
|  o+  +. *   .. o|
| .. *.. . + o +.o|
|  o+.B.+ o o o +.|
| . o=+X=o .   .  |
+----[SHA256]-----+

I wonder if we need the ASCII art though or not the plain fingerprints only (first line of the command)

I think it should be included, its often used during generation in Debian among other distros.

One way to enhance it if the default would be to not show it would be to have it as available as a suboption, something like:

show ssh fingerprints
show ssh fingerprints <specific fingerprint>
show ssh fingerprints ascii
show ssh fingerprints ascii <specific fingerprint>

Specific fingerprint in this case is tha nem of the fingerprint such as this compared to previous example:

show ssh fingerprints root@debian

Wow - you guys work quickly! 👍

My very humble opinion would be that the basic version of this command should consider a first time user and that it should provide all the information that could be needed to connect so the user doesn't have to look further. If this is multiple fingerprints in multiple formats and they have to read, then so be it. I like the idea from @Apachez that this command also provides a meaningful 'hint' to the underlying source that aids learning.

Additional sub-commands are awesome and should target users who know what they are looking for. and want a filtered view.

Of course there is always a RTFM point of view (I was really impressed with the docs) so that would cover all bases.

I've updated this to default to no ASCII art as I think it's cleaner, but added an option to show it if you want to see it:

admin@vyos:~$ show ssh ?
Possible completions:
  fingerprints          Show SSH server public key fingerprints


admin@vyos:~$ show ssh fingerprints ?
Possible completions:
  <Enter>               Execute the current command
  ascii                 Show visual ASCII art representation of the public key


admin@vyos:~$ show ssh fingerprints
<output without ascii>

admin@vyos:~$ show ssh fingerprints ascii
<output with ascii>

As for breaking it down to be able to see specific fingerprints, I'm not sure if it's worth the effort as this is only showing the server public keys, not users. There should only be a few on any specific instance of Vyos.

On a side note, I'm new to contributing to Vyos (and open source in general). The getting started documentation is pretty decent and I didn't have too many hurdles after figuring out that vyos-1x gets built as a package. I appreciate the patience I've received with this and the other PR I did recently.

@JeffWDH I am happy to download, build and test when you're ready if you point me to the right version(s)/location(s). I'm also very new to this but I managed to Build Equuleus in a docker container which has been working ok. Appreciate your efforts.

@fsbof This change was accepted so it should end up in the 1.5 rolling soon. I suspect backporting to 1.4 wouldn't be an issue but that is a question for a more senior dev. But as for 1.3, I am unsure as I have never ran that version and don't know if there are any changes between those releases that would make it a pain to backport.

This functionality has also been backported to 1.4 so it will be in the next LTS release.

Removing 1.3 backport as it's not trivial. Implementation depends on python3-pyhump (not available and must be self build) and also on vyos.opmode framework which does not exist for 1.3 equuleus