Ssh titkosítás nélkül

Linux-haladó

Ssh titkosítás nélkül

  • 772 megtekintés

( zoozo | 2006. 01. 27., p – 14:09 )

SSH-n keresztül használunk egy belső hálón egy X kiszolgálót. A hozzá kapcsolódó X-terminálkánt használt Pc-k ssh tunnelen keresztül erintkeznek az X kiszolgálóval. Azért lehetett csak ilyen körülményes módon megoldani a dolgot, mert bár belső hálóról van szó, mindegyik gépnél igy az X-termináloknál is kell a külső ip cím, azokon viszont csak néhány portot hagy nyitva a céges firewall. Átállítani nem szabad.
Jelenleg SSH-n keresztül tökéletesen működik a KDE felület, viszont felesleges titkosítással terhelni a servert és a klienseket. Ki lehet valahogy kapcsolni az encryption-t az ssh-ban, legalább az X11 forwardingra, vagy akár minden adatforgalomra?

A másik lehetőség a szabványos X -query kapcsolat. Ez lenne egyébként is az ideális megoldás. Ebben az esetben viszont át kellene állítani az X kiszolgálót úgy, hogy a nyitott portokon kommunikáljon az X-terminálokkal. Hol lehet ezt átállítani? És hogyan lehet tiltani azt, hogy a meghetározott X-terminálok IP-in kívül máshonnan ne fogadjon az X kapcsolatokat sem?

( Panther v | 2006. 01. 27., p – 14:33 )

ssh v1-et használva des-sel titkosítva kisebb az ssh(d) terhelése, de ekkor könnyebb lehallgatni a kapcsolatot.

Az SSH secure shell, tehát érdekes lenne, ha vissza lehetne butítani telnetté.

( tompos v | 2006. 01. 27., p – 14:39 )

Hasznalj rsh-t.
Annyit nem fox vele nyerni amugy szerintem.

tompos

( gsimon | 2006. 01. 27., p – 15:24 )

Fölöslegesnek tartanám kikapcsolni a titkosítást, ugyanis a nagyon számításigényes kódolást csak a kapcsolat elején használja a két oldal, amíg megbeszélik egymás között a kapcsolatra érvényes kulcsot. Ezután, mivel már van egy biztonságosan átvitt kulcs mindkét oldalon, váltanak egy kisebb számításigényű kódolásra, ami már nem feltétlen kell, hogy nyilvános kulcsú legyen. Ez a 'másodlagos' kódolás, lévén hogy nem kell nyilvános kulcsúnak lennie, és a kulcsa csak korlátos ideig van használva, lehet ugyanolyan erős kisebb számításigénnyel is.
Ha mégis faragni akarod, akkor a /etc/ssh/ssh_config ill. /etc/sshd/sshd_config file-okban a 'Ciphers' pontnál állíthatod, hogy milyen módszer(eke)t használhat, nézd meg az ott lévőket, nézegess utána, melyikről mit ír a gugli (sebesség, biztonság, stb.), és válogass kedved szerint :).

( uid_1062 | 2006. 01. 27., p – 16:03 )

Emlekeim szerint a Blowfishre mondjak, hogy gyors.

( synapse | 2006. 01. 27., p – 16:25 )

Baromsag, ne kapcsold ki nem nyersz vele annyit. En a server mas szolgaltatasait faragnam

synapse

( XMI | 2006. 01. 27., p – 16:34 )

Az én régebbi benchmarkjaim szerint az arcfour (=rc4) volt a leggyorsabb, kb utána jött cast128 és asszem csak ezután a blowfish. De még az aes128 is viszonylag gyorsnak mondható, legalábbis 100Mbit-es netre bőven elég gyors.

Ez egy ilyen scp-s teszt régi gépekkel:
[code:1:7de2d425f6]
P3/667 <- Athlon/600 transfering 42820 KBytes
Version Cipher Time observed MB/s calculated kB/s
V1 3DES 12.763 3.4-3.6 3355.01
V1 Blowfish 5.500 7.5-8.0 7785.45
V2 arcfour 4.490 10.0-11.0 9536.75
V2 3des-cbc 11.774 3.8-3.9 3636.83
V2 blowfish-cbc 5.384 8.4-8.6 7953.19
V2 cast128-cbc 5.293 8.4-8.7 8089.93[/code:1:7de2d425f6]
látszik, hogy az arfournál a 100mbit-es net a korlát, és ez egy régi teszt, amikor még 600mhz-es gépeim voltak, az akkori openssh még nem támogatta az aes-t, mert még akkor nem is létezett aes.

Egy másik tesztben azt csináltam, hogy localhost-ra csináltam x forwardingot és mplayer -vo x11-el lejátszottam egy 100 frameből álló videót és mértem az időt. Bár nem írtam fel, de gyanús, hogy itt is a 667MHz-es P3 volt a gép.
[code:1:7de2d425f6]100frames 720x480 BGR 32bit (=138240000 bytes)
Protocol cipher measured calculated
version (seconds) (MB/s)

2 aes128-cbc 33.837 4085.4685
2 aes192-cbc 36.959 3740.3609
2 aes256-cbc 39.863 3467.8774
2 3des-cbc 71.188 1941.9003
2 arcfour 21.337 6478.8864
2 blowfish-cbc 30.124 4589.0320
2 cast128-cbc 30.258 4568.7091
1 3des 91.134 1516.8872
1 blowfish 52.278 2644.3245
[/code:1:7de2d425f6]
itt már van aes és itt is elég durván az arcfour a nyerő. Az elért MB/s értékek azért fele akkorák, mint az előzőnél, mert itt a be és kitikosítást is ugyanaz a gép végzi, lévén, hogy localhostra ment az ssh. Az is látható, hogy az ssh v2 protokollt érdemesebb használni.

Egyébként úgy rémlik, hogy az openssh-t le lehet fordítani úgy, hogy ne legyen benne semilyen crypto és akkor titkosítatlanul megy, DE akkor mindig titkosítatlanul fog menni. És asszem a kliensnek és a szervernek is ilyen kiherélt sshnak kell lennie. Szoval ezt a verziót nem javaslom.