Az SSH-jelszó nem SOCKS-jelszó
Különböztesse meg az SSH-bejelentkezést a SOCKS-ügyfél-hitelesítéstől egy dinamikus OpenSSH-figyelőn.
Jelszót írt be a ssh -D elindításához. Ez az SSH-kapcsolatát hitelesítette. Nem hozott létre jelszóval védett SOCKS-fiókot minden program számára, amely elérheti az új figyelőt.
Az OpenSSH dinamikus továbbítása helyi SOCKS-szolgáltatást nyújt hitelesített SSH-transzporton. SOCKS5-kezelése a hitelesítés nélküli módszert választja; ez nem általános SOCKS-felhasználónév/jelszó kiszolgáló.
Személyes használathoz kösse helyileg:
ssh -N -D 127.0.0.1:1080 [email protected]Az adott számítógépen futó alkalmazások az 1080-as portot használják anélkül, hogy SSH-jelszavát SOCKS-jelszóként adnák meg. A dinamikus továbbítás dokumentációja leírja a figyelőt, az OpenSSH SOCKS-kezelő forráskódja pedig megadja a hitelesítés részleteit.
A megosztás megváltoztatja a problémát
A LAN-címhez kötés a portot az eredeti helyi használaton túl is elérhetővé teszi. A közeli ügyfelek nem hoznak létre külön SSH-munkamenetet csak azért, mert a forgalmuk az önén halad át. Ha a hálózat engedi a hozzáférést, ezek az ügyfelek megoszthatják az átjárója kifelé mutató identitását.
A tűzfal korlátozhatja az elérhető ügyfeleket, de nem ad hozzá SOCKS-bejelentkezési cserét. Külön SOCKS-felhasználónevekhez, kvótákhoz vagy felhasználónkénti szabályokhoz olyan kiszolgálót válasszon, amely támogatja ezeket a funkciókat. A Dante például a SOCKS-hitelesítést az ügyfélcím-korlátozásoktól elkülönítve dokumentálja.
Ez a hibaelhárításban is segít. Előfordulhat, hogy a SOCKS-felhasználónév/jelszó módszert erőltető ügyfél nem a várt módon tárgyal ezzel a figyelővel. Módosítsa az alkalmazást, vagy válasszon megfelelő hitelesített SOCKS-szolgáltatást; az SSH-jelszó ismételt próbálgatása a rossz bejelentkezést célozza.
A csak helyi elérhetőség továbbra is megértendő határ, nem pedig az az állítás, hogy a helyi számítógép minden folyamata ugyanahhoz a felhasználóhoz tartozik.