Egy kis gond OpenSSH körül...

 ( NevemTeve | 2015. július 21., kedd - 5:39 )

Tényleg kicsinek látszik, de nem tetszik...

Last unsuccessful login: Tue Jan 29 00:30:09 *'(- on ssh from 1.2.3.4
Last login: Wed Jan  1 07:54:08 *,-0 on /dev/pts/1 from 1.2.3.4

telnet esetében nincs ilyen, jók a dátumok. Ez most egy OpenSSH 6.9p1, 64-bites. Nincs jobb ötletem, mint kipróbálni régebbi verziókat illetve ugyanezt 32-biten...

Szerk: 6.8p1, 32-bit: jó
Szerk: 6.9p1, 32-bit: jó

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Ez vajon mit jelent:

sshlogin.c: In function 'store_lastlog_message':
sshlogin.c:92:9: warning: unused variable 'last_login_time' [-Wunused-variable]
sshlogin.c:91:53: warning: unused variable 'buf' [-Wunused-variable]
sshlogin.c:91:21: warning: unused variable 'hostname' [-Wunused-variable]

Szerk: találtam egy port-aix.h nevű fájlt, szerintem lesz valaki köze a dologhoz...

Szerk sshlogin.c:98

time_string = sys_auth_get_lastlogin_msg(user, uid);

Továbbá: kezdem azt hinni, hogy a /usr/include/usersec.h-ban definiált loginsuccess lehet az eredeti forrás. (/usr/ccs/lib/libc.a(shr.o) illetve /usr/ccs/lib/libc.a(shr_64.o)

A következő rendkívül tudományos megoldás született:

if [ $(uname -v) -eq 5 -a $(uname -r) -lt 3 ]; then
    echo 'Húzzál vissza 32-bitre'
fi

AIX-on nincs saját SSH szerver?

Adnak hozzá OpenSSH-t, az kétségtelen...
azért nem árt frissíteni, különben ilyesmiket látunk:

$ /usr/bin/openssl version
OpenSSL 1.0.1e 11 Feb 2013
$ /usr/bin/ssh -v    
OpenSSH_6.0p1

Ok, de ezt az IBM patchelgeti nem? Vagy az 5.3 már nem supporttált?

Szomorú. :)

Ehhez nem értek, én csak programozó vagyok...
egyébként nemigen bízom külső cég által fordított programokban: nyilván jószándékkal csinálják, amit csinálnak, de azért nem úgy dolgoznak, mint ahogy egy lelkiismeretes programozó tenné... pl éppen a (gyári) openssh esetében így állnak a dinamikus függőségek:

1   libc.a        shr.o
2   libcrypto.a   libcrypto.so
3   libz.a        libz.so.1

Teccünk látni a második sort: valahol keressünk egy libcrypto.a-t, abban egy libcrypto.so-t, az biztosan jó is lesz. Verziószám-ellenőrzéssel ne is fárasszuk egymást.

:DDDDD

Egy brand termeknel, mint az AIX oprendszer, ez nem is szokott igenykent felmerulni, hiszen oda csak egy forrasbol kerulhet libcrypto.a - az AIX patchkeszleteibol. Szoval az a libcrypto.a ami oda kerul az biztosan jo lesz - hiszen mar a gyarban leteszteltek, hogy az-e.
--
Blog | @hron84
Üzemeltető macik

Mondjuk azért néha a perlz.org-ról is letöltődik egy-s-más, haladók meg forrásból is tudnak telepíteni...

Mert hát azért nem olyan ez, mint mondjuk egy bolti pénztárgép, ahol gyártáskor telepítik az összes szükséges szoftvert, aztán legfeljebb biztonsági frissítések jönnek.

Az a kerdes, h az IBM mennyire partolja a kulso programok telepiteset, mennyire tamogatja oket. TBH, nem igazan lehet oket hibaztatni azert, ha nem keszulnek fel arra, h valaki felul akarja csapni a libcrypto.a-t valami inkompatibilissel. Minden orultre nem lehet felkeszulni... oh, pardon.
--
Blog | @hron84
Üzemeltető macik

Nem kell felülcsapni semmit, elég elhelyezni a search-path-re, vagy elállítani a LIBPATH nevű változót... ha ezt még kombináljuk az archívumba telepített shared object című rémálommal, akkor egészen érdekes meglepetéseket szerezhetünk magunknak... jókat blogoltam erről mindenfelé

Oke, de amit te csinalsz, az nem az atlagos AIX felhasznalas.
--
Blog | @hron84
Üzemeltető macik

nevemteve szeret szivni oskovulet, nem supported cuccokkal, hagyd ra

Igen, például ez az OpenSSL-1.0.2d + OpenSSH-6.9p1 kombináció is olyan, de olyan régi...

majd a vendor ad uj csomagokat. ha nem ad, akkor mar nem supportalt rendszert hasznalsz. ha nem supportalt rendszert hasznalsz, IJ. de ezt mar 25x elmagyaraztuk.

supportalt rendszerekre a vendor dolga kiadni a frissitest, nem jottment programozok dolga kotyvasztani

Off: AIX-on, a mcedit-ben működik neked az [End] billentyű?

nem voltam AIX-re belepve 2 eve, es amikor volt loginom, akkor sem volt mceditem :)

de vimben mukodott!

Az jó. És ha mégis gond lett volna, mit teszel? Várod, hogy valaki megjavítsa, vagy azért elkezdesz vizsgálódni, debuggolni, önállóan menedzselni a problémát?

ha vendor supported end-to-end amit hasznalok (terminal, kapcsolat, minden jo), akkor nyitok hibajegyet. ha nem vendor supported, nem hasznalom. mert gondolom azert vettetek AIX-et, hogy legyen hozza support. ha nem kell a support, akkor hekkelhetsz magadnak egy LFS-t.

A vim-ben, ha nem mukodik az [End] akkor eloveszed a Vim kezikonyvet, es megnezed, mi a default keybinding helyette, es azt hasznalod.

Egyebkent csatlakozom ahhoz, amit NagyZ irt. Ha AIX-od van, akkor vagy van ra support szerzodesed, vagy nincs. Ha van ra support szerzodesed, akkor szolsz az IBM-nek, hogy he, itten nem mukodik az End billentyu az mcedit-ben, ezen es ezen a patchlevelen, kozmikus hiba, keretik azonnal fixalni.
Ha nincs support szerzodesed, akkor meg befogod az arcodat, es tudomasul veszed, hogy az mcedit-ben sosem lesz End billentyud, es elkezdesz Vim-et hasznalni. Vagy veszel support szerzodest.

Teve, hidd el, az, hogy te egy kioregedett, tamogatastol nagyon regen megfosztott brand oprendszerrel szopsz, az kuriozum. Hozzad hasonlo talan meg ot AIX-os, es tovabbi husz hasonlo allapotu de nem-AIX-os emberke van az orszagban. A nagyon szereny kisebbseg.

Minden tiszteletem a tied, mert a szent orulteket altalaban minden kultura tiszteli. :-)
--
Blog | @hron84
Üzemeltető macik

Azért gondoljuk át az alábbiakat, pont ebben a mcedit-es esetben:

* a mc-t nem az IBM fejleszti/fordítja/szállítja
* a gond termináltípustól függhet
* viszont az AIX verzió 5.2-től 7.1-ig bármi lehet

az mc resze az alaprendszernek? ha nem akkor nincs mirol beszelnunk. gondolkozz inkabb ezen.

Érdekes logika, itt egy hasonló:

K: Mit gondolsz az almakompótról?
V: Az alma nem tartozik az alapvető zöldségek közé, ne beszéljünk róla.

mar multkor is bizonyitottad, hogy kar neked barmit mondani, mert keptelen vagy felfogni, szerintem maradjunk most is ennyiben. en out, te meg szenvedj nyugodtan naponta olyan dolgokkal, amik maximum idopocsekolasok, de az is csak joindulattal.

Nem is azzal van feltetlen a baj, hogy idopocsekolas (de, amugy, mert doglott lovat ostorozol, az AIX 5 - bar nem ertek hozza, de - gondolom, hogy nem veletlenul unsupported mar). Ennyi erovel W98-ra is portolhatnal cuccokat, annak is pont ugyanennyi ertelme lenne. Mindenki ugy veri el az idejet, amivel akarja, ez a te maganproblemad.

Azonban szidni az AIX-ot azert, mert nem keszult fel egy olyan felhasznalasra, amirol megalapozottan gyanithato, hogy a userek egy nagyon-nagyon szuk koret (= par embert) erint, az erosen a nonszensz kategoria. Ez pont ugyanolyan, mintha azon hozongenel, hogy egy etterem nem enged be a konyhajaba, hogy megnezd, hogyan keszul a kaja, esetleg akar bele is szolj. Van aki toleralja az ilyesmit, van aki nem. Az oprendszerek pont ugyanilyenek, vannak, amelyeket ugy terveznek, hogy toleraljak a belemokolasokat, van, amelyeket nem igy terveznek, mert a jellemzo use casek szerint sosem fog ilyesmire igeny lenni.

Ha egy normalisan karbantartott, support szerzodessel uzemeltetett brand oprendszer nezek, azokon altalaban nem szoktak varatlan dolgok tortenni, nem jelennek meg hirtelen konyvtarak a system load pathon a semmibol, plane nem rendszerkonyvtarak (ha megis, akkor meg nem az lesz a legnagyobb bajod, hogy _ket_ libcrypto.a(libcrypto.so) van pathen). Ez nem csak az AIX-re all, hanem kb. barmire, az OS X-tol az OEL-ig.

Don't get me wrong, nem sertegetesnek szanom, de tartok tole, hogy az IBM-nek nalad sokkal jobban kepzett es sokkal tapasztaltabb mernokei vannak, ha ok ugy lattak, hogy nem kell ilyen esetre felkeszulni, az valoszinuleg azert van, mert meg nem talalkoztak olyan tamogatott esettel, ami alapul szolgalhatna a cafolatnak.
--
Blog | @hron84
Üzemeltető macik

Hát, bevallom, most összezavarodtam. Kit bíráltam vagy szidalmaztam? Ha ezt tettem, elnézést kérek, semmiképp sem volt ilyen szándékom.

Ettől függetlenül bármikor beszélgethetünk akármelyik részletkérdésről, például hogy mire valók a major és minor verziószámok shared libeknél. (Mondjuk nem feltétlenül pont itt, mert már nagyon közel vagyunk a nulla szélességhez.)

loop.

Ketlem, hogy az IBM-nel nem hozzaerto, lelkiismeretes programozok dolgoznak.

En is tudom, mire valo a verziozas a shared libeknel. Pont ezert mondom, hogy ha az IBM fejlesztoi nem lattak okat, hogy alkalmazzak, annak bizony - hiszed vagy sem - lehet, hogy megvolt a jo oka. Peldaul az, hogy nem keszultek fel azokra a perverzekre, akik le akarnak cserelni barmelyik gyari alap libraryt sajat ganyolt verziora.
--
Blog | @hron84
Üzemeltető macik