SSH authenticity can't be established

AnArchUser123 · 2021-03-05 23:00:15

Did someone change with the recent openssh update? I tried connecting to my server today with my SSH key and I got:

The authenticity of host '[192.168.3.7]:26 ([192.168.3.7]:26)' can't be established.
ED25519 key fingerprint is SHA256:1PShljti5GRAOzeTv4UxUi5PpNcbUw2GSUagI7bjxgc.
This key is not known by any other names

I haven't changed anything on my server or removed anything for .ssh/known_hosts. I also have two entries in .ssh/known_hosts now:

192.168.3.7 ecdsa-sha2-nistp256

and

[192.168.3.7]:26 ssh-ed25519

Is this normal or am I being attacked?

respiranto · 2021-03-06 03:47:46

The two lines in your `known_hosts' are not necessarily related. One is for the default port, 22, the other for port 26.

Which command did you use to connect? If a Host/Match block in `/etc/ssh/ssh_config' or `.ssh/config' is relevant, please share it.

Did you use a different command earlier? Did you change a corresponding Host/Match block / anything else in your client ssh configuration?

AnArchUser123 · 2021-03-06 12:28:09

I'm using

ssh user@192.168.3.7 -p 26

but it seems to happen once regardless of which server I'm connecting to as it is complaining about the key. My other arch PC has shown the same message too which leads be to believe it has to do with the update.

For the Host/Match block do you mean this?

# Host *
#   ForwardAgent no
#   ForwardX11 no
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   IdentityFile ~/.ssh/id_ecdsa
#   IdentityFile ~/.ssh/id_ed25519
#   Port 22
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
#   MACs hmac-md5,hmac-sha1,umac-64@openssh.com
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
#   VisualHostKey no
#   ProxyCommand ssh -q -W %h:%p gateway.example.com
#   RekeyLimit 1G 1h
#   UserKnownHostsFile ~/.ssh/known_hosts.d/%k

I haven't modified any SSH config files.

seth · 2021-03-06 14:15:00

You're connecting to local server by IP and the system tells you that you've not connected to that server/IP before and that it's also not known by other names.
Since it's an IP and not a local domain: Did maybe simply the server IP change?

respiranto · 2021-03-06 14:29:06

Please post the output of

ssh-keygen -F '[192.168.3.7]:26'

If there is indeed an entry for `[192.168.3.7]:26' and you did not change the default configuration, then you should get a big warning upon connecting.

I suspect, however, the problem is rooted in the changed default order of `HostKeyAlgorithms'.

AnArchUser123 · 2021-03-06 14:33:00

seth wrote:

You're connecting to local server by IP and the system tells you that you've not connected to that server/IP before and that it's also not known by other names.
Since it's an IP and not a local domain: Did maybe simply the server IP change?

Nope the IP has always been the same.

respiranto wrote:

Please post the output of
ssh-keygen -F '[192.168.3.7]:26'
If there is indeed an entry for `[192.168.3.7]:26' and you did not change the default configuration, then you should get a big warning upon connecting.
I suspect, however, the problem is rooted in the changed default order of `HostKeyAlgorithms'.

Here is the output:

# Host [192.168.3.7]:26 found: line 19 
[192.168.3.7]:26 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJi19c6edXUuqsXYx03h793GgFbepjtxRG6kyAZmmtwG

I did read about something related to HostKeyAlgorithms in the changelog.

Interestingly if I run it on my other PC which also got the error, I get:

 Host [192.168.3.7]:26 found: line 8 
[192.168.3.7]:26 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCktJ2DU331E/+6DVLUcPNvp61XlHXGeu0+FdNO1fHia4ccGmh53GGSQoGo02Z5CxuGeJB6Wre76foAz5Ts3iBKSZfQ2NUarSrMO/nvHGCaSSm37cYvr7atdrnwl56z631/NQnb2c9dKJ8YLqkFUVI2nA/Zpkf9fDly0VutmztBWE/RG8fAR4gyT6/BN1AeQgyU0M874pke6nchkcFTp9UcWIAPp1s/gRpHacLaSAFdjHH2bQDPVij3PIWPY+sp1vLRngnQPdaxaP7dT7jF9OcWu3fPwcM52Vhl6cJ1FbagefoT3xCkwFMN7aI6watMV1Dp+qjD0W3rGVHvSDaBfNVp
# Host [192.168.3.7]:26 found: line 9 
[192.168.3.7]:26 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJi19c6edXUuqsXYx03h793GgFbepjtxRG6kyAZmmtwG

Last edited by AnArchUser123 (2021-03-06 14:37:21)

respiranto · 2021-03-06 14:48:47

If that's the case, connecting via `ssh -p 26 192.168.3.7' should fail with:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
[...]

If this is still not the case, please share the output of

ssh -vvv -p 26 192.168.3.7

On the two lines returned on your other machine: You might have set `UpdateHostKeys' there.

AnArchUser123 · 2021-03-06 14:53:40

Here is the output:

OpenSSH_8.5p1, OpenSSL 1.1.1j  16 Feb 2021
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: resolve_canonicalize: hostname 192.168.3.7 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/user/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/user/.ssh/known_hosts2'
debug3: ssh_connect_direct: entering
debug1: Connecting to 192.168.3.7 [192.168.3.7] port 26.
debug3: set_sock_tos: set socket 3 IP_TOS 0x48
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa type 0
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/user/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/user/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/user/.ssh/id_ed25519 type -1
debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
debug1: identity file /home/user/.ssh/id_ed25519_sk type -1
debug1: identity file /home/user/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/user/.ssh/id_xmss type -1
debug1: identity file /home/user/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.5
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9p1 Debian-10+deb10u2
debug1: compat_banner: match: OpenSSH_7.9p1 Debian-10+deb10u2 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.3.7:26 as 'user'
debug3: put_host_port: [192.168.3.7]:26
debug3: record_hostkey: found key type ED25519 in file /home/user/.ssh/known_hosts:19
debug3: load_hostkeys_file: loaded 1 keys from [192.168.3.7]:26
debug1: load_hostkeys: fopen /home/user/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug3: order_hostkeyalgs: have matching best-preference key type ssh-ed25519-cert-v01@openssh.com, using HostkeyAlgorithms verbatim
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c
debug2: host key algorithms: ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:1PShljti5GRAOzeTv4UxUi5PpNcbUw2GSUagI7bjxgc
debug3: put_host_port: [192.168.3.7]:26
debug3: put_host_port: [192.168.3.7]:26
debug3: record_hostkey: found key type ED25519 in file /home/user/.ssh/known_hosts:19
debug3: load_hostkeys_file: loaded 1 keys from [192.168.3.7]:26
debug1: load_hostkeys: fopen /home/user/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host '[192.168.3.7]:26' is known and matches the ED25519 host key.
debug1: Found key in /home/user/.ssh/known_hosts:19
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /home/user/.ssh/id_rsa RSA SHA256:NQLB1+OBiHqeQKF9B8BRPh+HW8mJJ6Rhpqx48Duk+ro
debug1: Will attempt key: /home/user/.ssh/id_dsa 
debug1: Will attempt key: /home/user/.ssh/id_ecdsa 
debug1: Will attempt key: /home/user/.ssh/id_ecdsa_sk 
debug1: Will attempt key: /home/user/.ssh/id_ed25519 
debug1: Will attempt key: /home/user/.ssh/id_ed25519_sk 
debug1: Will attempt key: /home/user/.ssh/id_xmss 
debug2: pubkey_prepare: done
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_rsa RSA SHA256:NQLB1+OBiHqeQKF9B8BRPh+HW8mJJ6Rhpqx48Duk+ro
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: /home/user/.ssh/id_rsa RSA SHA256:NQLB1+OBiHqeQKF9B8BRPh+HW8mJJ6Rhpqx48Duk+ro
debug3: sign_and_send_pubkey: RSA SHA256:NQLB1+OBiHqeQKF9B8BRPh+HW8mJJ6Rhpqx48Duk+ro
debug3: sign_and_send_pubkey: signing using rsa-sha2-512 SHA256:NQLB1+OBiHqeQKF9B8BRPh+HW8mJJ6Rhpqx48Duk+ro
Enter passphrase for key '/home/user/.ssh/id_rsa': 
debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.3.7 ([192.168.3.7]:26).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: filesystem full
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug3: client_input_hostkeys: received RSA key SHA256:UULR4qWuMxQvi1JClEl9pvJWOncNXTDGPRFsJpOisEg
debug3: client_input_hostkeys: received ECDSA key SHA256:DvmsQEmlA+Go4sdOt1JhGfgxWMyy4bZZTTZU3FvgR68
debug3: client_input_hostkeys: received ED25519 key SHA256:1PShljti5GRAOzeTv4UxUi5PpNcbUw2GSUagI7bjxgc
debug3: put_host_port: [192.168.3.7]:26
debug1: client_input_hostkeys: searching /home/user/.ssh/known_hosts for [192.168.3.7]:26 / (none)
debug3: hostkeys_foreach: reading file "/home/user/.ssh/known_hosts"
debug3: hostkeys_find: found ecdsa-sha2-nistp256 key under different name/addr at /home/user/.ssh/known_hosts:11
debug3: hostkeys_find: found ssh-ed25519 key at /home/user/.ssh/known_hosts:19
debug1: client_input_hostkeys: searching /home/user/.ssh/known_hosts2 for [192.168.3.7]:26 / (none)
debug1: client_input_hostkeys: hostkeys file /home/user/.ssh/known_hosts2 does not exist
debug3: client_input_hostkeys: 3 server keys: 2 new, 18446744073709551615 retained, 2 incomplete match. 0 to remove
debug1: client_input_hostkeys: host key found matching a different name/address, skipping UserKnownHostsFile update
debug3: receive packet: type 4
debug1: Remote: /home/user/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug3: receive packet: type 4
debug1: Remote: /home/user/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: set_sock_tos: set socket 3 IP_TOS 0x48
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0

At the start I got:

The authenticity of host '[192.168.3.7]:26 ([192.168.3.7]:26)' can't be established.
ED25519 key fingerprint is SHA256:1PShljti5GRAOzeTv4UxUi5PpNcbUw2GSUagI7bjxgc.
This key is not known by any other names

I then got the option to type yes or no to connect I never got the message: WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

respiranto · 2021-03-06 15:17:31

Oh, I forgot that the known_hosts file contains the base64 encoded public key, not the sha256 hash, which naturally differs.

Anyways, the connection succeeds now. So you typed "yes" back then. I'd have advised against that.

So it looks like you never connected before to `[192.168.3.7]:26'. Otherwise, you must have deleted the corresponding line from `known_hosts' somehow. You could search in your backup for such a line.

Unless there is another server running at port 22, I suggest

ssh -o HostKeyAlgorithms=ecdsa-sha2-nistp256 -o HostKeyAlias=192.168.3.7 -p 26 192.168.3.7

AnArchUser123 · 2021-03-06 15:24:24

I see thanks for your help. I'm pretty sure I didn't remove the line from two PCs and have connected to it which was why I made the post. However I also got this message connecting to another host which means you are probably right that a default has changed somewhere since the update.

george55 · 2021-03-08 08:41:47

Same thing happened my side. Suddenly all servers I had already fingerprinted were not recognized anymore. Seeing that others have the same problem after the recent updates makes me assume that this is a software-update issue, not an actual change on the servers or anything malicious happening.

respiranto · 2021-03-08 21:41:18

So you did not get a big warning either?

This is what I would expect as result of a software update that presumably changed the default order of `HostKeyAlgorithms'. In this case, you could easily verify the authenticity of the remote host using the previously preferred host key explicitly (and verify the newly preferred key, e.g., using `UpdateHostKeys').

If that is not the case, however, inspect your known_hosts files and, if these mysteriously lack information, consult your backups.

gjasso · 2021-03-09 07:16:22

I had the same issue with three different servers this morning. As respiranto suggests, this seems to be related to an update in the request order of the encryption algorithm used by the host key. The keys I have logged in my `~/.ssh/known_hosts` file all use `ecdsa-sha2-nistp256` while the new keys being sent by the server use `ed25519`.

I verified the fingerprints of all "new" (ed25519) public keys by login into each VPS via a remote console (through the portal of my service provider) and running:

$ ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

You can also verify the fingerprints of other keys you may have saved to verify that none of them have been manipulated.

respiranto · 2021-03-09 07:47:23

You could also have done:

ssh -o HostKeyAlgorithms=ecdsa-sha2-nistp256,ed25519 -o UpdateHostKeys=yes host

Actually, one may omit setting UpdateHostkeys, as it seems to have been enabled by default in presumably the same version in which HostKeyAlgorithms changed. Possibly a reaction.

HCF · 2021-03-09 22:20:32

Same issue here--gave me quite the initial scare.

I 'fixed' this by adding

HostKeyAlgorithms ecdsa-sha2-nistp256

to each entry in my

~/.ssh/config

As stated in one of the earlier posts, there seems to have been a defaults change from ecdsa-sha2-nistp256 to ssh-ed25519.

Last edited by HCF (2021-03-09 22:22:56)

respiranto · 2021-03-10 21:36:20

I would advise against changing that default permanently (to `ecdsa-...'; even if only for known hosts).

You might want to read the Wiki on ECDSA keys.

Irrespective of the current issue, I'd actually recommend modifying `HostKeyAlgorithms' globally. In particular, removing `ssh-rsa', which is to be deprecated in OpenSSH, due to relying on SHA-1 which is affordably broken.

Arch Linux

#1 2021-03-05 23:00:15

SSH authenticity can't be established

#2 2021-03-06 03:47:46

Re: SSH authenticity can't be established

#3 2021-03-06 12:28:09

Re: SSH authenticity can't be established

#4 2021-03-06 14:15:00

Re: SSH authenticity can't be established

#5 2021-03-06 14:29:06

Re: SSH authenticity can't be established

#6 2021-03-06 14:33:00

Re: SSH authenticity can't be established

#7 2021-03-06 14:48:47

Re: SSH authenticity can't be established

#8 2021-03-06 14:53:40

Re: SSH authenticity can't be established

#9 2021-03-06 15:17:31

Re: SSH authenticity can't be established

#10 2021-03-06 15:24:24

Re: SSH authenticity can't be established

#11 2021-03-08 08:41:47

Re: SSH authenticity can't be established

#12 2021-03-08 21:41:18

Re: SSH authenticity can't be established

#13 2021-03-09 07:16:22

Re: SSH authenticity can't be established

#14 2021-03-09 07:47:23

Re: SSH authenticity can't be established

#15 2021-03-09 22:20:32

Re: SSH authenticity can't be established

#16 2021-03-10 21:36:20

Re: SSH authenticity can't be established

Board footer