SSH kulcskeresés - Láma

Linux-security

Úgy tűnik, nem értem, az SSH hitelesítés folyamatát.
Egy szerver mentést állítanám vissza egy újratelepített szűz rendszerre úgy, hogy az új szerver is elérje azokat az ssh erőforrásokat, amiket a régi.
A probléma ott van, hogy már maga a mentés is SSH kulcs segítségével érhető el.
Az új rendszer feltelepítése után el kellene érnem, hogy kulccsal tudjam hitelesíteni az új szervert is a mentés szerverén.
Ehhez azonban tudnom kéne, az SSH mikor milyen kulcsot használ hitelesítéshez. Ez azonban nem sikerül.
A éles szerver root felhasználója készíti a mentést. A root felhasználónak nincs saját kulcsa, mégis be tud lépni a távoli mentés gépére egy egyszerű ssh paranccsal.
Az új gép root felhasználójának szintén nincs saját kulcsa, de nem tud belépni a mentéshez.
Gondoltam, ha nem a user kulcsával hitelesít az ssh, akkor a szerver valamelyik kulcsával. De ha a teljes /etc/ssh mappát átmásolom az új szerverre, akkor sem tudom elérni az új gépről a mentés szerverét. Mindig jelszót kér.
Ha naplózom az ssh kapcsolódást, a logban nem látom, melyik kulcsfájlt használja a hitelesítéshez. Egyik naplófájlban megjelent ugyan a sikeres hitelesítésről, hogy RSA és 16 bájt, de ebből sem tudom beazonosítani, melyik kulccsal hitelesít.

Hogyan állapíthatom meg, hogy a jelenlegi rendszer melyik kulcs használatával hitelesíti magát?

( zrubi v | 2019. 04. 17., sze – 15:33 )

A szerver ssh kulcsa arra való, hogy a kilinesek meg tudjanak győződni arról, hogy valóban a kívánt szerverhez csatlakoztak.

A userek ssh kulcsa arra való, hogy jelszó nélkül tudjanak belépni egy (vagy több) szerverre. Ez csak akkor megy, ha a szerveren fizikailag ott van az adott user publikus kulcsa.

Tehát, a szerveren biztosan kiderül hogy milyen kulcssal léptek be, mert:
- az SSH logolja,
- a kuklcs ott kell legyen fizikailag. Egyszerű (default) esetben a felhasználó home könyvtárában a ".ssh/authorized_keys" állományba.

A root felhasználónak nincs saját kulcsa, mégis be tud lépni a távoli mentés gépére egy egyszerű ssh paranccsal.

nem feltétlenül kell hogy "saját" kulcsa legyen, másét is használjatja, hiszen ő a "root" ;)

De, ha megnézed milyen userrel akar belépni a mentős gépre, utána a metős gép logjaiból ki kell derüljön, hogy pontosan milyen kulcsot használt...
(De a kliensen is biztosan megtalálható, hogy milen kulcsot használt. lehet aliassal, ssh configgal is megadni a paramétereket)

--
zrubi.hu

Az alatt, hogy egy egyszerű ssh paranccsal, azt értettem, hogy root-ként belépve ssh root@szerver paranccsal. Nem adom meg senkinek másnak a kulcsát. A /root/.ssh mappában pedig nincs semilyen id_* kulcs.
A mentés szerver authorized_keys mappájában sajnos túl sok kulcs van, de az esélyeseket megpróbáltam megkeresni az éles gépen, és nem találtam.
Továbbra is azt gondolom, hogy ha a /root/.ssh mappában nincs kulcs, és a root mégis be tud lépni, minden további paraméter nélkül, akkor valami olyan kulcsot használ, amiről nincs tudomásom.
Sajnos olyan logot még nem találtam, amiben ez esetben a használt kulcs fájl fizikai helye benne lenne. Az ssh -vvvv sem ad számomra elég információt.

> Az ssh -vvvv sem ad számomra elég információt.

Akkor ott valami más van, vagy nem nézed elég alaposan. Már debug1-en elárulja a kliens: 


debug1: Will attempt key: /home/kroozo/.ssh/id_rsa RSA SHA256:ezittegyhash agent
debug1: Will attempt key: /home/kroozo/.ssh/id_dsa 
debug1: Will attempt key: /home/kroozo/.ssh/id_ecdsa 
debug1: Will attempt key: /home/kroozo/.ssh/id_ed25519 
debug1: Will attempt key: /home/kroozo/.ssh/id_xmss 
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/kroozo/.ssh/id_rsa RSA SHA256:ezittegyhash agent
debug1: Server accepts key: /home/kroozo/.ssh/id_rsa RSA SHA256:ezittegyhash agent
debug1: Authentication succeeded (publickey).

-vvv-vel (hajrá nyelvtanhuszárok) az ssh el szokta árulni, hogy mégis hogy a pitlibe authentikált, csak meg kell próbálni elolvasni a sorokat, legalább a "Next authentication method" sorok után mert átfutásra nem szokott feltétlen egyértelmű lenni, hogy ez most az.

Bizonyosan csak én nem találom meg benne, hisz kulcs nélkül nincs ssh.
Itt az ssh -vvv teljes kimenete:
https://pastebin.com/g8qzJThx
Azt látom belőle, hogy a /root/.ssh/ alatt egyetlen kulcsot sem talál, de hogy ezek helyett mégis melyiket használja, azt nem tudtam kideríteni.
Számomra már az is fura, hogy egy user saját jelszó vagy saját kulcs nélkül egyáltalán kapcsolódhat.

Hát, tényleg olvasmányos :)

Itt van ni: 


debug2: key: webmuhely@xubuntu (0x55968e758790), agent
...
debug1: Next authentication method: publickey
debug1: Offering RSA public key: webmuhely@xubuntu
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug2: input_userauth_pk_ok: fp SHA256:6lLZ6UJS7FaqNsexGndC+ww8O/jA45XvG3Sy7Wb8O2A
debug3: sign_and_send_pubkey: RSA SHA256:6lLZ6UJS7FaqNsexGndC+ww8O/jA45XvG3Sy7Wb8O2A
debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).

Szóval az agentből veszi ki, később ezzel is authol. Az 

ssh-add -l

lesz a barátod.

A 

debug1: Skipping ssh-dss key webmuhely@xubuntu - not in PubkeyAcceptedKeyTypes

szerintem átbaszásból van ott, mert a kulcs, amit felajánl, az rsa, amit meg skippel az dsa, szóval két kulcs az, csak ugyanaz a kommentjük, és a dsaról nem is derül ki más. Az agenten szerintem ott lesz mindkettő.

Akkor most kicsit lassabban: hol van a kulcs?
Az ssh-add -L a publikus kulcsot is megmutatta, erre rákerestem, amiből kiderült, hogy ez a /root/.ssh/authorized_keys fájlban van. Ez gáz, mert ebben azon felhasználók publikus kulcsai szerepelnek, akik beléphetnek az aktuális gépre. Márpedig ez a log nem a mentés szerver logja, hanem az éles (szerepkörben futó) szerveré.
Akkor az ssh hitelesítés folyamata a következő? :
- Az éles szerver root felhasználója megpróbálja magát hitelesíteni a mentés szerveren, mint root, de nincs ssh kulcsa, emiatt
- A mentés szerver root felhasználójának a kulcsával hitelesíti a kapcsolatot, mivel a mentés szerver root felhasználójának joga van belépni az éles szerverre?

Ez lenne a titok? A mentés gép kulcsa hitelesíti az ssh kapcsolatot, és az új szerverrel azért nem tud kapcsolatot kiépíteni, mert a mentés gép root felhasználójának még nincs joga belépni az új szerverre?

Ez egy kicsit ebben a formában hektikus, és biztos nem az történik, amit leírtál, mint kérdés.

Az 'ssh-add -l' megmutatja, hogy milyen kulcsok vannak betöltve, azt is, hogy honnan. Nekem konkrétan ott van a file neve a sor végén, el tudod árulni, hogy neked hogy néz ki egy ilyen sor? Lehet, hogy pkcs vagy valami ilyesmi van a file helyett, ha máshonnan jön.

A -L ezeknek a publik kulcsa, az hogy ezt megtaláltad az authorized_keys fileban csak annyit jelent, hogy azzal a kulccsal ide is be lehet jelentkezni. (Ami egyébként indikál némi fuckupot)

Szóval valahol az éles szerveren hozzáadódik az éles szerveren futo ssh-agenthez az a kulcs.

(Lehetne még esetleg agent forwardingból, de egyrészt mentő script esetén kétlem, másrészt olyankor az extra összezavaróként kiírja az -l a filenevet, ami nem is azon a gépen van)

Az ssh-add -l kimenete nálam: 


2048 SHA256:eh1xA1yVPpXLsEq+isRaauYoc8bNUPZwbAkiMlb5G24 webmuhely@xubuntu (DSA)
2048 SHA256:6lLZ6UJS7FaqNsexGndC+ww8O/jA45XvG3Sy7Wb8O2A webmuhely@xubuntu (RSA)

Ennyi. Ebből sokkal okosabb nem lettem. Gondolom ez is azt bizonyítja, hogy nem a helyi fájlrendszerben van a kulcs.

nem, ez azt bizonyitja, hogy van komment a publikus kulcs utan.

eff@eff-latitude:~$ ssh-add .ssh/id_rsa
Identity added: .ssh/id_rsa (eff@...)
eff@eff-latitude:~$ ssh-add -l
4096 SHA256:+S3KgXoUtA7nvf...ZFGn5jtRnegH4VE eff@... (RSA)

na ez nalam igy nez ki file szinten:
id_rsa:

-----BEGIN OPENSSH PRIVATE KEY-----
...
-----END OPENSSH PRIVATE KEY-----

id_rsa.pub:

ssh-rsa ...== eff@...

En lehet megprobalnek egy grepet, hatha (systemd service, cron, egyeb):
grep -r -e 'ssh-add' /etc

Ha az nem megy, meg lehet probalni a kulcs metadatat keresni, vagy akar a publikus kulcsra is.
grep -r -e 'ssh-rsa.*webmuhely@xubuntu' /

amiket meg esetleg megnezhetsz, az pl .ssh/config, .profile, .bashrc, stb, hatha ott adja hozza automatikusan.

Rákerestem már a kulcsokra a teljes /etc alatt, de sehol sincs meg.
A környezet egy teszt környezet, szűz debian telepítésekből kialakítva, így nem hiszem, hogy külön trükkök lennének benne. Én legalábbis nem tettem bele sehova ilyen vicceket.
Szerintem van itt valami, amit nem tudok az ssh hitelesítés folyamatáról, abban az esetben, ha a kapcsolódó kliensnek nincs saját kulcsa.
Jó lenne valamilyen eszköz, ami egyértelműen, kijelzi, hogy fájl szinten melyik kulcsot használja a rendszer.
Számomra az is érdekes az ssh logból, hogy amíg a /root/.ssh/id_* fájlokat keresi az ssh, addig naplózza a fájlok elérési útvonalát, aztán már nem. Ami - az én tudatlan agyamnak - azt erősíti szintén, hogy a használt kulcsnak nincs a kliens fájlrendszerében tárolt változata. És ezt újraindítás után is tudja, tehát vélhetőleg máshol sincs a kliensen tárolva.

figyu, többen is megírtuk, a kulcsot az ssh-agent adja oda a kapcsolatkor. Ezt egyértelműen le is logolja.

Az, hogy azz ssh-agent honnan szerezte a kulcsot, egy másik kérdés, az nem lesz benne az ssh logokban. Az agent viszont biztosan tudja.

Sőt, olyan linket is kaptál, amiben leírják hogyan szerezd meg az ssh-agent-től a memóriájában lévő kulcsot.

nics itt semmi magic, csak a rutin, meg az évek hiányoznak ;)

--
zrubi.hu

azert irtam, hogy probald meg megtalalni, mi inditja az ssh-agent-et, mi adja hozza a kulcsot. Azt meg mindig nem tudjuk, hogy milyen backup rendszerrol van szo, sajat custom, vagy valami agentes kozponti/automatizalt cucc?

pl siman el tudom kepzelni, hogy ha bacula csinalja a mentest, akkor abban valami kozponti helyrol importalja be a privat kulcsot, ami total mashogy nez ki, es csak a backup rendszer doksijabol fogod tudni kihamozni. Az is lehet, hogy egy management node ssh-zik be agent forwarddal, es ugy futtat backupot, akkor masik vason lesznek a kulcsok.

ha megtalalod, mi inditja az ssh-agent-et (grep -r -e 'ssh-agent' /), meg mi adja hozza a kulcsot (grep -r -e 'ssh-add' /), akkor talan kozelebb jutsz a megoldashoz. Ha custom, akkor en ezekre tippelnek, bar ha pythonban, vagy masban irodott a backupert felelos szolgaltatas, akkor ezekkel nem fogod megtalalni. pl: http://docs.paramiko.org/en/2.4/api/agent.html

Szovel elso lepes a backupert felelos scriptek/rendszer megtalalasa es atnezese, dokumentacio, readme-k, honnan indul a trigger, stb.

A kulcsos SSH asszimetrikus kulcsú titkosítással működik. a szerveren megvan a publikus fele, a kliensen aki be akar lépni, a privát fele.
Itt viszonylag jól leírják, mi történik:
"https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process#authenticating-the-user's-access-to-the-server"

Ha a kliens oldalon (éles szerver / új éles szerver) nincs meg a privát kulcs, akkor nem fogja tudni bizonyítnai, hogy ő valójában az, akinek vallja magát. Viszont ezen felül még akár szerver oldalon (mentés szerver) is lehet korlátozni a dolgot, hogy adott kulcsot csak adott géptől/felhasználótól/IP-ről fogadok el.

( eff | 2019. 04. 17., sze – 16:27 )

Az éles rendszeren meg kell nézni, pontosan mit csinál a mentés, sim plain ssh esetén vagy `-i`, vagy esetleg ssh-agent, ha valami trukkosebb, akkor meg annak a backup rendszernek a dokumentaciojabol lehet kideriteni milyen credential store-t hasznal (esetleg host_key, vagy kerberos host auth?)

A masik lehetoseg, hogy a backup szerveren megemeled az sshd loglevelt, es megnezed az auth logot, hogy pontosan milyen authentikacioval engedi be.

ssh host based auth: https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Host-based_Authentication
attol, hogy a host keyeket atmasolod, masik IP-rol nem fogja beengedni.

( gernext | 2019. 04. 17., sze – 22:58 )

Ahonnan beenged az SSH, ott -vvv kapcsolóval csatlakozz a szerverre. Abból ki fog derülni hogy végül milyen módon jutott be.

már hogyne derülne ki.
ott figfyel a commentje, az hogy agnet-től kapta, és a fingerprintje is:

debug2: key: webmuhely@xubuntu (0x55968e758790), agent
debug1: Offering RSA public key: webmuhely@xubuntu
debug3: sign_and_send_pubkey: RSA SHA256:6lLZ6UJS7FaqNsexGndC+ww8O/jA45XvG3Sy7Wb8O2A
debug1: Authentication succeeded (publickey).

(csak a releváns sorokat idéztem)
És már más is megírta. :)

--
zrubi.hu

keresd meg az agent-et.
hol, mikor ki indítja el, és adja hozzá ezt a kulcsot.

Maga a kulcs ilyenkor nem biztos hogy azon a gépen van, lehet akár egy fizikai tokenen is.

Amint az agent-hez adtad, a memóriában marad. Egy reboot-ig, vagy ameddig "kézzel" ki nem veteted onnal, vagy ameddig az agent tároja a beállításai szerint.

--
zrubi.hu

Nem hinném, hogy nagy probléma lenne megkeresni egy file-t amiben benne van a webmuhely@xubuntu vagy a "RSA PRIVATE KEY".
Első körben azokat a file-okat keresném amelyek neve key-t tartalmaz. Ha nem ad eredményt akkor lehet bővíteni.

pl: for i in `find / -type f -name *key*`;do echo $i;grep "webmuhely@xubuntu" $i;echo "---";done

Egyénként ha célgépen a céluser $HOME/.ssh/authorized_keys file-jában benne kellene lennie a publikus kulcsnak.
Arra is lehet keresni (általában a privát és publikus kulcs egymás mellett van).

F

( plt | 2019. 04. 18., cs – 13:35 )

Köszönöm a tippeket és ötleteket. Meglett a megoldás. Gondolom, ezt sokan tudják, nekem újdonság volt:
Ha a root A gépről bejelentkezik ssh-val a root nevében a B gépre, akkor a bejelentkezés ideje alatt a B gépről ssh-val már kulcs nélkül jelentkezhet vissza - persze szintén root néven - az A gépre. Az AB irányú hitelesítés hitelesít BA irányba is.

( Tom | 2019. 04. 18., cs – 14:05 )

Csak tippelgetek mivel kevés az info, ~/.bashrc-be az éles szerveren a root usernél nincs csalafintaság az ssh-agent indításásra?
pl. ehhez hasonlóan: http://mah.everybody.org/docs/ssh
vagy uram bocsá a /etc/profile fájban esetleg a /etc/profile.d könyvtárban - ide azért én nem tenném, de ki tudja.

Ha jól tévedek akkor az rc.local lefut sysvinit-es rendszeren, systemd-sen nem tudom, akár itt is lehet valami varázslat.

Ezt az egészet meg meg lehet bonyolítani egy ldap-al is: https://serverfault.com/questions/653792/ssh-key-authentication-using-l…, ahol a backup szerver rendszeresen leszedi az ldap-ba mententt publikus kulcsokat.

Ami biztos, valahol elindul az agent és betölti a kulcso(ka)t, majd amikor kell, az ssh használja is.
Én a kissebb ellenállás felé mozdulnék: csinálnék egy új kulcsot/kulcspárt az új szerveren, a publikus részt meg bemásolnám a backup authorized_keys fájlba.