svn probléma

Clipper, CCC

1-2 hétig nem volt frissítve a CCC. Nem lehetett kommitolni az svn szerverbe. Ráadásul nyáron 14400-as internetem van, az is rögtön megszakad, ha fúj egy kis szél, ezért nem volt könnyű megtalálni a hibát. Végül rájöttem, hogy az a baj, hogy az svn nem bír olvasni a /dev/random-ból (blokkolva olvasná, de nem jön belőle semmi). Nem tudtam jobbat kitalálni mint, hogy újraindítottam az egész gépet, amivel lenullázódott a 388 napos uptime.

Mellesleg az eset mutatja, hogy valamennyire az uptime is informatív, pl. jelzi, hogy előfordulnak-e ilyen apróbb hibák.

  • 4907 megtekintés

( pch v | 2007. 07. 13., p – 15:21 )

legalább shotot csináltál az uptime-ről? :)

pch

( hrgy84 | 2007. 07. 13., p – 18:57 )

Ezt nem értem... Mi a ráknak akar a svn olvasni a /dev/random-ból?

Belenéztem, és úgy látom, hogy a cram-md5 azonosításhoz használja. Ez kb. így megy:

1. Küld a szerver egy véletlen sorozatot.
2. A kliens ehhez hozzáfűzi a jelszavát, az eredményből md5 hasht képez, amit visszaküld.
3. A szerver ellenőrzi, hogy neki ugyanaz a hashkód jön-e ki.

Ebben az a poén, hogy a jelszót nem kell közvetlenül átküldeni a hálózaton.

--
CCC3

( asch v | 2007. 09. 06., cs – 13:15 )

Egyszer foglalkoztam a random kérdéssel. Kb ezt olvastam (szelektív és kreatív emlékezetemen átszűrve :-))
- két random dev van, a random és az urandom. A random "valódi" random számokat ad, amig van a tárolóban, viszont ha nincs akkor blokkol amig nem keletkeznek random számok. Az urandom nem valódi random, abban az esetben ha a "valódi" randomszámok elfogynak (lehet, hogy magától is, hogy spóroljon) akkor álvéletlennel pótolja ki
- a random device-hoz entrópia forrásra van szükség. Ahhoz, hogy az RSA kulcsokat ne lehessen megsejteni, illetve, hogy egy ilyen autentikáció kikutathatatlan maradjon az álvéletlenek nem elég erősek.
- Entrópia forrás lehet valamilyen entrópia forrás hardver (nem tudom miben van ilyen, én még nem találkoztam élő példánnyal :-(), ami valami termikus zajt felerősítve mintavételez (kb)
- Hardver entrópia forrás hiányában a Linuxok rendelekznek egy entrópiagyűjtővel, ami különböző rendszer folyamatok időzítéseinek ingadozása alapján gyűjti az entrópiát (nyilvánvalóan lassú tempóban). Azt hiszem van olyan álláspont miszerint csak a user input (egér és billentyűzet) időzítéséből fogadtató el valódi entrópia (csak a konzolon, SSH-n keresztül már nem). Ezen álláspont szerint működnek is Linuxok. Egyszer ki is próbáltam (most hogy írom is kipróbáltam és az Ubuntu Feistymmel működik). Indítasz egy terminált és beírod cat /dev/random. Ki fog dobni egy rakat random bájtot, amig el nem fárad(fogy - hogy mennyit tároljon biztos lehet hangolni valahogy). Aztán blokkolódni fog, amig nem kezded nyomogatni a billentyűzetet vagy rángatni az egeret. Ha rángatod hektikus tempóban de csurognak tovább a random bitek. Tök érdekes.
- Megoldás: hardveres random forrásra van szükség vagy valakinek időnként zongorázni kell a billentyűzeten, meg esetleg megnövelni a pufferméretet. Szélsőséges esetben át lehet állítani a random device-t, hogy olyan legyen mint az urandom, de én nem tenném. Te esetedben az autentikáció módját is elég lehet megváltoztatni.
OFF - úgy tudom SSH kapcsolat esetén RSA-t csak a kapcsolat felépítésekor használnak, magához a kommunikációhoz szimmetrikus kulcsot használnak, amihez egy kapcsolati kulcsra is szükség van. A kapcsolati kulcsot online generálják a felek (hogy melyik nem tudom). Ez a kapcsolati kulcs is lehet, hogy a /dev/random-ot használja, tehát sima ssh-hoz is kellhethek random számok. Esetleg aki tudja az igazat beírhatná, mert kiváncsivá tettem magam

http://en.wikipedia.org/wiki//dev/random
"
In this implementation the generator keeps an estimate of the number of bits of noise in the entropy pool. From this entropy pool random numbers are created. When read, the /dev/random device will only return random bytes within the estimated number of bits of noise in the entropy pool. /dev/random should be suitable for uses that need very high quality randomness such as one-time pad or key generation. When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered. (Source: Linux Programmer's Manual, section 4)
"
ez alatamasztja azt amit irtal.

Tyrael

- Entrópia forrás lehet valamilyen entrópia forrás hardver (nem tudom miben van ilyen, én még nem találkoztam élő példánnyal :-(), ami valami termikus zajt felerősítve mintavételez (kb)

Pl. ebben:
The Commodore C64 provided a hardware random number generator, included in its soundchip, the Mos_Technology_SID 6581. Random bytes are fetchable by a read on the correct memory address on the 6581.

vagy mostanában a via C3-as procikban.
Forrás

Az ssh kapcsolathoz szükség van véletlen számokra. Szerencsére az ssh nem akarja a /dev/random-ot blokkolva olvasni (az svn-hez hasonlóan), mert akkor elveszett volna az ssh belépés (azaz a távoli irányítás) lehetősége.

A véletlen számok forrása nem lehet kizárólag interaktív (billentyű, egér). Pl. ez a szerver, amiról itt szó volt, 4 éve nem látott se billentyűzetet, se egeret. Amikor (távolról) újraindítottam, akkor se.

A kérdéses svn szerver nincs ssl-lel védve. Bárkit odaenged a letöltésekhez. A módosítások CRAM-MD5-ös azonosításhoz vannak kötve, ami nem nagyon erős, de azért mégsem rondíthat bele akárki. A CRAM-MD5-höz is kellenek véletlen számok.

--
CCC3