Load key error in libcrypto

ssh: Error loading key «./id_rsa»: invalid format

For some reason one of my ssh keys «just broke» — it just stopped working:

Copying the key inside a clean VM, the key does work. Even with the exact same ssh version (OpenSSH_7.8p1, OpenSSL 1.1.0i-fips 14 Aug 2018 on Fedora 28). So it must be related to some config on my system I assume.

Also peculiar: GNOME somehow manages to add the key on login with seahorse. Then ssh-add -L does list the key but it is not usable:

8 Answers 8

Traditionally OpenSSH used the same private key format is identical to the older PEM format used by OpenSSL. (Because it uses OpenSSL for parsing the key, it will accept the newer PKCS#8 format as well.)

So the issue can be one of:

Your OpenSSL version refuses to load this key format. Perhaps it has accidentally enabled FIPS mode and refuses any algorithms except those part of its original FIPS validation?

Try loading the key into the openssl command-line tool (which, yes, might also be linked to a different libcrypto, and you should check with ldd):

Try converting it to PKCS#8 format:

Your OpenSSH has been built without OpenSSL support. Even though ssh -V says the support was enabled, that does not automatically mean the ssh-add binary is the same – it might come from a different partial installation.

Use type -a ssh and type -a ssh-add to compare installation locations.

Once you know the path, use ldd /usr/bin/ssh-add to verify that it’s linked to libcrypto.so (the OpenSSL cryptographic library).

If nothing works at all, try converting your key to the new OpenSSH-proprietary format using. PuTTY. Install the putty package for Fedora, and use:

Also peculiar: GNOME somehow manages to add the key on login with seahorse.

Older GNOME Keyring versions have an internal copy of the SSH agent code and are independent from the system OpenSSH. So they will accept keys that your OpenSSH won’t. (But on the other hand, this means severe lagging in terms of feature support (such as Ed25519 keys), and the latest GNOME Keyring just uses the system ssh-agent instead.)

Источник

ssh failed on almaLinux 9 with openssl 3.0.1 (error in libcrypto) #18420

I installed almaLinux 9.0 recently,
and when I try to ssh my company’s server, it failed:

/.ssh/known_hosts2′ -> ‘/home/gxl/.ssh/known_hosts2’ debug3: ssh_connect_direct: entering debug1: Connecting to 192.168.1.100 [192.168.1.100] port 32200. debug3: set_sock_tos: set socket 3 IP_TOS 0x48 debug1: Connection established. debug1: identity file /home/gxl/.ssh/id_rsa type -1 debug1: identity file /home/gxl/.ssh/id_rsa-cert type -1 debug1: identity file /home/gxl/.ssh/id_dsa type -1 debug1: identity file /home/gxl/.ssh/id_dsa-cert type -1 debug1: identity file /home/gxl/.ssh/id_ecdsa type -1 debug1: identity file /home/gxl/.ssh/id_ecdsa-cert type -1 debug1: identity file /home/gxl/.ssh/id_ecdsa_sk type -1 debug1: identity file /home/gxl/.ssh/id_ecdsa_sk-cert type -1 debug1: identity file /home/gxl/.ssh/id_ed25519 type -1 debug1: identity file /home/gxl/.ssh/id_ed25519-cert type -1 debug1: identity file /home/gxl/.ssh/id_ed25519_sk type -1 debug1: identity file /home/gxl/.ssh/id_ed25519_sk-cert type -1 debug1: identity file /home/gxl/.ssh/id_xmss type -1 debug1: identity file /home/gxl/.ssh/id_xmss-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_8.7 debug1: Remote protocol version 2.0, remote software version SSHD_0.7.6 debug1: compat_banner: no match: SSHD_0.7.6 debug2: fd 3 setting O_NONBLOCK debug1: Authenticating to 192.168.1.100:32200 as ‘jasonguo’ debug3: put_host_port: [192.168.1.100]:32200 debug3: record_hostkey: found key type RSA in file /home/gxl/.ssh/known_hosts:1 debug3: load_hostkeys_file: loaded 1 keys from [192.168.1.100]:32200 debug1: load_hostkeys: fopen /home/gxl/.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: prefer hostkeyalgs: rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa 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-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,ext-info-c debug2: host key algorithms: rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa,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,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com debug2: ciphers ctos: aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr debug2: ciphers stoc: aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr debug2: MACs ctos: hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha1,umac-128@openssh.com,hmac-sha2-512 debug2: MACs stoc: hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha1,umac-128@openssh.com,hmac-sha2-512 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: ecdh-sha2-nistp256,diffie-hellman-group14-sha1 debug2: host key algorithms: ssh-dss,ssh-rsa debug2: ciphers ctos: aes256-ctr,aes192-ctr,aes128-ctr debug2: ciphers stoc: aes256-ctr,aes192-ctr,aes128-ctr debug2: MACs ctos: hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: MACs stoc: hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: compression ctos: none,zlib,zlib@openssh.com debug2: compression stoc: none,zlib,zlib@openssh.com debug2: languages ctos: debug2: languages stoc: debug2: first_kex_follows 0 debug2: reserved 0 debug1: kex: algorithm: ecdh-sha2-nistp256 debug1: kex: host key algorithm: ssh-rsa debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha2-256 compression: none debug1: kex: client->server cipher: aes256-ctr MAC: hmac-sha2-256 compression: none debug1: kex: ecdh-sha2-nistp256 need=32 dh_need=32 debug1: kex: ecdh-sha2-nistp256 need=32 dh_need=32 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-rsa SHA256:6d1FhDGSnk4bXhMpQfD+KYkn6oGjQaLwdzPjQ7fJFss debug3: put_host_port: [192.168.1.100]:32200 debug3: put_host_port: [192.168.1.100]:32200 debug3: record_hostkey: found key type RSA in file /home/gxl/.ssh/known_hosts:1 debug3: load_hostkeys_file: loaded 1 keys from [192.168.1.100]:32200 debug1: load_hostkeys: fopen /home/gxl/.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.1.100]:32200’ is known and matches the RSA host key. debug1: Found key in /home/gxl/.ssh/known_hosts:1 **ssh_dispatch_run_fatal: Connection to 192.168.1.100 port 32200: error in libcrypto**»>

I don’t know why, and it’s okay when I use centos 7 or almaLinux 8

The text was updated successfully, but these errors were encountered:

Источник

Regarding «error in libcrypto» #522

Dear experts,
I have a landscape as below:
SFTP server with OpenSSH, a client PC to connect to it using public key. After connection is made, it will execute some scripts for business purposes.

The connection is, to be honest, usually smooth. But in some random days, it gives me the message:
fatal: ssh_dispatch_run_fatal: Connection to [client IP address]: error in libcrypto

I have been searching all over the web but no solution so far. I used version 5_30_2016 which I found (maybe) relating to issue #106 and #169. Then upgraded to 0.0.8.0 waiting for some magic but no luck.
Both client and server are running Windows Server. I also checked with network provider, uptime is 99.9% so I think it’s not the reason.

The text was updated successfully, but these errors were encountered:

can you please share the verbose logs at client side and debug3 of sshd.log (this can be set in the ssh_config)

Hi, thanks for your reply.
Due to security policies, I don’t have permission to collect debug3 log.
I’m running debug2. But the error still haven’t occured for several days, nothing to collect. I’ll keep monitor and will update debug2 log.
Please don’t close this post.

Ok.. I am marking it as issue-discussion till we get the issue reproduced.

@bagajjal
Please see sshd.log file, the error occured yesterday.
sshd.log.txt

Network team is monitoring and tell me that Diffie-Hellman Key Exchange Reply packet is missing during connection establishment. We have Diffie-Hellman Key Exchange Init but no Reply.
Hope it can help. Thanks

sorry but beside that, I also encounter some disconnections 3 minutes after connection is successfully established.
In sshd_config, I set these parameters:

So I wonder if these are the reason.
Everything is so random so I can’t make sure, just guess

The clientAlive configuration makes the connection to disconnect if there is no data exchanged with in 3 min (3 * 60 sec)..

ClientAliveInterval 60
ClientAliveCountMax 3

@bagajjal
can you share somethings, some clues or kind like that. Since I want to follow the issue.

ClientAliveInterval 60
ClientAliveCountMax 3

Will the connection be terminated if there’s a transmitting? Because in my system, it seems so. In the middle of session, while data is transferring, connection is cut.
I just want to make sure so I can erase it from my checklist for further investigation

And for the error in libcrypto and the missing of Diffie-Hellman Key Exchange Reply . Any clues?

Sorry for being harsh and for my English.

@nightwish47
We need you help to take the «error in libcrypto» issue further. We were not able to repro it on our side.
As a first step, we need to get hold of the stack that is throwing this error — SSH_ERR_LIBCRYPTO_ERROR.

For this, we need your help to do the following:

• Download sources and compile them locally. Steps are here
• We need to intercept when SSH_ERR_LIBCRYPTO_ERROR is getting returned from anywhere in the code. Here a trick that we could use:

In ssherr.h, replace this
#define SSH_ERR_LIBCRYPTO_ERROR -22
with
#define SSH_ERR_LIBCRYPTO_ERROR_RETURN_CODE -22

and add the following definition
int ssh_err_libcrypto_error_func();
#define SSH_ERR_LIBCRYPTO_ERROR ssh_err_libcrypto_error_func()

Add the following implementation to any of the c files
int ssh_err_libcrypto_error_func() <
DebugBreak();
return SSH_ERR_LIBCRYPTO_ERROR_RETURN_CODE;
>

If you have a postmortem debugger enabled on your machine (windbg.exe -I), any logic hitting ssh_err_libcrypto_error_func() would automatically attach to a debugger and we can get the crash stack.

@manojampalam
Sorry, this «error in libcrypto» doesn’t occur in development and test environment, it only occurs in production environment so I can’t handle the risk.
I know the software isn’t ready for production but this kind of problem has never happened before.
Anyway, I will try your suggestion on dev/test system. Thanks.

I also attach another log file from another client. Hope it can help.
sshd.log.20170220.txt

Also, my system contains multiple clients. Their SSH client software are different, but the error seems to happen in some specified clients than some others.
For example:
2 clients use OpenSSH 4.3, the error only happens in 1 client.
Other 2, 1 uses WinSCP, another uses Maverick Legacy, error happens in Maverick Legacy client only.

Источник

Error loading key «. /id_ed25519.pub»: error in libcrypto

Bug Description

I can’t add my ED25519 ssh-key to my ssh-agent. I am getting this error message:

/.ssh/ id_ed25519. pub
Error loading key «/home/ user/.ssh/ id_ed25519. pub»: error in libcrypto

I have setup key agent for KDE like this:

/.config/ plasma- workspace/ env/ssh- agent.sh
#!/bin/bash

[ -n «$SSH_AGENT_PID» ] || eval «$(ssh-agent -s)»

/.config/ plasma- workspace/ env/ssh- askpass. sh
#!/bin/bash

[ -n «$SSH_ASKPASS» ] || export SSH_ASKPASS= /usr/bin/ ksshaskpass

/.config/ plasma- workspace/ shutdown/ ssh-agent- shutdown. sh
#!/bin/bash

[ -z «$SSH_AGENT_PID» ] || eval «$(ssh-agent -k)»

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: openssh-client 1:8.7p1-4
Uname: Linux 5.15.0- 051500- generic x86_64
ApportVersion: 2.20.11-0ubuntu76
Architecture: amd64
CasperMD5CheckR esult: pass
CurrentDesktop: KDE
Date: Sat Jan 29 16:43:55 2022
InstallationDate: Installed on 2022-01-21 (7 days ago)
InstallationMedia: Kubuntu 22.04 LTS «Jammy Jellyfish» — Alpha amd64 (20220121)
RebootRequiredPkgs: Error: path contained symlinks.
RelatedPackageV ersions:
ssh-askpass N/A
libpam-ssh N/A
keychain N/A
ssh-askpass-gnome N/A
SSHClientVersion: OpenSSH_8.7p1 Ubuntu-4, OpenSSL 3.0.1 14 Dec 2021
SourcePackage: openssh
UpgradeStatus: No upgrade log present (probably fresh install)

Источник

Опять C_Login failed

Сообщений 10

#1 Тема от dini 2018-10-27 08:20:23

• dini
• Посетитель
• Неактивен

Опять C_Login failed

Система Arch
После обновления OpenSSH, libssh и pkcs11-helper всё опять сломалось. 🙁

#2 Ответ от Владимир Салыкин 2018-10-29 11:43:06

• Владимир Салыкин
• Посетитель
• Неактивен

Re: Опять C_Login failed

Добрый день, dini.

Для диагностики проблемы нужны версии Arch, OpenSSH, libssh, pkcs11-helper, opensc, openssl и нашей pkcs11 библиотеки

#3 Ответ от dini 2018-10-29 13:30:05

• dini
• Посетитель
• Неактивен

Re: Опять C_Login failed

Дистриб сам по себе rolling, посему версия от сегодня.
librtpkcs11ecp.so пробовал из раздела загрузок и из sdk, не заработала ни та, не другая.
До обновления libssh всё работало, но случился CVE-2018-10933 и прилетело обновление, после всё и перестало работать.

#4 Ответ от Владимир Салыкин 2018-10-29 22:03:08

• Владимир Салыкин
• Посетитель
• Неактивен

Re: Опять C_Login failed

Добрый день, dini.

Судя по информации у вас установлены 2 версии openssl. Тут точно нет конфликта? Какая используется Вашим openssh?

#5 Ответ от dini 2018-10-30 06:14:15

• dini
• Посетитель
• Неактивен

Re: Опять C_Login failed

Конфликтов быть не должно, libcrypto.so и libssl.so ссылаются на libcrypto.so.1.0.0 и libssl.so.1.0.0 соответственно.

#6 Ответ от Владимир Салыкин 2018-10-30 13:04:16

• Владимир Салыкин
• Посетитель
• Неактивен

Re: Опять C_Login failed

Добрый день, dini.

Принято. Попробуем воспроизвести в тестировании ваш сценарий и вашу проблему. Дайте нам пару дней.

#7 Ответ от Владимир Салыкин 2018-10-31 10:30:09

• Владимир Салыкин
• Посетитель
• Неактивен

Re: Опять C_Login failed

Добрый день, dini.

Взяли ssh сервер на ubuntu, Рутокен ЭЦП, в качестве клиента Arch Linux rolling, поставили библиотеки

core/libssh2 1.8.0-2 [установлен]
core/openssh 7.9p1-1 [установлен]
extra/libssh 0.8.4-1 [установлен]
core/openssl-1.0 1.0.2.p-1 [установлен]
core/pkcs11-helper 1.25.1-1 [установлен]
community/opensc 0.18.0-1 [установлен]

Подключается без ошибок.
Показывайте конфиг и рассказывайте как именно настраивали аутентификацию по Рутокен — у нас в инструкциях есть несколько вариантов.

#8 Ответ от dini 2018-11-02 11:33:38

• dini
• Посетитель
• Неактивен

Re: Опять C_Login failed

Всё что относится к конфигам ssh:

#9 Ответ от dini 2018-11-05 09:54:29

• dini
• Посетитель
• Неактивен

Re: Опять C_Login failed

В общем спасение утопающего, дело рук самого утопающего. Проблема оказалась в том, что, по какой-то причине, заблокировался пин пользователя. Попытался через rtadmin, но не получилось разблокировать, ну да ладно.
1. По какой причине заблокировался? Неверный ввод пина исключён по определению.
2. Почему при якобы заблокированном пользователе информацию с токена я получал? Получается под защитой пина только часть инфы? Или пин вообще для «Есть потому как должно быть»?

#10 Ответ от Кирилл Мещеряков 2018-11-06 10:53:26

• Кирилл Мещеряков
• Посетитель
• Неактивен

Re: Опять C_Login failed

1) в opensc недавно проводили несколько чисток кода, связанных с потенциальными уязвимостями. По возможности не ставьте непротестированные версии, так как в них может быть много что не так. Думаю, проблема с заблокированным пином скорее всего связана именно с этим.
2) без ввода пин-кода пользователя можно получить список объектов не защищенных пин-кодом. Пинкодом защищаются закрытые ключи, а сертификаты лежат в открытом виде. Создать ключ, удалить ключ, подписать на ключе без знания пинкода никак не выйдет, а посмотреть открытые объекты можно. Так работают не только Рутокен но и больше все смарт-карты и токены.

Источник

Up until last week I was running Ubuntu 20.04 happily, and then over the weekend decided to back everything up and install 22.04. I’ve had a couple of teething issues which I’ve solver, however I’m having real issues with SSH. I have two first generation WD MyCloud drives which handle all my backups and files both on and away from home. I can still connect to the shares with no problems, however I need to SSH onto both drives in order to run maintenance, backup between cloud drives, etc.

Initially I couldn’t gain SSH access at all after upgrading, however the one-fix at this website worked. I can now connect via SSH and entering a password.

However with Ubuntu 20.04 I had set up a passphrase so that various autyomated scripts that I use using rsync could copy between cloud drives and also between Ubuntu and the cloud drive shares. This was working until I upgraded, now the scripts continually ask me for my password and I can’t figure out how to stop it.

What I was originally doing was running

ssh-keygen -b 4096

to generate a passphrase and then

ssh-copy-id root@server

to copy the passphrase across

If I then entered

ssh root@server

it simply connected without asking to my password.

I know this is going to be due to my cloud drives only supporting the now insecure SSH, but I cannot upgrade it to a more secure one (unless someone knows how — I would prefer to do this to be honest). My maintenance scripts can make up to 20 connections over a period of hours, and to have to sit and constantly enter the password is becoming a pain.

Can anyone help me get my remote rsync commands working again so they don’t keep asking me for my password

The terminal outputs as I run through these are

colin@colin-desktop:~/.ssh$ ssh-keygen -b 4096

Generating public/private rsa key pair.
Enter file in which to save the key (/home/colin/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/colin/.ssh/id_rsa
Your public key has been saved in /home/colin/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx colin@colin-desktop
The key's randomart image is:
+---[RSA 4096]----+
...
+----[SHA256]-----+

colin@colin-desktop:~/.ssh$ ssh-copy-id root@xxx.xxx.xxx.xxx

/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
root@xxx.xxx.xxx.xxx's password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'root@xxx.xxx.xxx.xxx'"
and check to make sure that only the key(s) you wanted were added.

colin@colin-desktop:~/.ssh$ ssh root@xxx.xxx.xxx.xxx

root@xxx.xxx.xxx.xxx's password: 

Linux NASServer 3.2.26 #1 SMP Thu Jul 9 11:14:15 PDT 2015 wd-2.4-rel armv7l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

NASServer:~# cd ~/.ssh

NASSERVER:~/.ssh# ls -al

total 12
drwx------ 2 root root 4096 May 17 23:32 .
drwx------ 7 root root 4096 Apr 28 19:02 ..
-rw------- 1 root root  742 May 17 23:32 authorized_keys

NASServer:~/.ssh# exit

logout
Connection to xxx.xxx.xxx.xxx closed.

colin@colin-desktop:~$ rsync --verbose --archive -e 'ssh -p 22' ~/Files/ root@xxx.xxx.xxx.xxx:/shares/Files/

root@xxx.xxx.xxx.xxx's password: 

How this originally came about was that I needed to be able to rsync to and from a remote location without the need for a human intervention regarding security. The instructions I was given were to use ssh-keygen to generate public/private keys and then ssh-copy-id to copy the public key to the remote host. I’ve just reinstalled 20.04 on another machine and used this successfully and the rsync is working without the need for a password. However if I clear the keys on the server out, reinstall 22.04 and do the same, it still prompts me for the password. I’ve updated my question to show the output of the commands as they are being run on Ubuntu 22.04 with the server name obscured for obvious reasons.

The Terminal output of rsync -vvv follows

colin@colin-desktop:~$ ssh -vvv root@xxx.xxx.xxx.xxx
OpenSSH_8.9p1 Ubuntu-3, OpenSSL 3.0.2 15 Mar 2022
debug1: Reading configuration data /home/colin/.ssh/config
debug3: kex names ok: [diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,curve25519-sha256,curve25519-sha256@libssh.org,sntrup761x25519-sha512@openssh.com]
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolve_canonicalize: hostname xxx.xxx.xxx.xxx is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/colin/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/colin/.ssh/known_hosts2'
debug3: ssh_connect_direct: entering
debug1: Connecting to xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x10
debug1: Connection established.
debug1: identity file /home/colin/.ssh/id_rsa type 0
debug1: identity file /home/colin/.ssh/id_rsa-cert type -1
debug1: identity file /home/colin/.ssh/id_ecdsa type -1
debug1: identity file /home/colin/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/colin/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/colin/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/colin/.ssh/id_ed25519 type -1
debug1: identity file /home/colin/.ssh/id_ed25519-cert type -1
debug1: identity file /home/colin/.ssh/id_ed25519_sk type -1
debug1: identity file /home/colin/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/colin/.ssh/id_xmss type -1
debug1: identity file /home/colin/.ssh/id_xmss-cert type -1
debug1: identity file /home/colin/.ssh/id_dsa type -1
debug1: identity file /home/colin/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.9p1 Ubuntu-3
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-4
debug1: compat_banner: match: OpenSSH_6.0p1 Debian-4 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to xxx.xxx.xxx.xxx:22 as 'root'
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: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,curve25519-sha256,curve25519-sha256@libssh.org,sntrup761x25519-sha512@openssh.com,ext-info-c
debug2: host key algorithms: ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-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-ecdsa-sha2-nistp256-cert-v01@openssh.com
debug2: ciphers ctos: 3des-cbc,aes128-cbc,aes192-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: ciphers stoc: 3des-cbc,aes128-cbc,aes192-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: MACs ctos: hmac-sha1,hmac-sha1-96,hmac-sha2-256,hmac-sha2-512,hmac-md5,hmac-md5-96,umac-64@openssh.com,umac-128@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-md5-etm@openssh.com,hmac-md5-96-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com
debug2: MACs stoc: hmac-sha1,hmac-sha1-96,hmac-sha2-256,hmac-sha2-512,hmac-md5,hmac-md5-96,umac-64@openssh.com,umac-128@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-md5-etm@openssh.com,hmac-md5-96-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com
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: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-rsa,ssh-dss
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: MACs ctos: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
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: diffie-hellman-group1-sha1
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: 3des-cbc MAC: hmac-sha1 compression: none
debug1: kex: client->server cipher: 3des-cbc MAC: hmac-sha1 compression: none
debug2: bits set: 515/1024
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-rsa SHA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
debug3: record_hostkey: found key type RSA in file /home/colin/.ssh/known_hosts:1
debug3: load_hostkeys_file: loaded 1 keys from xxx.xxx.xxx.xxx
debug1: load_hostkeys: fopen /home/colin/.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 'xxx.xxx.xxx.xxx' is known and matches the RSA host key.
debug1: Found key in /home/colin/.ssh/known_hosts:1
debug2: bits set: 495/1024
debug3: send packet: type 21
debug2: ssh_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: ssh_set_newkeys: mode 0
debug1: rekey in after 134217728 blocks
debug1: get_agent_identities: bound agent to hostkey
debug1: get_agent_identities: agent returned 1 keys
debug1: Will attempt key: /home/colin/.ssh/id_rsa RSA SHA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX agent
debug1: Will attempt key: /home/colin/.ssh/id_ecdsa 
debug1: Will attempt key: /home/colin/.ssh/id_ecdsa_sk 
debug1: Will attempt key: /home/colin/.ssh/id_ed25519 
debug1: Will attempt key: /home/colin/.ssh/id_ed25519_sk 
debug1: Will attempt key: /home/colin/.ssh/id_xmss 
debug1: Will attempt key: /home/colin/.ssh/id_dsa 
debug2: pubkey_prepare: done
debug3: send packet: type 5
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,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-with-mic,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/colin/.ssh/id_rsa RSA SHA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX agent
debug1: send_pubkey_test: no mutual signature algorithm
debug1: Trying private key: /home/colin/.ssh/id_ecdsa
debug3: no such identity: /home/colin/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/colin/.ssh/id_ecdsa_sk
debug3: no such identity: /home/colin/.ssh/id_ecdsa_sk: No such file or directory
debug1: Trying private key: /home/colin/.ssh/id_ed25519
debug3: no such identity: /home/colin/.ssh/id_ed25519: No such file or directory
debug1: Trying private key: /home/colin/.ssh/id_ed25519_sk
debug3: no such identity: /home/colin/.ssh/id_ed25519_sk: No such file or directory
debug1: Trying private key: /home/colin/.ssh/id_xmss
debug3: no such identity: /home/colin/.ssh/id_xmss: No such file or directory
debug1: Trying private key: /home/colin/.ssh/id_dsa
debug3: no such identity: /home/colin/.ssh/id_dsa: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
root@xxx.xxx.xxx.xxx's password: