ssh_config visual host key (yes no) option
![Creative The name of the picture](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgO9GURib1T8z7lCwjOGLQaGtrueEthgQ8LO42ZX8cOfTqDK4jvDDpKkLFwf2J49kYCMNW7d4ABih_XCb_2UXdq5fPJDkoyg7-8g_YfRUot-XnaXkNYycsNp7lA5_TW9td0FFpLQ2APzKcZ/s1600/1.jpg)
![Creative The name of the picture](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYQ0N5W1qAOxLP7t7iOM6O6AzbZnkXUy16s7P_CWfOb5UbTQY_aDsc727chyphenhyphen5W4IppVNernMMQeaUFTB_rFzAd95_CDt-tnwN-nBx6JyUp2duGjPaL5-VgNO41AVsA_vu30EJcipdDG409/s400/Clash+Royale+CLAN+TAG%2523URR8PPP.png)
up vote
0
down vote
favorite
/etc/ssh/ssh_config
has ssh_visual host key no
option. What what does it do?
Edited: Indeed, Visual, not virtual. Still, what is it controlling?
ssh
add a comment |Â
up vote
0
down vote
favorite
/etc/ssh/ssh_config
has ssh_visual host key no
option. What what does it do?
Edited: Indeed, Visual, not virtual. Still, what is it controlling?
ssh
Are you sure you're not misreading VisualHostKey?
â steeldriver
Apr 26 at 14:41
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
/etc/ssh/ssh_config
has ssh_visual host key no
option. What what does it do?
Edited: Indeed, Visual, not virtual. Still, what is it controlling?
ssh
/etc/ssh/ssh_config
has ssh_visual host key no
option. What what does it do?
Edited: Indeed, Visual, not virtual. Still, what is it controlling?
ssh
edited May 1 at 14:59
asked Apr 26 at 14:37
sixtytrees
1764
1764
Are you sure you're not misreading VisualHostKey?
â steeldriver
Apr 26 at 14:41
add a comment |Â
Are you sure you're not misreading VisualHostKey?
â steeldriver
Apr 26 at 14:41
Are you sure you're not misreading VisualHostKey?
â steeldriver
Apr 26 at 14:41
Are you sure you're not misreading VisualHostKey?
â steeldriver
Apr 26 at 14:41
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
2
down vote
See man ssh_config:
VisualHostKey
If this flag is set to yes, an ASCII art representation
of the remote host key fingerprint is printed in addition
to the fingerprint string at login and for unknown host keys.
If this flag is set to no (the default), no fingerâÂÂprint
strings are printed at login and only the fingerprint string
will be printed for unknown host keys.
add a comment |Â
up vote
2
down vote
Firsly, consider that /etc/ssh/ssh_config
is the SSH client config system-wide. This means that any time you ssh
from your computer to remote servers, this config comes into play.
By default, when you connect to a server for the first time, the system asks you to state whether the SSH fingerprint from the remote server is 'expected' or not, so you can verify whether the server is actually legitimate or not (the server admin can tell you what the server's fingerprint is, and you verify what you see in the SSH client against what they tell you). Most end-users aren't going to go character by character to verify the fingerprint themselves.
However, there's an extra component that we see with key gen that we don't by default see with SSH fingerprint verification. It's called 'random art', and each key/fingerprint should have a unique random art.
Consider this key I just generated, for a 'bogus' key of course, within a bionic container. It shows us a randomart and the fingerprint:
The key fingerprint is:
SHA256:xtaA8biLm/Jktn9A/j2sty686uosrRtz0GQIFw6nP2s root@bionic
The key's randomart image is:
+---[RSA 4096]----+
|o +. . |
| B . = |
|. o o o o |
| . + .o o |
| + .o. S . |
| + .o+ |
| E.* .+ o |
| .oO.+ = = |
| oBO++oo*oo |
+----[SHA256]-----+
The idea behind the Visual Image of the host key is that the end-user is probably not going to go character by character to verify the fingerprint, and will only rely on the first several and last several characters as the 'skim' the fingerprint. And in fact, because of this, threat actors might try to 'impersonate' by generating keys which are matching the first several and last several characters in the fingerprint, to "trick" people since they aren't likely to do character-by-character fingerprint verifications.
This is where the Random Art piece comes into play - different keys, even if they have the same 'first' and 'last' bits will have different randomart for different keys, which a standard user would be able to spot as a substantial difference (which wouldn't be spotted on a key itself unless they do character-by-character fingerprint identification/comparison)
By default, the SSH client does not show the randomart of remote keys (the VisualHostKey no
setting that's the default). However, if you set VisualHostKey
to yes
and uncomment that line in the config file, then the system will also show you the randomart of the remote key to help users 'verify' the server fingerprint is valid.
First, an example without VisualHostKey
set to on
:
$ ssh -p 22 teward@10.73.250.210
The authenticity of host '10.73.250.210 (10.73.250.210)' can't be established.
ECDSA key fingerprint is SHA256:ZDA6BYWGmr0ftUqQxCu1CsaonKqKKUM3fbMzKUlMorE.
Are you sure you want to continue connecting (yes/no)?
and now the same prompt but with the randomart shown (VisualHostKey yes
):
$ ssh -p 22 teward@10.73.250.210
The authenticity of host '10.73.250.210 (10.73.250.210)' can't be established.
ECDSA key fingerprint is SHA256:ZDA6BYWGmr0ftUqQxCu1CsaonKqKKUM3fbMzKUlMorE.
+---[ECDSA 256]---+
| . ..+= |
| = oo o |
|o* =o o |
|*+*. o.o |
|=o=o=. .S |
|oE.oo+.o |
|o .oooo + |
|=. oo = |
|O. . o |
+----[SHA256]-----+
Are you sure you want to continue connecting (yes/no)?
Much easier to determine the randomart of a server being 'valid' versus instead the text representation of the fingerprint, no?
(Note that this is the 'long' description of what the manpage is stating about that config option, and is probably more easy to understand with visual examples, and such, than the dry manpage explanation)
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
See man ssh_config:
VisualHostKey
If this flag is set to yes, an ASCII art representation
of the remote host key fingerprint is printed in addition
to the fingerprint string at login and for unknown host keys.
If this flag is set to no (the default), no fingerâÂÂprint
strings are printed at login and only the fingerprint string
will be printed for unknown host keys.
add a comment |Â
up vote
2
down vote
See man ssh_config:
VisualHostKey
If this flag is set to yes, an ASCII art representation
of the remote host key fingerprint is printed in addition
to the fingerprint string at login and for unknown host keys.
If this flag is set to no (the default), no fingerâÂÂprint
strings are printed at login and only the fingerprint string
will be printed for unknown host keys.
add a comment |Â
up vote
2
down vote
up vote
2
down vote
See man ssh_config:
VisualHostKey
If this flag is set to yes, an ASCII art representation
of the remote host key fingerprint is printed in addition
to the fingerprint string at login and for unknown host keys.
If this flag is set to no (the default), no fingerâÂÂprint
strings are printed at login and only the fingerprint string
will be printed for unknown host keys.
See man ssh_config:
VisualHostKey
If this flag is set to yes, an ASCII art representation
of the remote host key fingerprint is printed in addition
to the fingerprint string at login and for unknown host keys.
If this flag is set to no (the default), no fingerâÂÂprint
strings are printed at login and only the fingerprint string
will be printed for unknown host keys.
answered May 1 at 15:06
![](https://i.stack.imgur.com/kCmqs.png?s=32&g=1)
![](https://i.stack.imgur.com/kCmqs.png?s=32&g=1)
PerlDuck
3,72511030
3,72511030
add a comment |Â
add a comment |Â
up vote
2
down vote
Firsly, consider that /etc/ssh/ssh_config
is the SSH client config system-wide. This means that any time you ssh
from your computer to remote servers, this config comes into play.
By default, when you connect to a server for the first time, the system asks you to state whether the SSH fingerprint from the remote server is 'expected' or not, so you can verify whether the server is actually legitimate or not (the server admin can tell you what the server's fingerprint is, and you verify what you see in the SSH client against what they tell you). Most end-users aren't going to go character by character to verify the fingerprint themselves.
However, there's an extra component that we see with key gen that we don't by default see with SSH fingerprint verification. It's called 'random art', and each key/fingerprint should have a unique random art.
Consider this key I just generated, for a 'bogus' key of course, within a bionic container. It shows us a randomart and the fingerprint:
The key fingerprint is:
SHA256:xtaA8biLm/Jktn9A/j2sty686uosrRtz0GQIFw6nP2s root@bionic
The key's randomart image is:
+---[RSA 4096]----+
|o +. . |
| B . = |
|. o o o o |
| . + .o o |
| + .o. S . |
| + .o+ |
| E.* .+ o |
| .oO.+ = = |
| oBO++oo*oo |
+----[SHA256]-----+
The idea behind the Visual Image of the host key is that the end-user is probably not going to go character by character to verify the fingerprint, and will only rely on the first several and last several characters as the 'skim' the fingerprint. And in fact, because of this, threat actors might try to 'impersonate' by generating keys which are matching the first several and last several characters in the fingerprint, to "trick" people since they aren't likely to do character-by-character fingerprint verifications.
This is where the Random Art piece comes into play - different keys, even if they have the same 'first' and 'last' bits will have different randomart for different keys, which a standard user would be able to spot as a substantial difference (which wouldn't be spotted on a key itself unless they do character-by-character fingerprint identification/comparison)
By default, the SSH client does not show the randomart of remote keys (the VisualHostKey no
setting that's the default). However, if you set VisualHostKey
to yes
and uncomment that line in the config file, then the system will also show you the randomart of the remote key to help users 'verify' the server fingerprint is valid.
First, an example without VisualHostKey
set to on
:
$ ssh -p 22 teward@10.73.250.210
The authenticity of host '10.73.250.210 (10.73.250.210)' can't be established.
ECDSA key fingerprint is SHA256:ZDA6BYWGmr0ftUqQxCu1CsaonKqKKUM3fbMzKUlMorE.
Are you sure you want to continue connecting (yes/no)?
and now the same prompt but with the randomart shown (VisualHostKey yes
):
$ ssh -p 22 teward@10.73.250.210
The authenticity of host '10.73.250.210 (10.73.250.210)' can't be established.
ECDSA key fingerprint is SHA256:ZDA6BYWGmr0ftUqQxCu1CsaonKqKKUM3fbMzKUlMorE.
+---[ECDSA 256]---+
| . ..+= |
| = oo o |
|o* =o o |
|*+*. o.o |
|=o=o=. .S |
|oE.oo+.o |
|o .oooo + |
|=. oo = |
|O. . o |
+----[SHA256]-----+
Are you sure you want to continue connecting (yes/no)?
Much easier to determine the randomart of a server being 'valid' versus instead the text representation of the fingerprint, no?
(Note that this is the 'long' description of what the manpage is stating about that config option, and is probably more easy to understand with visual examples, and such, than the dry manpage explanation)
add a comment |Â
up vote
2
down vote
Firsly, consider that /etc/ssh/ssh_config
is the SSH client config system-wide. This means that any time you ssh
from your computer to remote servers, this config comes into play.
By default, when you connect to a server for the first time, the system asks you to state whether the SSH fingerprint from the remote server is 'expected' or not, so you can verify whether the server is actually legitimate or not (the server admin can tell you what the server's fingerprint is, and you verify what you see in the SSH client against what they tell you). Most end-users aren't going to go character by character to verify the fingerprint themselves.
However, there's an extra component that we see with key gen that we don't by default see with SSH fingerprint verification. It's called 'random art', and each key/fingerprint should have a unique random art.
Consider this key I just generated, for a 'bogus' key of course, within a bionic container. It shows us a randomart and the fingerprint:
The key fingerprint is:
SHA256:xtaA8biLm/Jktn9A/j2sty686uosrRtz0GQIFw6nP2s root@bionic
The key's randomart image is:
+---[RSA 4096]----+
|o +. . |
| B . = |
|. o o o o |
| . + .o o |
| + .o. S . |
| + .o+ |
| E.* .+ o |
| .oO.+ = = |
| oBO++oo*oo |
+----[SHA256]-----+
The idea behind the Visual Image of the host key is that the end-user is probably not going to go character by character to verify the fingerprint, and will only rely on the first several and last several characters as the 'skim' the fingerprint. And in fact, because of this, threat actors might try to 'impersonate' by generating keys which are matching the first several and last several characters in the fingerprint, to "trick" people since they aren't likely to do character-by-character fingerprint verifications.
This is where the Random Art piece comes into play - different keys, even if they have the same 'first' and 'last' bits will have different randomart for different keys, which a standard user would be able to spot as a substantial difference (which wouldn't be spotted on a key itself unless they do character-by-character fingerprint identification/comparison)
By default, the SSH client does not show the randomart of remote keys (the VisualHostKey no
setting that's the default). However, if you set VisualHostKey
to yes
and uncomment that line in the config file, then the system will also show you the randomart of the remote key to help users 'verify' the server fingerprint is valid.
First, an example without VisualHostKey
set to on
:
$ ssh -p 22 teward@10.73.250.210
The authenticity of host '10.73.250.210 (10.73.250.210)' can't be established.
ECDSA key fingerprint is SHA256:ZDA6BYWGmr0ftUqQxCu1CsaonKqKKUM3fbMzKUlMorE.
Are you sure you want to continue connecting (yes/no)?
and now the same prompt but with the randomart shown (VisualHostKey yes
):
$ ssh -p 22 teward@10.73.250.210
The authenticity of host '10.73.250.210 (10.73.250.210)' can't be established.
ECDSA key fingerprint is SHA256:ZDA6BYWGmr0ftUqQxCu1CsaonKqKKUM3fbMzKUlMorE.
+---[ECDSA 256]---+
| . ..+= |
| = oo o |
|o* =o o |
|*+*. o.o |
|=o=o=. .S |
|oE.oo+.o |
|o .oooo + |
|=. oo = |
|O. . o |
+----[SHA256]-----+
Are you sure you want to continue connecting (yes/no)?
Much easier to determine the randomart of a server being 'valid' versus instead the text representation of the fingerprint, no?
(Note that this is the 'long' description of what the manpage is stating about that config option, and is probably more easy to understand with visual examples, and such, than the dry manpage explanation)
add a comment |Â
up vote
2
down vote
up vote
2
down vote
Firsly, consider that /etc/ssh/ssh_config
is the SSH client config system-wide. This means that any time you ssh
from your computer to remote servers, this config comes into play.
By default, when you connect to a server for the first time, the system asks you to state whether the SSH fingerprint from the remote server is 'expected' or not, so you can verify whether the server is actually legitimate or not (the server admin can tell you what the server's fingerprint is, and you verify what you see in the SSH client against what they tell you). Most end-users aren't going to go character by character to verify the fingerprint themselves.
However, there's an extra component that we see with key gen that we don't by default see with SSH fingerprint verification. It's called 'random art', and each key/fingerprint should have a unique random art.
Consider this key I just generated, for a 'bogus' key of course, within a bionic container. It shows us a randomart and the fingerprint:
The key fingerprint is:
SHA256:xtaA8biLm/Jktn9A/j2sty686uosrRtz0GQIFw6nP2s root@bionic
The key's randomart image is:
+---[RSA 4096]----+
|o +. . |
| B . = |
|. o o o o |
| . + .o o |
| + .o. S . |
| + .o+ |
| E.* .+ o |
| .oO.+ = = |
| oBO++oo*oo |
+----[SHA256]-----+
The idea behind the Visual Image of the host key is that the end-user is probably not going to go character by character to verify the fingerprint, and will only rely on the first several and last several characters as the 'skim' the fingerprint. And in fact, because of this, threat actors might try to 'impersonate' by generating keys which are matching the first several and last several characters in the fingerprint, to "trick" people since they aren't likely to do character-by-character fingerprint verifications.
This is where the Random Art piece comes into play - different keys, even if they have the same 'first' and 'last' bits will have different randomart for different keys, which a standard user would be able to spot as a substantial difference (which wouldn't be spotted on a key itself unless they do character-by-character fingerprint identification/comparison)
By default, the SSH client does not show the randomart of remote keys (the VisualHostKey no
setting that's the default). However, if you set VisualHostKey
to yes
and uncomment that line in the config file, then the system will also show you the randomart of the remote key to help users 'verify' the server fingerprint is valid.
First, an example without VisualHostKey
set to on
:
$ ssh -p 22 teward@10.73.250.210
The authenticity of host '10.73.250.210 (10.73.250.210)' can't be established.
ECDSA key fingerprint is SHA256:ZDA6BYWGmr0ftUqQxCu1CsaonKqKKUM3fbMzKUlMorE.
Are you sure you want to continue connecting (yes/no)?
and now the same prompt but with the randomart shown (VisualHostKey yes
):
$ ssh -p 22 teward@10.73.250.210
The authenticity of host '10.73.250.210 (10.73.250.210)' can't be established.
ECDSA key fingerprint is SHA256:ZDA6BYWGmr0ftUqQxCu1CsaonKqKKUM3fbMzKUlMorE.
+---[ECDSA 256]---+
| . ..+= |
| = oo o |
|o* =o o |
|*+*. o.o |
|=o=o=. .S |
|oE.oo+.o |
|o .oooo + |
|=. oo = |
|O. . o |
+----[SHA256]-----+
Are you sure you want to continue connecting (yes/no)?
Much easier to determine the randomart of a server being 'valid' versus instead the text representation of the fingerprint, no?
(Note that this is the 'long' description of what the manpage is stating about that config option, and is probably more easy to understand with visual examples, and such, than the dry manpage explanation)
Firsly, consider that /etc/ssh/ssh_config
is the SSH client config system-wide. This means that any time you ssh
from your computer to remote servers, this config comes into play.
By default, when you connect to a server for the first time, the system asks you to state whether the SSH fingerprint from the remote server is 'expected' or not, so you can verify whether the server is actually legitimate or not (the server admin can tell you what the server's fingerprint is, and you verify what you see in the SSH client against what they tell you). Most end-users aren't going to go character by character to verify the fingerprint themselves.
However, there's an extra component that we see with key gen that we don't by default see with SSH fingerprint verification. It's called 'random art', and each key/fingerprint should have a unique random art.
Consider this key I just generated, for a 'bogus' key of course, within a bionic container. It shows us a randomart and the fingerprint:
The key fingerprint is:
SHA256:xtaA8biLm/Jktn9A/j2sty686uosrRtz0GQIFw6nP2s root@bionic
The key's randomart image is:
+---[RSA 4096]----+
|o +. . |
| B . = |
|. o o o o |
| . + .o o |
| + .o. S . |
| + .o+ |
| E.* .+ o |
| .oO.+ = = |
| oBO++oo*oo |
+----[SHA256]-----+
The idea behind the Visual Image of the host key is that the end-user is probably not going to go character by character to verify the fingerprint, and will only rely on the first several and last several characters as the 'skim' the fingerprint. And in fact, because of this, threat actors might try to 'impersonate' by generating keys which are matching the first several and last several characters in the fingerprint, to "trick" people since they aren't likely to do character-by-character fingerprint verifications.
This is where the Random Art piece comes into play - different keys, even if they have the same 'first' and 'last' bits will have different randomart for different keys, which a standard user would be able to spot as a substantial difference (which wouldn't be spotted on a key itself unless they do character-by-character fingerprint identification/comparison)
By default, the SSH client does not show the randomart of remote keys (the VisualHostKey no
setting that's the default). However, if you set VisualHostKey
to yes
and uncomment that line in the config file, then the system will also show you the randomart of the remote key to help users 'verify' the server fingerprint is valid.
First, an example without VisualHostKey
set to on
:
$ ssh -p 22 teward@10.73.250.210
The authenticity of host '10.73.250.210 (10.73.250.210)' can't be established.
ECDSA key fingerprint is SHA256:ZDA6BYWGmr0ftUqQxCu1CsaonKqKKUM3fbMzKUlMorE.
Are you sure you want to continue connecting (yes/no)?
and now the same prompt but with the randomart shown (VisualHostKey yes
):
$ ssh -p 22 teward@10.73.250.210
The authenticity of host '10.73.250.210 (10.73.250.210)' can't be established.
ECDSA key fingerprint is SHA256:ZDA6BYWGmr0ftUqQxCu1CsaonKqKKUM3fbMzKUlMorE.
+---[ECDSA 256]---+
| . ..+= |
| = oo o |
|o* =o o |
|*+*. o.o |
|=o=o=. .S |
|oE.oo+.o |
|o .oooo + |
|=. oo = |
|O. . o |
+----[SHA256]-----+
Are you sure you want to continue connecting (yes/no)?
Much easier to determine the randomart of a server being 'valid' versus instead the text representation of the fingerprint, no?
(Note that this is the 'long' description of what the manpage is stating about that config option, and is probably more easy to understand with visual examples, and such, than the dry manpage explanation)
edited May 1 at 15:18
answered May 1 at 15:12
![](https://i.stack.imgur.com/jLgkr.jpg?s=32&g=1)
![](https://i.stack.imgur.com/jLgkr.jpg?s=32&g=1)
Thomas Wardâ¦
41.3k23112166
41.3k23112166
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1028439%2fssh-config-visual-host-key-yes-no-option%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Are you sure you're not misreading VisualHostKey?
â steeldriver
Apr 26 at 14:41