ssh kerdes

Hálózatok egyéb

Sziasztok!

Router mogott van ket gep, az egyiket szervernek hasznalom plusz van az egyetemi szerver, amire be akarok lepni.

A vegso cel az lenne, hogy egy harmadik fel dupla port forwarddal az egyetem ip cimet kapja meg (egy phd-s ismerosnek szuksege van egy adatbazisra). Ez mukodik szepen, csak szeretnem automatikussa tenni a kapcsolat kiepiteset.

Az otthoni szerveren letrehoztam egy _vendeg_felhasznalot, ot jailbe tettem (jailkittel). Letrehoztam az ssh kulcsokat, a nyilvanosat felmasoltam az egyetemi szerver authorized_keys fajljaba. A jogosultsag 755. Ha ezek utan be akarok ssh-zni, az egyetemi szerver tovabbra is keri a jelszot.

Ezek utan kiprobaltam normal felhasznaloval a belepest mind az otthoni szerverrol (amelyik nincs jailben), mind az otthoni masik geprol. Mindket esetben keri a jelszot az egyetemi szerver.

Az otthoni gep es szerver kozott mukodik a bejelentkezes ssh kulccsal es mukodik visszafele is (szoval az egyetem geperol sajatra)

A kerdesem az lenne, hogy az elkepzelheto, hogy az egyetemi szerveren valamiert tiltva van a kulccsal torteno belepes?

Udv:

Dani

( ZsoL | 2008. 01. 16., sze – 17:33 )

Hasznos dolog a debug kapcsolo az ssh-nak. A szerveren engedelyezni kell a kulcsos authentikaciot, a kliensen pedig hasznalni kell. Igy elso blikkre.

( covek v | 2008. 01. 16., sze – 17:33 )

ssh -v kapcsolóval indítva? Egyetemi szerver sshd.conf megtekintése? Ottani rendszergazda segítsége?
covek@covek.hu

Kosz a valaszt!

az sshd.confban talatam ilyet: 


RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile	%h/.ssh/authorized_keys

Gondolom a kikommentelt sornak akkor lenne jelentosege, ha nem itt lennenek tarolva a nyilvanos kulcsok.

A -v kapcsoloval kapott uzenetet ide kitettem. Ami szamomra feltunt, az ez volt: 


debug1: Authentications that can continue: publickey,gssapi-with-mic,keyboard-interactive
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Next authentication method: publickey
debug1: Trying private key: /home/dani/.ssh/identity
debug1: Offering public key: /home/dani/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-with-mic,keyboard-interactive
debug1: Trying private key: /home/dani/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive

Dani

--------------------------
Debian lenny, 2.6.23

( dfodor | 2008. 01. 17., cs – 21:50 )

Nem lehetseges az egyetemi szerveren RSA/DSA kulccsal torteno authentikacio, helyette Kerberos kulcsot lehet kerni.

ssh-hoz talaltam patch-et, de a honlapon ez allt:

This patch adds support for doing GSSAPI key exchange (and user authentication based on the results of that exchange) to OpenSSH. It extends the current GSSAPI support in OpenSSH to perform server (as well as user) authentication through GSSAPI, therefore removing the need for maintaining site-wide maps of ssh host keys*

* Whilst you can get away without generating host keys at all with this patch, to do this safely you will have to be able to ensure both that your clients will only be performing GSSAPI authenticated connections and that clients will have valid credentials when rekeying occurs.

Jol ertem, hogy ezzel a patchelt ssh-val utana csak GSSAPI alapu hitelesitest lehet letrehozni?

--------------------------
Debian lenny, 2.6.23

Rosszul erted.
Egyreszt a jelenlegi ssh verziok nagyreszt tamogatjak a gssapi bejelentkezest. Masreszt ez a patch arra jo, hogy ne kelljen host-keyeket tarolnod. A *-os resz azt mondja, hogy ha egyaltalan nem akarsz host-keyeket tarolni, akkor az osszes hostra, ahova ssh-zol ezt a GSSAPI auth methodot kell hasznalnod.

( ghost77 | 2008. 08. 14., cs – 20:10 )

Hi

Bocsi a láma kérdésért de hogyan tudom azt beállítani, hogy ha 1 ipről tegyük fel 5 hibás bejelentkezés van akkor tiltsa az ip-t?