AIX vs. SFTP for Azure Storage Account: SSH-RSA

AIX

Sziasztok,

Microsoft az év elején elérhetővé tette az SFTP interface-eket blob containerek részére.

Valamilyen SSH problémából kifolyólag AIX-ből (7.3, OpenSSH 8.x, sftp cli a kliens) nem vagyunk képesek csatlakozni semmilyen kulccsal, jelszóval viszont felépül a kapcsolat.

Más SFTP szolgáltatásokhoz képesek vagyunk kapcsolódni az érintett AIX hostról és a kérdéses SFTP szolgáltatáshoz is tudunk máshonnan kapcsolódni.

Itt dobja el az SFTP szerver a kapcsolatot (kliens-oldali log-ok):

debug1: Sent ALLOW_PKCS12_KEYSTORE_CLIENT_FLAG packet
debug3: sign_and_send_pubkey: RSA SHA256:kulcs
debug3: sign_and_send_pubkey: signing using ssh-rsa
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 1

RSA itt jelentheti a kulcs tipusát és a signing algoritmust is, ha jól értettem meg.
Utóbbi esetben az "SHA-RSA" az sha1-et jelenti, ami az OpenSSH 7.x-ben kivezetésre került (természetesen az RSA kulcs továbbra is támogatott).
Ennek ellenére ugyanúgy a "signing using ssh-rsa" marad a log bejegyzésben, ha explicit megadjuk hogy mit használhat:

HostKeyAlgorithms rsa-sha2-512,rsa-sha2-256

Ahol felépül a kapcsolat az érintett AIX hostról ott egyértelműen látszik hogy nem SHA1-t használ:

debug3: sign_and_send_pubkey: RSA SHA256:kulcs
debug3: sign_and_send_pubkey: signing using rsa-sha2-512

Nem vagyok meggyőződve róla, hogy a Microsoft nem ludas abban, hogy nem tudnak megállapodni az SHA algoritmusról.
Viszont, az sem teljen világos, hogy az AIX miért ragaszkodik az RSA-SHA-hoz, ha van más támogatott is és explicit megadjuk, hogy mást használjon.

Van bármi tippetek?
 

Köszönöm!

( sibike | 2023. 05. 09., k – 16:23 )

Szerintem nektek a PubkeyAcceptedAlgorithms paramétert kellene tekergetni. Ez mit mond kliens oldalon?

ssh -Q PubkeyAcceptedAlgorithms

Innen szép nyerni. :) Van esetleg supportotok rá? Az a gyanúm, hogy az IBM patcheli az SSH-t, mert a hivatalos OpenSSH source code alapján kellene lennie.

Az, hogy miért nem rsa-sha2-512-vel kapcsolódik, annak prózai oka lehet: Microsoft oldalon nem támogatott.

Visszatérve az eredeti problémára: rsa-sha támogatottnak kellene lennie mindkét oldalon, mert egyébként ezt kapnád:

sign_and_send_pubkey: no mutual signature supported

Olyat esetleg tudtok próbálni, hogy Linux alól PubkeyAcceptedKeyTypes=ssh-rsa kapcsolóval is működik-e a csatlakozás?

Van esetleg supportotok rá?

Van, de az az igazság hogy összeteszem a két kezem hogy az ügyfél oldal - olaszok - engineer-eit is érdekli ez az issue és együtt tudunk dolgozni,
mert nekem lenne fontos hogy docker-es SFTP-ről migrálni tudjunk managed-re. AIX persze az ügyfélnél van. :)
Van AIX támogatás is, Microsoft support-hoz pedig én is hozzáférek, bár sokat nem várok tőlük.

Az, hogy miért nem rsa-sha2-512-vel kapcsolódik, annak prózai oka lehet: Microsoft oldalon nem támogatott.
 

Támogatott:Supported algorithms
De kiegyeznhetnének akár az rsa-sha2-256-ban is, ahogyan Ubuntu alól.

Egyébként ezt vissza is küldik, ha rossz KEX-et adok neki:

Unable to negotiate with 44.133.20.16 port 22: no matching host key type found. Their offer: rsa-sha2-256,rsa-sha2-512,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384

Olyat esetleg tudtok próbálni, hogy Linux alól PubkeyAcceptedKeyTypes=ssh-rsa kapcsolóval is működik-e a csatlakozás?

Ubuntu 22.04-el igen, AIX alól ugyanezzel a hibával száll el (azonos kulcspárral).

Egyre inkább az az érzésem, hogy ssha-rsa (sha1) esetén a Microsoft egyszerűen kidobja a klienst értelmes response nélkül, hogy ezt használja a kliens az pedig valami AIX bug.

Támogatott:Supported algorithms

A public key oszlopot nézd, ne a hostkey-t!

Egyre inkább az az érzésem, hogy ssha-rsa (sha1) esetén a Microsoft egyszerűen kidobja a klienst értelmes response nélkül, hogy ezt használja a kliens az pedig valami AIX bug.

Ahogy fentebb írtam, ez azért az van, mert a MS oldal csak ezeket támogatja:

ssh-rsa, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384

Gondolom AIX oldalon pedig csak az ssh-rsa a támogatott a fentiek közül.

Sikerült egy régebbi OpenSSH elé kerülnöm, ott ez a parancs listázza a támogatott key signing algoritmusokat:

ssh -Q key-sig

Nem tudom értelmezni ezt a táblázatot.

Az "SSH-RSA" most a public key tipusára (RSA) vonatkozik, vagy az aláíró algoritmusra (SHA-1)?

RSA kulcstipust biztosan támogatniuk kell.
Az pedig nagyon furcsa lenne, ha csak azt az ssh-rsa (SHA-1) aláíró algoritmust támogatnák egy újonnan bevezett szolgáltatásban, amit már évek óta kivezett az OpenSSH.

Szerintem ez valami újabb OpenSSH-ban jött be, AIX-en (OpenSSH_8.1p1) ezt dobja:

Unsupported query "key-sig"

Ugyanez 22.04-ben:
OpenSSH_8.9p1 Ubuntu-3, OpenSSL 3.0.2 15 Mar 2022

 

ssh -Q key-sig
ssh-ed25519
ssh-ed25519-cert-v01@openssh.com
sk-ssh-ed25519@openssh.com
sk-ssh-ed25519-cert-v01@openssh.com
ssh-rsa
rsa-sha2-256
rsa-sha2-512
ssh-dss
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
sk-ecdsa-sha2-nistp256@openssh.com
webauthn-sk-ecdsa-sha2-nistp256@openssh.com
ssh-rsa-cert-v01@openssh.com
rsa-sha2-256-cert-v01@openssh.com
rsa-sha2-512-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

 

"Az pedig nagyon furcsa lenne, ha csak azt az ssh-rsa (SHA-1) aláíró algoritmust támogatnák egy újonnan bevezett szolgáltatásban, amit már évek óta kivezett az OpenSSH."

Hát pedig de. Ubuntu 22.04 alól tesztelve Azure SFTP felé RSA kulccsal:

sftp ....
sign_and_send_pubkey: no mutual signature supported

sftp -oPubkeyAcceptedKeyTypes=ssh-rsa ...
Connected to ......blob.core.windows.net.
sftp>

"

 * ssh(1), sshd(8): rename the PubkeyAcceptedKeyTypes keyword to
   PubkeyAcceptedAlgorithms. The previous name incorrectly suggested
   that it control allowed key algorithms, when this option actually
   specifies the signature algorithms that are accepted. The previous
   name remains available as an alias. bz#3253

"

Semmi köze ennek a  paraméternek a kulcs típusához.

Bővebben:

https://bugzilla.mindrot.org/show_bug.cgi?id=3253

Szerintem nem így van, tehát ebben a kontextusban a kulcs tipusát jelenti, nem az algoritmust.

De akkor induljunk ki abból, hogy az ssh-rsa mégis az algoritmus.
Pontosan melyiket, tehát az ssh-rsa most akkor SHA1-et vagy SHA2-t jelent?
Mert az openSSH továbbra is támogatja a SHA2-t, a SHA1 lett kivezetve.

SHA2-t biztosan támogatnia kell az Azure-nek, hiszen Ubunturól tudunk csatlkozni, a log-ok alapján pedig egyértelmű hogy SHA2-t használ:

debug3: sign_and_send_pubkey: RSA SHA256:kulcs
debug3: sign_and_send_pubkey: signing using rsa-sha2-512

"De akkor induljunk ki abból, hogy az ssh-rsa mégis az algoritmus."

In the SSH protocol, the "ssh-rsa" signature scheme uses the SHA-1
hash algorithm in conjunction with the RSA public key algorithm.

https://www.openssh.com/txt/release-8.7

"SHA2-t biztosan támogatnia kell az Azure-nek, hiszen Ubunturól tudunk csatlkozni, a log-ok alapján pedig egyértelmű hogy SHA2-t használ:"

Na ezt nem értem, ugyanis nekem NEM sikerül csatlakozni Azure-hoz, Ubuntu 22.04-ről, ahogy fent látod, csak ha külön engedélyezem az ssh-rsa-t.

debug1: Offering public key: /home/..../id_rsa RSA SHA256:kulcs agent
debug1: send_pubkey_test: no mutual signature algorithm

( NevemTeve | 2023. 05. 09., k – 18:32 )

Szerkesztve: 2023. 05. 09., k – 21:17

Mondtam volna, hogy ssh-keygen -t ed25519, de azt nem sorolták fel, szóval B-tervként: ssh-keygen -t ecdsa -b 256 és a id_ecdsa.pub fájlt kellene átadni azúréknak.

Szerk: megnéztem egy korszerű AIX7.2-t, a gyári OpenSSH verzió 8.1 (2019-ből), tud ilyet.

Figyeljetek arra a körülményre, hogy létrehoztam egy új kulcsot a legfrissebb Ubuntu alatt, ezzel onnan be tudtam authentikálni, viszont AIX-en ezzel is pontosan az történik mint a régi kulccsal (amit nem tudok mozgatni biztonsági okokból Ubuntura) - ezek alapján azt gondolom hogy az aláíró algoritmus nem felel meg az Azure-nak, nem maga a kulcspár.

( sibike | 2023. 05. 09., k – 21:11 )

Szerkesztve: 2023. 05. 09., k – 21:11

Ugye 2048 bites az RSA kulcs?

" RSA keys must be minimum 2048 bits in length."

( NevemTeve | 2023. 05. 10., sze – 06:27 )

Szerkesztve: 2023. 05. 10., sze – 06:41

Kezdetnek jó lenne az ssh -V outputja.

Aztán meg jöhetne a /etc/ssh/ssh_config-ban (vagy ~/.ssh/config-ban) a KexAlgorithms beállítása. Hogy pl.:

printf 'KexAlgorithms '; printf '%s,' $(ssh -Q kex | grep -v sha1); echo

OpenSSH_8.1p1, OpenSSL 1.1.1l  24 Aug 2021

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

Kiemelten az Azurral közösen támogatott algoritmusokat.

( NevemTeve | 2023. 05. 10., sze – 09:54 )

Szerkesztve: 2023. 05. 10., sze – 10:50

Teljesen off, de most látom, hogy a MANPATH beállítása nem elég (pl. export MANPATH=/usr/local/share/man:/usr/local/man:/usr/local/ssl/man), a -m opciót is használni kell (pl man -m ssh), különben a gyári (tehát elavult) manuált látjuk a saját telepítés helyett.

 

További off: az OpenSSH source szerint ezek mind szinonímák az ssh -Q-nál:

                        else if (strcmp(optarg, "key-sig") == 0 ||
                            strcasecmp(optarg, "PubkeyAcceptedKeyTypes") == 0 || /* deprecated name */
                            strcasecmp(optarg, "PubkeyAcceptedAlgorithms") == 0 ||
                            strcasecmp(optarg, "HostKeyAlgorithms") == 0 ||
                            strcasecmp(optarg, "HostbasedKeyTypes") == 0 || /* deprecated name */
                            strcasecmp(optarg, "HostbasedAcceptedKeyTypes") == 0 || /* deprecated name */
                            strcasecmp(optarg, "HostbasedAcceptedAlgorithms") == 0)
                                cp = sshkey_alg_list(0, 0, 1, '\n');

Még további off: a "packet type 1" az DISCONNECT, tehát nem feltétlenül authentikációs probléma (az a "packet type 51"); lehet, hogy a tűz- vagy vízfal vágta el a drótot?

"Még további off: a "packet type 1" az DISCONNECT, tehát nem feltétlenül authentikációs probléma (az a "packet type 51"); lehet, hogy a tűz- vagy vízfal vágta el a drótot?"

Én inkább arra gondolok, hogy valami kompatiblitási probléma miatt vágja le az Azure oldal a kapcsolatot. Lehet hogy az ottani logban szerepel is egy kis exception/crash ezzel kapcsolatban.

Én inkább arra gondolok, hogy valami kompatiblitási probléma miatt vágja le az Azure oldal a kapcsolatot. Lehet hogy az ottani logban szerepel is egy kis exception/crash ezzel kapcsolatban.

Igen, ez elképzelhető és először arra gondoltam, hogy nem is feltétlenül az authentikációban van a root cause.
Ezt csak nagyon kicsit árnyalja, hogy a passwrod basis authentikáció megy: be tud authentikálni és a megfelelő container-t látja, tehát az authorizáció is megy.

Még további off: a "packet type 1" az DISCONNECT, tehát nem feltétlenül authentikációs probléma (az a "packet type 51"); lehet, hogy a tűz- vagy vízfal vágta el a drótot?

A mi oldalunkon ezt lényegesebben ki lehet zárni, ki van engedve és működik a kapcsolat az érintett Azure VNET-ben levő más SFTP-re, illetve a kapcsolat itt is felépül, válasz nem érkezik.

Elküldtem az olaszoknak, valószinűleg tartozom neked egy sörrel. :)

Diagnosing The Problem
Collect debug logs from ssh or sshd (for outgoing or incoming connections, respectively).  The log output will contain the following messages.  The string at the end of the "Received disconnect" message may vary.
debug1: Sent ALLOW_PKCS12_KEYSTORE_CLIENT_FLAG packet
debug2: we sent a publickey packet, wait for reply
Received disconnect from 142.148.10.122 port 2222:11: Error processing packet

debug1: Sent ALLOW_PKCS12_KEYSTORE_CLIENT_FLAG packet
debug3: sign_and_send_pubkey: RSA SHA256:kulcs
debug3: sign_and_send_pubkey: signing using ssh-rsa
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 1