OpenSSH FAQ (Gyakran Ismételt Kérdések)

1.0 - Mi az OpenSSH és hol lehet beszerezni?

• 1.1 - Mi az OpenSSH, és honnan lehet letölteni?
• 1.2 - Miért kéne használni?
• 1.3 - Mely operációs rendszerek támogatottak?
• 1.4 - Mi a helyzet a szerzői jogokkal, a felhasználással és a szabadalmakkal?
• 1.5 - Hol kérhetek segítséget?

2.0 - Általános kérdések

• 2.1 - Miért létesít az ssh/scp kapcsolatot alacsony portokról. A tűzfalam blokkolja ezeket.
• 2.2 - Az ssh ügyfél miért "setuid root"?
• 2.3 - Az SSH 2.3-nak miért vannak problémái az OpenSSH 2.1.1-el való együttműködésben?
• 2.4 - Miért írja ki az OpenSSH, hogy: "Dispatch protocol error: type 20"?
• 2.5 - A kereskedelmi SSH régebbi verziói a host-kulcsot IDEA-val titkosítják.
• 2.6 - Mik ezek a figyelmeztető üzenetek a kulcshosszal kapcsolatban.
• 2.7 - Az X11 és/vagy az ügynök továbbítás (Agent Forwarding) nem működik.
• 2.8 - Az OpenSSH frissítése után elvesztettem az SSH2 támogatást.
• 2.9 - sftp/scp nem tud kapcsolódni, pedig az ssh rendben van.
• 2.10 - Adtok-e új szolgáltatásokat az scp-hez?
• 2.11 - Hogyan használjam a kapu továbbítást (port forwarding)?
• 2.12 - Az ssh kapcsolatom lefagy vagy kilép N perc inaktivitás után.
• 2.13 - Hogyan másoljak olyan fájlt scp segítségével, amelynek a nevében kettőspont található?
• 2.14 - Az OpenSSH miért közli a verzióját a klienssel?

3.0 - Portolható OpenSSH kérdések

• 3.1 - Téves PAM autentikációs üzenetek a logfáljokban.
• 3.2 - Üres jelszavak nem engedélyezettek PAM autentikációval.
• 3.3 - ssh(1)-nak sokáig tart a csatlakozás vagy a bejelentkezés.
• 3.4 - "Can't locate module net-pf-10" üzenet a logban Linux alatt.
• 3.5 - Jelszavas autentikáció nem működik (pl. Slackware 7.0 és Red Hat Linux 6.x alatt).
• 3.6 - Configure vagy az sshd(8) panaszkodik az RSA támogatás hiánya miatt.
• 3.7 - "scp: command not found" (scp: parancs nem található) hiba.
• 3.8 - A "jelmondatot" nem lehet olvasni.
• 3.9 - 'configure' hiányzik vagy a make nem működik.
• 3.10 - Kilépéskor az ssh kiakad.
• 3.11 - Miért áll meg az ssh kilépéskor?
• 3.12 - Frissítettem OpenSSH 3.1-ra és az X11 továbbítás többé nem működik.
• 3.13 - Frissítettem OpenSSH 3.8-ra és azóta néhány X11 program többé nem működik.
• 3.14 - Bemásoltam a nyilvános kulcsomat az authorized_keys fájlba, de a nyilvános kulcsú autentikáció még mindig nem működik.
• 3.15 - OpenSSH verziók és a PAM viselkedése.
• 3.16 - A "w" és a "who" AIX 5.x alatt miért nem listázza ki az ssh-val belépett felhasználókat?

1.0 - Mi az OpenSSH és hol lehet beszerezni?

1.1 - Mi az OpenSSH, és honnan lehet letölteni?

Az OpenSSH egy SZABADON FELHASZNÁHATÓ verziója az SSH protokollcsaládot használó hálózati eszközöknek, melyben egyre több Internet felhasználó bízik. A telnet, rlogin, ftp és a többi hasonló program felhasználói közül sokan nem is tudják, hogy a jelszavaik az Interneten kódolatlanul utaznak. Az OpenSSH a teljes forgalmat (beleértve a jelszavakat is) kódolja a hallgatózás, a kapcsolat lopás és a többi hálózati szintű támadások kivédése érdekében.

Az OpenSSH készlet tartalmazza az ssh(1) programot, amely az rlogint és a telnetet váltja ki, az scp(1)-t, amely az rcp(1)-t és az ftp(1)-t. Továbbá az OpenSSH-hoz hozzá lett adva az sftp(1) és az sftp-server(8), melyek a fájl átvitelt egyszerűsítik. Ezek a secsh-filexfer IETF tervezeten alapulnak.

Az OpenSSH számos programból áll.

• sshd(8) - Kiszolgáló program, mely a kiszolgáló gépen fut. Ez figyeli az ügyfél gépektől jövő kapcsolatokat, ha kapcsolódást érzékel akkor elvégzi az autentikációt és elkezdi kiszolgálni az ügyfelet. A viselkedését az sshd_config(5) fájl határozza meg.
• ssh(1) - Ez az ügyfél program amellyel be lehet jelentkezni egy másik rendszerbe vagy parancsokat lehet futtatni a másik gépen. slogin ennek a programnak egy másik neve. A viselkedését az ssh_config(5) globális konfigurációs fájl, és a felhasználók saját $HOME/.ssh/config fájlja határozza meg.
• scp(1) - Biztonságosan másol fájlokat egyik gépről a másikra.
• ssh-keygen(1) - Nyilvános kulcsú autentikációhoz (RSA vagy DSA) lehet vele kulcsokat generálni (host kulcsokat és felhasználói autentikációs kulcsokat).
• ssh-agent(1) - Autentikációs ügynök. Ez tudja tárolni az RSA kulcsokat az autentikációhoz.
• ssh-add(1) - Ezzel lehet regisztrálni új kulcsokat az ügynök részére.
• sftp-server(8) - SFTP kiszolgáló alrendszer.
• sftp(1) - Biztonságos fájl-átviteli program (secure file transfer).
• ssh-keyscan(1) - gyűjti az ssh publikus kulcsokat.
• ssh-keysign(8) - ssh segédprogram host-alapú autentikációhoz.

Letöltés

Az OpenSSH-t két különböző letölthető terjesztésben adják ki: a csak OpenBSD alá készült terjesztés és a többplatformos ún. portolható terjesztés. Ha az OpenSSH egy mostani OpenBSD-hez kell, vagy egy termékbe integrálva, akkor valószínűleg az OpenBSD alá készült terjesztésre van szükséged. Ha más platformhoz készült OpenSSH verziót akarsz, vagy egy régebbi OpenBSD-hez valót, akkor valószínűleg a Portolható terjesztésre lesz szükséged.

A letöltéshez válassz egy hozzád közeli tükör szervert.

1.2 - Miért kéne használni?

OpenSSH egy eszközkészlet, amely segít biztonságossá tenni a hálózati kapcsolatokat. Itt egy lista a szolgáltatásairól:

• Erős autentikáció. Lezár számos biztonsági lyukat (pl. IP, útválasztó és DNS spoofolás).
• Fejlettebb titkosítás. Minden kommunikáció automatikusan és láthatatlanul titkosítódik.
• Biztonságos X11 munkafolyamatok. A program automatikusan beállítja a DISPLAY-t a kiszolgáló gépen és minden X11 kapcsolatot a biztonságos csatornán keresztül továbbít.
• Tetszőleges TCP/IP portokat lehet átirányítani egy kódolt csatornán keresztül mindkét irányban (pl. elektronikus vásárláshoz).
• Nincs szükség a felhasználók semmiféle továbbképzésére.
• Sosem bízik meg a hálózatban. Minimális bizalom a kapcsolat távoli végében. Minimális bizalom a tartománynév kiszolgálókban(DNS). Tiszta RSA autentikáció nem bízik másban csak a privát kulcsban.
• Az ügyfél RSA-val autentikálja a kiszolgálót minden kapcsolat elején, hogy megakadályozza a "trójai lovakat" (útválasztó vagy DNS spoofolás miatt) és a" man-in-the-middle" támadásokat, továbbá a kiszolgáló RSA-val autentikálja az ügyfél gépet mielőtt elfogadná az .rhosts vagy /etc/hosts.equiv autentikációt (hogy megakadályozza a DNS, útválasztó, vagy IP-spoofolást).
• Host autentikációs kulcs terjesztése elvégezhető központilag az adminisztrációval, automatikusan a géphez való első kapcsolódáskor.
• Bármely felhasználó készíthet bármennyi felhasználói autentikációs RSA kulcsot saját használatra.
• A kiszolgáló programnak van saját RSA kulcsa, melyet minden órában automatikusan újra generál.
• Egy autentikációs ügynököt, mely a felhasználó laptopján vagy helyi munkaállomásán fut, lehet a felhasználó RSA autentikációs kulcsainak tárolására használni.
• A szoftvert még rendszergazdai jogosultság nélkül is lehet telepíteni és futtatni (korlátozott funkcionalitással).
• Az ügyfélprogram testre szabható felhasználónkénti vagy az egész rendszerre érvényes konfigurációs fájlok segítségével.
• Tömörítést lehet alkalmazni minden adaton a gzip segítségével (beleértve a továbbított X11 és TCP/IP port adatot), amely jelentős sebességnövekedést eredményezhet lassú kapcsolat esetében.
• Teljesen lecserélhető vele az rlogin, rsh és az rcp.

Jelenleg szinte minden kommunikáció a számítógépes hálózaton titkosítás nélkül megy végbe. Következésképp bárki, akinek van hozzáférése egy hálózatra kapcsolt géphez, képes figyelni bármilyen kommunikációt. Ezt teszik a hackerek, kíváncsi adminisztrátorok, munkaadók, bűnözők, ipari kémek és az állam. Sok hálózatból kiszivárog annyi elektromágneses sugárzás, hogy az adatokat még távolról is el lehet fogni.

Ha bejelentkezel egy távoli gépre, a jelszavad tiszta szöveg formájában megy át a hálózaton. Így egy hallgatózó ezután használhatja az accountodat bármilyen rosszindulatú dologra. Világszerte számos incidens fordult elő, ahol crackerek munkaállomásokon, a felhasználók tudta nélkül indítottak el olyan programokat, amelyekkel figyelték a hálózatot és jelszavakat gyűjtöttek. Ilyen programok megtalálhatók az interneten, vagy egy hozzáértő programozó néhány óra alatt képes megírni.

Az üzleti életben számos kereskedelmi titok van, szabadalmaztatás alatt álló alkalmazások, ár információk, információk az alvállalkozókról, ügyfelek adatai, személyes adatok, befektetési információk, stb. Jelenleg bárki akinek hozzáférése van a hálózathoz (bármely gép a hálózaton) le tud hallgatni bármint ami a hálózaton áthalad, függetlenül a normál hozzáférési megszorításaitól.

Számos vállalat nem fordít figyelmet arra, hogy ezeket az információkat könnyen meg lehet szerezni a hálózatról. Azt hiszik, hogy az adataik biztonságban vannak, mivel nem feltételezik senkiről, hogy tudja, hogy érzékeny információk vannak a hálózaton, vagy mert sok más adat is kering a hálózaton. Ez nem biztonságos hozzáállás.

1.3 - Mely operációs rendszerek támogatottak?

Habár az OpenSSH-t OpenBSD-n fejlesztik, számos port létezik más operációs rendszerre is. Az OpenSSH portolható verziójának fejlesztését Damien Miller vezeti. Egy rövid információ a portolható verzióról itt található: Az OpenSSH Portolható Kiadása. A támogatott oprendszerek listája:

• OpenBSD
• NetBSD
• FreeBSD
• AIX
• HP-UX
• IRIX
• Linux
• NeXT
• SCO
• SNI/Reliant Unix
• Solaris
• Digital Unix/Tru64/OSF
• Mac OS X
• Cygwin

Azoknak a cégeknek a listáját, amelyeknek a terjesztésében benne van az OpenSSH az Openssh Felhasználók lapján találhatod.

1.4 - Mi a helyzet a szerzői jogokkal, a felhasználással és a szabadalmakkal?

Az OpenSSH fejlesztői mindent megtesznek, hogy az OpenSSH szerzői jogi és szabadalmi problémáktól mentes maradjon. Ennek érdekében bizonyos opciókat el kellett távolítani az OpenSSH-ból. Mégpedig a szabadalommal védett algoritmusok támogatását.

OpenSSH nem támogat semmilyen szabadalmaztatott átviteli algoritmust. SSH1 módban csak a 3DES és a Blowfish a lehetséges opciók. SSH2 módban csak a 3DES, Blowfish, CAST128, Arcfour és az AES a lehetséges választás. A szabadalom védett IDEA algoritmus nem támogatott.

OpenSSH támogatja mind az SSH1 mind az SSH2 protokollokat.

Mivel az RSA szabadalma lejárt, nincs megszorítás az RSA algoritmust használó szoftverekre, beleértve az OpenBSD-t.

1.5 - Hol kérhetek segítséget?

Számos helyen lehet segítségért fordulni. A fő OpenSSH webhelyen kívül sok más levelezés listát is meg lehet próbálni. Mielőtt egy levelezési listán próbálkoznál, kérlek olvasd végig a lista archívumát, hátha a kérdésed már megválaszolták korábban. Az OpenSSH levelezési lista archiválva van és egy könnyen kereshető formában a következő helyen érhető el: theaimsgroup.com.

Az OpenSSH-ról szóló levelezési listákra való feljelentkezéssel kapcsolatos további információkért nézd meg az OpenSSH levelezési lista oldalt.

Az OpenSSH-ban talált hibák bejelentésével kapcsolatos információk a Hibák bejelentése lapon találhatók.

2.0 - Általános kérdések

2.1 - Miért létesít az ssh/scp kapcsolatot alacsony portokról?

Az OpenSSH ügyfél az alacsony portokat használja az rhosts és rhosts-rsa autentikációra, mivel a kiszolgálónak meg kell bíznia az ügyfél által adott felhasználónévben. Hogy ezt elkerüld, add a lenti példát a saját ssh_config vagy ~/.ssh/config fájlodhoz.

UsePrivilegedPort no

Vagy megadhatod opcióként a parancssorban az -o kapcsolóval az ssh(1) parancs használatakor.

$ ssh -o "UsePrivilegedPort no" host.com

2.2 - Az ssh ügyfél miért "setuid root"?

Az előbbi kérdésből kifolyólag, (2.1) az OpenSSH-nak szükséges a root jogosultság ahhoz, hogy hozzá tudja kötni magát az alacsony portokhoz az rhosts autentikáció elvégzéséhez. Ezen kívül szükség van egy privilegizált portra a régebbi SSH kiadásokban használt rhosts-rsa autentikációhoz is.

Továbbá, mind az rhosts-rsa autentikációhoz (az 1 protokoll verzióban) mind a host-alapú autentikációban (a 2 protokoll verzióban) az ssh ügyfélnek el kell érnie a privát host kulcsot azért, hogy az ügyfél gép autentikálni tudjon a kiszolgálóhoz. A 3.3 verzió előtti OpenSSH-ban az ssh binárisnak setuid root jogra volt szüksége ennek engedélyezéséhez, de nyugodtan eltávolíthatod a setuid bitet, ha nem akarod ezt a fajta autentikációt használni.

Az OpenSSH 3.3 óta az ssh nem setuid root alapértelmezésben. ssh-keysign segítségével lehet a privát host kulcsot elérni, és az ssh nem használ privilegizált forrásportot alapértelmezésben. Ha mégis privilegizált forrásportot akarsz használni, akkor manuálisan kell beállítanod a setuidot az ssh-n.

2.3 - Az SSH 2.3-nak miért vannak problémái az OpenSSH 2.1.1-val való együttműködésben?

Az SSH 2.3 és korábbi verziók HMAC megvalósítása hibás volt. A kódjuk nem a teljes adatblokk kimenetet adta meg a digest-ből, hanem mindig csak 128 bitet. Ezért hosszabb digest esetén az SSH 2.3 nem tud együttműködni az OpenSSH-val.

OpenSSH 2.2.0 felismeri az SSH 2.3 ezen hibáját. Az SSH mostani verzióit már javították. Vagy hozzáadhatod a következő sort az SSH 2.3 sshd2_config-hoz:

Mac hmac-md5

2.4 - Miért írja ki az OpenSSH, hogy: Dispatch protocol error: type 20

Ez az együttműködési hiba azért van, mert az OpenSSH régebbi verziói nem támogatták a "session rekeying"-et. Azonban a kereskedelmi SSH 2.3 megpróbálja egyeztetni ezt a szolgáltatást és ezért tapasztalhatod a kapcsolat lefagyását vagy a következő hibaüzenetet: "Dispatch protocol error: type 20 ". Hogy elkerüld ezt a problémát, frissíts a legutolsó OpenSSH kiadásra, vagy kapcsold ki a kereskedelmi SSH 2.3-ban a "rekeying"-et úgy, hogy hozzáadod a következő sort az ssh2_config vagy az sshd2_config-hoz.

RekeyIntervalSeconds 0

2.5 - A kereskedelmi SSH régebbi verziói IDEA-val kódolták a host kulcsokat.

Az SSH régebbi verziói egy szabadalommal védett algoritmust használnak a /etc/ssh/ssh_host_key kódolásához. Ez azért probléma, mert az sshd(8) nem képes olvasni ezt a host kulcsot. Ennek kiküszöbölésére használd a lenti parancsot, hogy átkonvertáld a saját ssh_host_key-ed, hogy 3DES-t használjon. MEGJEGYZÉS: A kereskedelmi SSH ssh-keygen(1) programját használd, *NE* az OpenSSH-t, a lenti példához:

# ssh-keygen -u -f /etc/ssh/ssh_host_key

2.6 - Mik ezek a figyelmeztető üzenetek a kulcshosszal kapcsolatban?

A kereskedelmi SSH ssh-keygen(1) programja tartalmazott egy olyan hibát, mely miatt olykor a generált Publikus Autentikációs (RSA vagy DSA) kulcsok legnagyobb helyi értékű bitje nem volt beállítva. Ezek a kulcsok rövidebbek mint amilyennek feltüntetik őket.

OpenSSH kiír egy figyelmeztető üzenetet, ha ilyen kulccsal találkozik. Hogy megkíméld magad ezektől az üzenetektől, szerkeszd át a saját known_hosts fájlod és javítsd ki a hibás kulcshosszt (általában "1024") a helyes kulcshosszra (általában "1023").

2.7 - Az X11 és/vagy az ügynök továbbítás (Agent Forwarding) nem működik.

Ellenőrizd a saját ssh_config és sshd_config fájljaidat. Az alap konfigurációs fájlok nem engedélyezik az ügynök és X11 továbbítást. Az enedélyezéshez írd be a következőket az sshd_config fájlba:

X11Forwarding yes

és a következő sorokat az ssh_config fájlba:

ForwardAgent yes ForwardX11 yes

X11 továbbításhoz szükséges egy működő xauth(1) bináris. OpenBSD alatt ez az xbase fájl készletben van, de ez valószínűleg más platformokon különböző. OpenSSH Portable esetén az xauth vagy legyen megtalálható konfiguráláskor, vagy legyen beállítva az XAuthLocation segítségével az sshd_config(5) és a ssh_config(5) fájlokban.

Megjegyzés az ügynökök együttműködésével kapcsolatban: Kétféle különböző, és egymással nem kompatibilis ügynök továbbító mechanizmus létezik az SSH2 protokollban. Az OpenSSH mindig az eredeti SSH1 ügynök kéréseknek egy kiterjesztését használta, azonban sok kereskedelmi termék egy másfajta, nem szabad ügynök továbbító protokollt használ. Ez azt jelenti, hogy nem lehet ügynök továbbítást használni az OpenSSH és ezek között a termékek között.

MEGJEGYZÉS: Mandrake 7.2 Linux felhasználóknak. Mandrake megváltoztatta az XAUTHORITY környezeti változót az /etc/skel/.bashrc fájlban, és ezért minden bash felhasználó home katalógusában is. Ezt a változót az OpenSSH állítja be, és hogy a fenti opciók működjenek a következő sort ki kell kommentezni:

# export XAUTHORITY=$HOME/.Xauthority

2.8 - Az OpenSSH frissítése után elvesztettem az SSH2 támogatást.

A verziók között megváltozhat az sshd_config vagy az ssh_config. Mindig ellenőrizd ezeket a változásokat mielőtt frissíted az OpenSSH verziódat. Az OpenSSH 2.3.0 verziója után a következőket kell az sshd_config fájlhoz hozzáadni:

HostKey /etc/ssh_host_dsa_key HostKey /etc/ssh_host_rsa_key

2.9 - sftp/scp nem tud kapcsolódni, pedig az ssh rendben van.

sftp és/vagy scp lehet hogy képtelen kapcsolódni ha olyan héj (shell) inicializálást használsz (.profile, .bashrc, .cshrc, stb), amely nem-interaktív folyamatoknak ad valamilyen kimenetet. Ez a kimenet megzavarja az sftp/scp ügyfelet. Ellenőrizheted, hogy a shelled így viselkedik-e, a következő utasítással:

ssh sajáthost /usr/bin/true

Ha a fenti parancs ad kimenetet, akkor meg kell változtatnod a héj inicializációt.

2.10 - Adtok-e új szolgáltatásokat az scp-hez?

Hosszú válasz: az scp nem szabványos. A specifikációt valahogy úgy lehetne leírni, hogy "amit az rcp csinál". Mivel a kommunikáció mindkét oldalán ugyanazt a parancsot használják, ezért bármilyen új szolgáltatás vagy opció hozzáadása az együttműködést kockáztatná más implementációkkal.

Új szolgáltatások sokkal kívánatosabbak az sftp-ben, mivel ennek protokollja szabványosított (draft standard), kiterjeszthető, ezen kívül a kiszolgáló és az ügyfél szét van választva.

2.11 - Hogyan használjam a kapu továbbítást? (port forwarding)

Ha a távoli kiszolgálón fut az sshd(8), akkor lehetséges egy adott szolgáltatást ``becsövezni'' (tunnelling) az ssh-n keresztül. Ez kívánatos lehet például POP vagy SMTP kapcsolatok titkosítása esetén, habár maga a szoftver közvetlenül nem támogatja a titkosított kommunikációt. A tunnelling kapu továbbítást használ arra, hogy létrehozza a kapcsolatot a kliens és a kiszolgáló között. A kliens szoftvernek képesnek kell lennie arra, hogy meghatározzon egy nem szabványos kaput (port), amelyhez kapcsolódik.

Az elgondolás az, hogy a felhasználó az ssh segítségével csatlakozik a távoli kiszolgálóhoz, és meghatározza a kliens gépen azt a kaput, amelynek továbbítania kell a kapcsolatot a távoli kiszolgáló felé. Ezután már el lehet indítani azt a szolgáltatást, amelyet titkosítani szeretnénk (pl. fetchmail, irc) a kliens gépen, meghatározzuk ugyanazt a helyi kaput, amelyet átadtunk az ssh-nak, és így a forgalom egy biztonságos ssh alagúton fog haladni. Alapértelmezésben a továbbitást végrehajtó rendszer csak magától fogad el csatlakozást.

Főként a tunnellinggel kapcsolatos ssh opciók a -L és a -R, melyek segítségével a felhasználó továbbítani tudja a kapcsolatot, a -D opció, amely engedélyezi a dinamikus kaputovábbítást, a -g opció, mely engedélyez más hostokat, hogy használhassák a továbbítást és az -f opció, amely utasítja az ssh-t, hogy a háttérben fusson az authentikáció után. Nézd meg az ssh(1) man oldalt a további részletekért.

Az itt látható példa egy IRC kapcsolatot csövez a kliens gépről ``127.0.0.1'' (localhost) a távoli kiszolgálóra ``server.example.com'':

ssh -f -L 1234:server.example.com:6667 server.example.com sleep 10 irc -c '#users' -p 1234 pinky 127.0.0.1

Ez becsövez egy kapcsolatot a server.example.com IRC kiszolgálóra, joinol a ``#users'' csatornára, ``pinky'' becenévvel. A példában használt helyi kapu az 1234. Nem számít, hogy melyik kaput választjuk egészen addig, amíg nagyobb mint 1023 (mivel csak a root tud privilegizált kapura socketet nyitni) és amíg nem ütközik más, már használt kapukkal. A kapcsolat a távoli kiszolgáló 6667-es kapujára van továbbítva, mivel ez az IRC szabványos portja.

A ``sleep 10'' távoli parancs segítségével meghatározhatunk egy időtartamot (10 mp a példában) ami után indul el a csövezett szolgáltatás. Ha nem épül fel ez alatt az idő alatt a kapcsolat, akkor az ssh kilép. Ha több időre lenne szükség, akkor a sleep(1) értéket lehet növelni ennek megfelelően, vagy a fenti példát hozzá lehetne adni egy függvényként a felhasználó parancsértelmezőjéhez. Nézd meg a ksh(1) és csh(1) oldalakat a felhasználó által definiált függvények részletesebb leírásához.

Az ssh-nak van egy -N opciója, amely kényelmesebbé tesz a kaputovábbítást: ha -N meg van adva, akkor nem kell megadni távoli parancsot (``sleep 10'' a fenti példában), hanem ennek az opciónak az alkalmazásával az ssh végtelenségig vár (szemben azzal, hogy kilép miután a távoli parancs véget ért), ezért a felhasználónak kell manuálisan kilőnie a kill(1) segítségével.

2.12 - Az ssh kapcsolatom lefagy vagy kilép N perc inaktivitás után.

Ez általában annak az eredménye, hogy a csomagszűrő vagy NAT eszköz megszakítja időtúllépés (timeout) miatt a TCP kapcsolatot hosszabb idejű inaktivitás után. Engedélyezheted a ClientAliveInterval beállítást a kiszolgáló sshd_config fájljában, vagy a ServerAliveInterval beállítást az ügyfél ssh_config fájljában (ez utóbbi csak az OpenSSH 3.8 és újabb verziókban lehetséges).

Bármelyik opciót is állítod be, az értékét válaszd kisebbre mint a megszakítás (timeout) ideje. Ez biztosítja, hogy a kapcsolat "friss" maradjon az eszközök kapcsolat táblájában.

2.13 - Hogyan másoljak olyan fájlt scp segítségével, amelynek a nevében kettőspont található?

$ scp ./source:file sshserver:

2.14 - Az OpenSSH miért közli a verzióját a klienssel?

OpenSSH, ugyanúgy mint a legtöbb SSH megvalósítás, közli a nevét és verzióját a klienssel mikor kapcsolódnak.

SSH-2.0-OpenSSH_3.9

Ennek az információnak a segítségével tudnak a kliensek és a kiszolgálók engedélyezni olyan protokoll kompatibilitási opciókat, amelyekkel megkerülhetőek a megváltozott, hibás vagy hiányzó szolgáltatások abban a megvalósításban amellyel kommunikálnak. Ez a protokoll szolgáltatás ellenőrzés továbbra is szükséges, mivel az SSH protokollt még nem publikálták RFC formájában, és míg ez megtörténik addig is előfordulhatnak inkompatibilis változtatások.

3.0 - Portolható OpenSSH Kérdések

3.1 - Téves PAM autentikációs üzenetek a logfájlokban.

Az OpenSSH portolható verziója autentikációs hibákat generál minden bejelentkezéskor. Valami ehhez hasonlót:

"authentication failure; (uid=0) -> root for sshd service"

Ez azért van, mert az OpenSSH először megpróbálja meghatározni, hogy a felhasználónak autentikálnia kell-e a bejelentkezéshez (pl. üres jelszó). Sajnos a PAM szeret logolni minden autentikációs eseményt, köztük ezt is.

Ha ez nagyon zavar, akkor állítsd be az "PermitEmptyPasswords no" sort az sshd_config fájlban. Ez megszünteti ezt a hibaüzenetet annak árán, hogy nem engedélyezi az üres jelszavas bejelentkezéseket. Egyébként ez az alapbeállítás az sshd_config fájlban.

3.2 - Üres jelszavak nem engedélyezettek PAM autentikációval.

Az üres jelszavak engedélyezéséhez a PAM-mal fordított OpenSSH verziókban, hozzá kell adni a nullok flag-et a jelszóellenőrző modul végéhez az /etc/pam.d/sshd fájlban. Például:

auth required/lib/security/pam_unix.so shadow nodelay nullok

Ezen kívül be kell állítani a "PermitEmptyPasswords yes" sort az sshd_config fájlban.

Van egy hátránya az üres jelszavak használatának PAM autentikációban: PAM engedélyez bármilyen jelszót, ha egy olyan bejelentkezést autenkikál, amelynek üres a jelszava. Ez megtöri azt az ellenőrzést, amelyet az sshd(8) használ arra , hogy meghatározza vajon egy felhasználói fiókhoz nincs beállítva jelszó és engedélyezze a felhasználóknak a hozzáférést ehhez a fiókhoz függetlenül a PermitEmptyPasswords által meghatározott alapszabályt. Ebből az okból kifolyólag ajánlott, hogy ne add a nullok direktívát a PAM konfigurációs fájlodhoz, hacsak ténylegesen nem akarod engedélyezni az üres jelszavakat.

3.3 - ssh(1)-nak sokáig tart a csatlakozás vagy a bejelentkezés

Hosszú késlekedés (több mint 10 másodperc) általában névfeloldási hiba:

• A glibc néhány verziójának (elsősorban a Red Hat 6.1-gyel szállított glibc 2.1) sokáig tart amíg feloldja az "IPv6 és IPv4" címeket a tartománynevekből. Ezt ki lehet küszöbölni a AddressFamily inet opcióval az ssh_config fájlban.
• Lehet DNS kikeresési probléma, akár a kliensen, akár a kiszolgálón. Használd az nslookup programot mind a kliensen mind a kiszolgálón, hogy ki lehet-e keresni a másik oldal nevét és IP címét. Ezen kívül a kiszolgálón keresd vissza azt a nevet amit a kliens IP címének kikeresése adott vissza. Kikapcsolhatod a legtöbb kiszolgáló oldali kikeresést a UseDNS no beállításával a sshd_config fájlban.

10 másodpercnél rövidebb késlekedést más is okozhat.

• A 3.8 előtti OpenSSH kiadásoknak olyan moduli fájljuk volt, amelyben a moduli rövidebb volt mint amit az sshd keresett, ezért az sshd inkább egy olyan modulit használt, amely jelentősen nagyobb volt a szükségesnél, aminek sebességcsökkenés lett az ára. A moduli fájl lecserélése megoldhatja ezt (Figyelem! Általában ez a fájl nem cserélődik ki automatikusan frissítéskor, hanem manuálisan kell lecserélni).
• A 3.8 előtti OpenSSH kiadásokban volt egy hiba az ssh-ban, amely azt okozta, hogy a kért moduli nagyobb volt a kelleténél (amely a fenti problémával együtt már elég nagy lassulást eredményezhetett). A kliens 3.8 vagy annál újabb verzióra való frissítése megoldja a problémát.
• Ha vagy a kliens, vagy a kiszolgáló nem rendelkezik rendszermag alapú véletlen szám generátor eszközzel (pl. Solaris < 9, AIX < 5.2, HP-UX < 11.11) és nincs megfelelő helyettesítő (pl. prngd) akkor lehetséges, hogy az ssh-rand-helper által entrópia generálásra meghívott program megáll. Ezt debug módban meg lehet vizsgálni:

  /usr/local/libexec/ssh-rand-helper -vvv

  Minden jelentős késedelmet meg kell vizsgálni és javítani, vagy a megfelelő parancsot el kell távolítani a ssh_prng_cmds fájlból.

Mit is jelent az hogy "lassú"?

CPU	Idő (SSHv1)[1]	Idő (SSHv2)
170 MHz SPARC/sun4m	0.74 mp	1.25 mp
236 MHz HPPA/8200[2]	0.44 mp	0.79 mp
375 MHz PowerPC/604e	0.38 mp	0.51 mp
933 MHz VIA Ezra	0.34 mp	0.44 mp
2.1 GHz Althon XP 2600+	0.14 mp	0.22 mp

[1] Az SSHv1 protokoll gyorsabb, de gyengébb a titkosítása mint az SSHv2-nek.
[2] Az írás idejében a gcc meglehetősen lassú kódot készít HPPA-n az RSA és Diffie-Hellman műveletekhez (lásd: gcc bug #7625 és discussion on openssh-unix-dev).

3.4 - "Can't locate module net-pf-10" üzenet a logban Linux alatt.

A Linux rendszermag keresi a 10 protokoll családot (IPv6) a modprobe-on keresztül. Vagy töltsd be a megfelelő magmodult, írd be a helyes alias-t az /etc/modules.conf fájlba vagy kapcsold ki az IPv6-ot az /etc/modules.conf-ban.

Valamilyen fura okból bizonyos rendszerekben az /etc/modules.conf neve /etc/conf.modules.

3.5 - A jelszavas autentikáció nem működik (pl. Slackware 7.0 és Red Hat Linux 6.x alatt).

Ha a jelszó megfelelő, de a rendszer mégsem enged belépni, annak a legvalószínűbb oka, hogy be van állítva az MD5 tipusú jelszavak használata, viszont az ssh által használt crypt(3) függvény nem érti meg őket.

Az érintett fiókok (accountok) azok, amelyekben a jelszavak az /etc/passwd vagy az /etc/shadow fájlokban $1$ sztringgel kezdődnek. Ha egy újonnan létrehozott fiókkal vagy egy frissen megváltoztatott jelszóval nem lehetséges a jelszavas bejelentkezés, de a régebbi fiókokhoz működik, akkor feltehetően ez a hiba oka.

A problémát az okozza, hogy az OpenSSL bizonyos verzióiban levő crypt(3) függvény nem tudja értelmezni az MD5 jelszavakat. Az sshd linkelési sorrendje miatt az OpenSSL crypt(3) függvénye lesz használva a rendszeré helyett. Az OpenSSH configure megpóbálja javítani ezt de nem mindig sikerül.

Több megoldás is létezik:

• Engedélyezni kell az sshd beépített MD5 jelszó támogatását fordításkor.

  ./configure --with-md5-passwords [options]

  Biztonságos egyszerre használni mindkét algoritmust, mivel az sshd automatikusan kiválasztja a megfelelőt minden fiókhoz.

• Ha a rendszeredben különálló libcrypt könyvtár van (pl. Slackware 7), akkor manuálisan is hozzáadhatod a -lcrypt -et a LIBS listához, hogy az legyen használva az OpenSSL-é helyett:

  LIBS=-lcrypt ./configure [options]

• Ha a rendszered támogatja a PAM-ot, akkor beállíthatod az sshd-t hogy használja (lásd 3.15). Ez azt jelenti, hogy nem az sshd fogja ellenőrizni a jelszót, hanem átadja a beállított PAM moduloknak.

3.6 - Configure or sshd(8) panaszkodik az RSA vagy DSA támogatás hiánya miatt.

Az OpenSSL könyvtárnak tartalmaznia kell vagy az RSA vagy a DSA támogatást, vagy beépítve vagy az RSAref-en keresztül.

3.7 - "scp: command not found" (scp: parancs nem található) hiba

scp(1)-nek benne kell lennie a PATH-ban, mind a kiszolgálón mind az ügyfél gépen. Lehet, hogy szükséges a --with-default-path opció használata az egyedi elérési út meghatározásához a kiszolgálón. Ez az opció lecseréli az alapértelmezett elérési utat, így szükséges meghatározni minden más elérési utat is az scp elérési útján kívül. Például:

$ ./configure --with-default-path=/bin:/usr/bin:/usr/local/bin:/path/to/scp

Figyelj arra, hogy a kiszolgáló adminisztrátora általi konfiguráció felülbírálja a --with-default-path által beállított értéket. Ez magába foglalja az /etc/profile fájlban megadott PATH változó beállítását, ill. az /etc/environment fájlban megadott PATH változót AIX rendszeren, vagy (3.7p1 és a feletti) a PATH vagy SUPATH változót az /etc/default/login fájlban Solaris vagy Reliant Unix rendszereken.

3.8 - A jelmondat (passphrase) nem olvasható

Némelyik operációs rendszer a /dev/tty-t hibásan állítja be, ami azt okozza, hogy a jelszót nem lehet beolvasni és a következő hibaüzenet jelenik meg:

You have no controlling tty. Cannot read passphrase.

A megoldás, hogy a /dev/tty jogait be kell állítani 0666-ra és jelezni kell a hibát a rendszer szállítójának.

3.9 - 'configure' hiányzik vagy a make nem működik

Ha nincs "configure" fájl a letöltött tar.gz fájlban vagy a make leáll "missing separator" hibával, akkor valószínűleg az OpenBSD terjesztését töltötted le az OpenSSH-nak és más platformon próbálod lefordítani. Kérlek nézd meg a portable version oldalon található információt.

3.10 - Kilépéskor az ssh kiakad

OpenSSH kiakadhat kilépéskor. Ez akkor fordulhat elő, ha van még aktív háttérprocessz. Linuxon és HP-UX-on ismert ez a probléma, amit következőképpen tudunk leellenőrizni:

$ sleep 20 & exit

$ sleep 20 < /dev/null > /dev/null 2>&1 &

A probléma egyik megoldása bash felhasználóknak, hogy elhelyezik a "shopt -s huponexit" sort vagy az /etc/bashrc, vagy a ~/.bashrc fájlba. Egyéb esetben nézd meg a shell-ed kézikönyv oldalát, hogy kilépéskor mely opcióval lehet HUP szignált küldeni az aktív folyamatoknak. Nézd meg a bug #52 oldalt egyéb megoldásokért.

3.11 - Miért áll meg az ssh kilépéskor?

Ha lefuttatod az

$ ssh host parancs

• biztos benne, hogy a parancs nem vár több bemenetet.
• biztos benne, hogy a parancs nem ad több kimenetet.
• a parancs kilép, mivel az sshd át kell hogy adja a parancs kimeneti állapotát az ssh-nak.

3.12 - Frissítettem OpenSSH 3.1-ra és az X11 továbbítás többé nem működik.

Általában az X11 R6-ot használó X11 ügyfeleknek működniük kell az alapbeállítással. Néhány gyártó, többek közt a HP, az X11 ügyfeleit R6 és R5 könyvtárakkal (lib) szállítja, így bizonyos kliensek működnek, míg mások nem. Ez igaz a HP-UX 11.X-re.

3.13 - Frissítettem OpenSSH 3.8-ra és azóta néhány X11 program többé nem működik.

Ahogy ez dokumentálva van a 3.8 release notes fájlban, ssh már nem megbízható X11 sütiket (cookies) használ alapértelmezésben. A korábbi viselkedést a ForwardX11Trusted yes beállításával lehet elérni az ssh_config fájlban.

Ennek tünetei a következők lehetnek:
BadWindow (invalid Window parameter)
BadAccess (attempt to access private resource denied)
X Error of failed request: BadAtom (invalid Atom parameter)
Major opcode of failed request: 20 (X_GetProperty)


3.14 - Bemásoltam a nyilvános kulcsomat az authorized_keys fájlba, de a nyilvános kulcsú autentikáció még mindig nem működik.

Ebben az esetben a következő parancsokat kell futtatni a kiszolgálón:

$ chmod go-w $HOME $HOME/.ssh $ chmod 600 $HOME/.ssh/authorized_keys

Ha ez nem lehetséges valamilyen okból, akkor be lehet kapcsolni a StrictModes no beállítást a sshd_config-ban, de ez nem javasolt.

3.15 - OpenSSH verziók és a PAM viselkedése.

./configure --with-pam [options]

A lényeges autentikációs opciókat a következő táblázat foglalja össze:

Verzió	UsePAM	PasswordAuthentication	ChallengeResponseAuthentication
<=3.6.1p2	Nem alkalmazható	Használja a PAM-ot	Használja a PAM-ot ha PAMAuthenticationViaKbdInt engedélyezett
3.7p1 - 3.7.1p1	Alapérték yes-re	Nem használja a PAM-ot	Használja a PAM-ot ha UsePAM engedélyezett
3.7.1p2 - 3.8.1p1	Alapérték no-ra	Nem használja a PAM-ot[1]	Használja a PAM-ot ha UsePAM engedélyezett
3.9p1	Alapérték no-ra	Használja a PAM-ot ha UsePAM engedélyezett	Használja a PAM-ot ha UsePAM engedélyezett

[1] Néhány szállító, nevezetesen Redhat/Fedora, backportolta (beépítette a régebbi verzióba) a PasswordAuthentication-t a 3.9p1-ből a saját 3.8x alapú csomagjaiba. Ha a szállító által adott csomagot használsz, olvasd el a dokumentációt.

A hordozható OpenSSH PAM felületének még vannak problémái néhány modullal, azonban remélhetőleg ezeknek a száma csökkenni fog a jövőben. A 3.9p1 kiadás ismert problémái a következőek:

• Azok a modulok, amelyek a module-private adatot használják (pl. pam_dhkeys, pam_krb5, AFS), hibázhatnak a hitelesítő igazolások (credential) elkészítésekor(bug #688) amikor ChallengeResponseAuthentication segítségével autentikál. PasswordAuthentication működik a 3.9p1 verzióban és felette.

3.16 - A "w" és a "who" AIX 5.x alatt miért nem listázza ki az ssh-val belépett felhasználókat?