[OpenSSH]

OpenSSH FAQ (Veelgestelde vragen)

1.0 - Wat Is OpenSSH en Waar Kan Ik Het Krijgen?

2.0 - Algemene Vragen

3.0 - Portable OpenSSH Vragen

1.0 - Wat Is OpenSSH en Waar Kan Ik Het Krijgen?

1.1 - Wat is OpenSSH en waar kan ik het downloaden?

OpenSSH biedt een van begin tot eind versleutelde vervanging van applicaties zoals telnet, rlogin en ftp. In tegenstelling tot deze legacy applicaties stuurt OpenSSH nooit iets (inclusief gebruikersnaam en wachtwoord) over de lijn zonder encryptie en biedt het host-authenticatie om te verifiëren dat u echt praat met het systeem dat u denkt en dat niemand anders de sessie kan overnemen.

Het OpenSSH pakket bevat het ssh(1) programma dat rlogin en telnet vervangt en scp(1) dat rcp(1) en ftp(1) vervangt. OpenSSH heeft ook sftp(1) en sftp-server(8) toegevoegd die een makkelijkere oplossing bieden voor bestandsoverdracht. Het is gebaseerd op de secsh-filexfer IETF draft.

OpenSSH bestaat uit verschillende programma's.

Downloaden

De meeste recente versie van OpenSSH is opgenomen in de laatste distributie van OpenBSD en wordt geïnstalleerd als onderdeel van een basis-installatie.

Vandaag de dag hebben de meeste andere besturingssystemen een versie van OpenSSH (vaak hernoemd of gelabeld als 'eigen'), waardoor de meeste gebruikers het direct kunnen gebruiken. Echter, soms is de bijgevoegde versie tamelijk oud en ontbreken er functies van de huidige versie van OpenSSH en wilt u de huidige versie installeren, of u wilt het installeren op één van de weinige besturingssystemen waar het ontbreekt en waar de OS-uitgever geen modere versie beschikbaar stelt. U wilt wellicht ook OpenSSH gebruiken in uw embedded applicatie.

Niet-OpenBSD gebruikers zullen de multi-platform Portable distributie wilen downloaden, compileren en installeren vanaf een mirror bij u in de buurt.

1.2 - Waarom zou het gebruikt moeten worden?

OpenSSH is een pakket van programma's om uw netwerkverbindingen te beveiligen. Hier is een lijst met functionaliteiten:

Op dit moment wordt bijna alle communicatie in computernetwerken zonder encryptie uitgevoerd. Het gevolg hiervan is dat iedereen die toegang heeft tot een machine op het netwerk alle communicatie kan afluisteren. Dit wordt gedaan door hackers, nieuwsgierige beheerders, werkgevers, criminelen, industriële spionnen en overheden. Sommige netwerken lekken genoeg elektromagnetische straling zodat de data zelfs vanop een afstand opgevangen kan worden.

Wanneer u inlogt, wordt uw wachtwoord als gewone tekst over het netwerk verzonden. Op die manier kan iedere luisteraar uw account gebruiken om te doen wat hij wil. Er zijn wereldwijd vele incidenten voorgekomen waar crackers programma's op werkstations hebben gestart zonder dat de eigenaars ervan wisten enkel om naar het netwerk te luisteren en wachtwoorden te verzamelen. Programma's om dit te doen zijn via Internet beschikbaar of kunnen door een kundige programmeur in een paar uur gebouwd worden.

Bedrijven hebben bedrijfsgeheimen, patentaanvragen in opmaak, prijsinformatie, informatie over toeleveranciers, klantgegevens, personeelsgegevens, financiële gegevens, enz. Op dit moment kan iedereen met toegang tot het netwerk (elke machine op het netwerk) luisteren naar alles wat zich op het netwerk afspeelt zonder gehinderd te worden door normale toegangsbeperkingen.

Veel bedrijven zijn zich niet bewust van het gemak waarmee informatie via het netwerk verkregen kan worden. Ze vertrouwen erop dat hun gegevens veilig zijn aangezien niemand kan weten dat er gevoelige informatie over het netwerk verzonden wordt of omdat er zoveel meer gegevens op het netwerk aanwezig zijn. Dit is geen veilig beleid.

1.3 - Welke besturingssystemen worden ondersteund?

Ook al wordt OpenSSH ontwikkeld op OpenBSD, er bestaan veel verschillende ports naar andere besturingssystemen. De portable versie van OpenSSH wordt geleid door Damien Miller. Zie voor een vluchtig overzicht van de portable versie van OpenSSH OpenSSH Portable Uitgave. Op dit ogenblik worden de volgende besturingssystemen ondersteund:

Een lijst met leveranciers die OpenSSH in hun distributie opnemen is te vinden op de OpenSSH Gebruikers pagina.

1.4 - Hoe zit het met auteursrecht, gebruik en patenten?

De ontwikkelaars van OpenSSH hebben erg hard geprobeerd om OpenSSH vrij van patenten of auteursrechtproblemen te houden. Hiervoor moesten sommige opties van OpenSSH verwijderd worden. Namelijk ondersteuning voor gepatenteerde algoritmen.

OpenSSH ondersteunt geen gepatenteerde transportalgoritmen. In SSH1-modus zijn alleen DES en Blowfish beschikbaar als opties. In SSH2-modus kan alleen gekozen worden uit 3DES, Blowfish, CAST128, Arcfour en AES. Het gepatenteerde IDEA-algoritme wordt niet ondersteund.

OpenSSH heeft ondersteuning voor de protocollen SSH1 en SSH2.

Sinds het patent op RSA verlopen is, zijn er geen beperkingen op het gebruik van software die RSA gebruikt, inclusief OpenBSD.

1.5 - Waar kan ik hulp krijgen?

Er zijn veel plaatsen waar u hulp kunt krijgen. Naast de website van OpenSSH, zijn er veel mailinglijsten die het proberen waard zijn. Voordat u een mailinglijst probeert, zoek eerst alle archieven van de mailinglijsten door om te kijken of uw vraag al beantwoord is. De OpenSSH Mailinglijst is gearchiveerd en in zoekbare vorm gegoten en kan gevonden worden op marc.info.

Voor meer informatie over het aanmelden bij OpenSSH-gerelateerde mailinglijsten, zie OpenSSH Mailinglijsten.

1.6 - Ik heb een probleem gevonden. Waar meld ik dit?

Informatie over het inzenden van foutmeldingen kunnen op de OpenSSH Probleemmeldingen pagina gevonden worden.

Indien u een veiligheidsprobleem wilt melden, neem dan contact op met de besloten mailinglijst van de ontwikkelaars <openssh@openssh.com>.

2.0 - Algemene Vragen

2.1 - Waarom maakt ssh/scp verbindingen vanaf lage poorten?

De OpenSSH-client maakt gebruik van lage poorten voor de authenticate bij rhosts en rhosts-rsa omdat de server de gebruikersnaam die de client opgeeft moet vertrouwen. Om dit te voorkomen kunt u onderstaand voorbeeld in de bestanden ssh_config of ~/.ssh/config plaatsen.

UsePrivilegedPort no

Of u kunt deze optie vanaf de prompt instellen met het -o argument van het ssh(1) commando.

$ ssh -o "UsePrivilegedPort no" host.com

2.2 - Waarom is de ssh-client setuid root?

Net zoals bij de vorige vraag (2.1) heeft OpenSSH root-rechten nodig om lage poorten te gebruiken voor rhosts-authenticatie. Een bevoorrechte poort is ook nodig voor rhosts-rsa authenticatie bij oudere SSH-versies.

Daarnaast heeft de ssh-client voor zowel rhosts-rsa authenticatie (in protocolversie 1) en hostgebaseerde authenticatie (in protocolversie 2) toegang nodig tot de private hostsleutel om de client te authentiseren bij de server. Voor versies van OpenSSH ouder dan 3.3 moest de ssh binary setuid root zijn en u kunt dit verwijderen als u deze authenticatiemethodes niet wilt gebruiken.

Vanaf OpenSSH 3.3 is ssh niet standaard setuid. Voor de toegang tot de private hostsleutel wordt ssh-keysign gebruikt en ssh gebruikt standaard geen gepriviligeerde bronpoorten. Als u een gepriviligeerde bronpoort wilt gebruiken moet u handmatig de setuid bit op ssh aanzetten.

2.3 - Waarom heeft SSH 2.3 problemen met OpenSSH 2.1.1?

SSH 2.3 en eerdere versies hebben een fout in hun HMAC-implementatie. Hun code gaf niet de volledige datablokuitvoer van de digest en produceerde in plaats daarvan altijd 128 bits. Dit zorgde ervoor dat met langere digests SSH 2.3 niet werkte met OpenSSH.

OpenSSH 2.2.0 ontdekt dat SSH 2.3 deze fout bevat. Recente versies van SSH hebben deze fout opgelost. Of u kunt het volgende toevoegen aan de sshd2_config van SSH 2.3.

Mac hmac-md5

2.4 - Waarom print OpenSSH: Dispatch protocol error: type 20

Problemen in de onderlinge werking zijn waargenomen omdat oudere versies van OpenSSH het verwisselen van session keys niet ondersteunde. Echter de commerciële SSH 2.3 probeert deze functionaliteit uit te voeren, uw verbinding kan bevriezen of u krijgt de foutmelding "Dispatch protocol error: type 20". Om dit probleem op te lossen kunt u upgraden naar een recente uitgave van OpenSSH of verwisseling van sleutels uitschakelen door het volgende in ssh2_config of sshd2_config van uw commerciële SSH 2.3 te zetten.

RekeyIntervalSeconds 0

2.5 - Oude versies van de commerciële SSH versleutelen hostsleutels met IDEA.

De oude versies van SSH gebruikten een gepatenteerd algoritme om hun /etc/ssh/ssh_host_key te versleutelen. Hierdoor kan sshd(8) zijn hostsleutel niet lezen. Gebruik het onderstaand commando om uw ssh_host_key 3DES te laten gebruiken om dit op te lossen. N.B.: gebruik voor onderstaand voorbeeld het ssh-keygen(1) programma van het Commerciële SSH produkt, *NIET* OpenSSH.

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

2.6 - Wat zijn die waarschuwingen over sleutellengtes?

Het ssh-keygen(1) programma van de commerciële SSH bevat een bug die soms zorgde voor Pubkey Authenticatiesleutels (RSA of DSA) waar de Meest Significante Bit (MSB) niet ingesteld was. Zulke sleutels leken de gehele lengte te hebben, maar zijn in werkelijkheid de helft van de tijd kleiner dan aangenomen wordt.

OpenSSH zal waarschuwingen geven wanneer het een dergelijke sleutel tegenkomt. Wijzig uw known_hosts bestanden en vervang de ongeldige sleutellengte (meestal "1024") door de juiste sleutellengte (gewoonlijk "1023") om van deze foutmelding af te komen.

2.7 - X11 en/of agent forwarding werkt niet.

Controleer uw ssh_config en sshd_config. De standaardconfiguratie schakelt forwarding van de authentication agent en X11 uit. Plaats de volgende regel in uw sshd_config om het aan te zetten:

X11Forwarding yes

en plaats de volgende regels in ssh_config:

ForwardAgent yes
ForwardX11 yes

X11 forwarding vereist een werkende xauth(1) binary. Op OpenBSD zit deze in de xbase bestandenset maar dit zal waarschijnlijk verschillend zijn op andere platformen. Voor OpenSSH Portable moet xauth ofwel gevonden worden tijdens configure ofwel gespecificeerd via XAuthLocation in sshd_config(5) en ssh_config(5).

Opmerking over agent interoperabiliteit: Er zijn twee verschillende en niet-compatibele agent forwarding mechanismes binnen het SSH2 protocol. OpenSSH heeft altijd een uitbreiding van de originele SSH1 agent aanvragen gebruikt, bepaalde commerciële producten gebruiken echter een verschillend, niet-vrij agent forwarding protocol. Dit betekent dat agent forwarding niet kan gebruikt worden tussen OpenSSH en die producten.

N.B.: Voor gebruikers van Linux Mandrake 7.2, Mandrake wijzigt de XAUTHORITY omgevingsvariabele in /etc/skel/.bashrc en hierdoor in de home directory van elke bash-gebruiker. Deze variabele wordt ingesteld door OpenSSH en om beide opties te laten werken moet u van de volgende lijn een commentaarregel maken:

# export XAUTHORITY=$HOME/.Xauthority

2.8 - Na het upgraden van OpenSSH heb ik geen ondersteuning meer voor SSH2.

Tussen versies kunnen wijzigingen aangebracht zijn in sshd_config of ssh_config. U kunt het beste bij het upgraden van OpenSSH-versies altijd deze wijzigingen controleren. Na OpenSSH versie 2.3.0 moet u het volgende aan uw sshd_config toevoegen:

HostKey /etc/ssh_host_dsa_key
HostKey /etc/ssh_host_rsa_key

2.9 - sftp/scp faalt bij het maken van een verbinding, maar ssh werkt OK.

sftp en/of scp kunnen falen bij het maken van de verbinding als uw shellinitialisatie (.profile, .bashrc, .cshrc, etc) uitvoer produceert voor niet-interactieve sessies. Deze uitvoer is verwarrend voor de sftp/scp-client. U kunt controleren of uw shell dit doet door het volgende uit te voeren:

ssh yourhost /usr/bin/true

Als bovenstaand commando uitvoer produceert moet u uw shellinitialisatie aanpassen.

2.10 - Kan [foo] worden toegevoegd aan scp?

In het kort: nee.

Uitgebreid: scp is niet gestandardiseerd. De specificatie kan nog het best omschreven worden als "dat wat rcp doet". Aangezien het commando door beide kanten van de verbinding gebruikt wordt kunnen er bij het toevoegen van mogelijkheden of opties problemen ontstaan met de interoperabiliteit met andere implementaties.

Het is waarschijnlijker dat nieuwe mogelijkheden worden toegevoegd aan sftp, omdat het protocol gestandaardiseerd is (tenminste, een draft standaard), uitbreidbaar, en de client en server ontkoppeld zijn.

2.11 - Hoe gebruik ik port forwarding?

Als de remote server sshd(8) gebruikt is het mogelijk om bepaalde services te ``tunnelen'' via ssh. Dit kan bijvoorbeeld gebruikt worden om POP- of SMTP-verbindingen te versleutelen ook al heeft de software geen ondersteuning voor versleutelde verbindingen. Tunnelen gebruikt port forwarding om een verbinding te maken tussen de client en de server. Hiervoor moet de client software in staat zijn een niet-standaard poort op te geven om een verbinding naar te maken.

De idee is dat de gebruiker met ssh een verbinding maakt met de remote host en opgeeft welke poort op de machine van de client gebruikt moet worden om verbindingen naar de remote server door te sturen. Daarna is het mogelijk om op de machine van de client de service te starten die versleuteld moet worden (b.v. fetchmail, irc) en hier de poort op te geven die aan ssh is doorgegeven en de verbinding wordt door ssh getunneld. Standaard zal het systeem dat aan forwarding doet, alleen verbindingen vanwege zichzelf aanvaarden.

De meest relevante opties voor tunnelen zijn de -L en -R opties, waarmee de gebruiker verbindingen kan doorsturen, de -D optie, waarmee dynamische poort forwarding mogelijk is, de -g optie, die andere hosts toelaat om port forwarding te gebruiken, en de -f optie, die ssh zegt zichzelf naar de achtergrond te plaatsen na authenticatie. Zie de ssh(1) man pagina voor verdere details.

Dit is een voorbeeld van het tunnelen van een IRC-sessie van de client machine ``127.0.0.1'' (localhost) naar de remote server ``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

Hier wordt een verbinding naar IRC-server server.example.com getunneld en kanaal ``#users'' gejoind met de gebruikersnaam ``pinky''. De lokale poort die in dit voorbeeld wordt gebruikt is 1234. Het maakt niet uit welke poort wordt gebruikt, zolang ze maar groter is dan 1023 (alleen root kan sockets openen op bevoorrechte poorten) en geen conflict veroorzaakt met de poorten die al in gebruik zijn. De verbinding wordt doorgestuurd naar poort 6667 van de remote server, angezien dat de standaard poort voor IRC-diensten is.

Het commando ``sleep 10'' wordt gebruikt om een bepaalde tijdsduur toe te laten (in het voorbeeld 10 seconden) om de dienst te starten die moet worden getunneld. Als er geen verbindingen gemaakt worden binnen de opgegeven tijd zal ssh afsluiten. Als meer tijd nodig is kan de waarde van sleep(1) daarvoor verhoogd worden of anders kan het voorbeeld hierboven toegevoegd worden als een functie van de shell van de gebruiker. Zie ksh(1) en csh(1) voor meer details over gebruikersgedefinieerde functies.

ssh heeft ook een -N optie, welke handig is m te gebruiken met port forwarding: als -N wordt opgegeven is het niet nodig om een remote commando op te geven (in het voorbeeld hierboven ``sleep 10''). Deze optie zorgt er echter voor dat ssh voor altijd blijft draaien (in plaats van af te sluiten na het remote commando voltooid is), en de gebruiker moet achteraf het proces handmatig afsluiten met kill(1).

2.12 - Mijn ssh-verbinding loopt vast of wordt afgesloten na N minuten inactiviteit.

Dit komt meestal doordat een packet filter of NAT-apparaat je TCP-verbinding laat verlopen vanwege inactiviteit. Je kan ClientAliveInterval in de sshd_config van de server aanzetten, of ServerAliveInterval in de ssh_config van de client (laatstgenoemde is in OpenSSH 3.8 en nieuwer beschikbaar).

Door één van de opties aan te zetten en het interval in te stellen op een periode korter dan de tijdsduur waarna de sessie wordt afgesloten zorg je ervoor dat de verbinding in de verbindingstabel van het apparaat "vers" blijft.

2.13 - Hoe kan ik met scp een bestand met een dubbele punt kopiëren?

scp zal het gedeelte voor de dubbele punt interpreteren als de naam van een server en er verbinding mee proberen te maken. Verwijs om dit te voorkomen naar het bestand via een relatieve of absolute padnaam, bijv:
$ scp ./bron:bestand sshserver:

2.14 - Waarom meldt OpenSSH z'n versienummer aan clients?

Zoals de meest SSH-implementaties meldt OpenSSH z'n naam en versie aan clients zodra deze verbinding maken, bv.

SSH-2.0-OpenSSH_3.9

Deze informatie wordt gebruikt door clients en servers om aanpassingen te doen voor protocolcompatibiliteit om langs gewijzigde, slecht werkende of niet aanwezige functionaliteiten in de implementatie heen te werken waartegen ze praten. Het is op dit ogenblik nog steeds nodig om het protocol te kunnen controleren omdat versies met incompatibiliteiten nog steeds veel in gebruik zijn.

3.0 - Portable OpenSSH Vragen

3.1 - Valse PAM-authenticatieberichten in logbestanden.

De portable versie van OpenSSH genereert valse authenticatieberichten bij elke login, bijvoorbeeld:

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

Deze worden gegenereerd omdat OpenSSH eerst kijkt of een gebruiker authenticatie nodig heeft bij het aanmelden (b.v. leeg wachtwoord). Helaas logt PAM alle authenticatiepogingen, inclusief deze.

Als u zich er aan ergert kunt u "PermitEmptyPasswords no" in sshd_config zetten. Dit verwijdert de foutmelding maar het is niet meer mogelijk in te loggen met accounts zonder wachtwoord. Dit is de standaardinstelling in het bijgeleverde sshd_config bestand.

3.2 - Lege wachtwoorden niet toegestaan met PAM-authenticatie.

Om lege wachtwoorden aan te zetten met een versie van OpenSSH met PAM moet u de optie nullok toevoegen aan het eind van de de wachtwoordcontrolemodule in het bestand /etc/pam.d/sshd. Bijvoorbeeld:

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

Dit moet gedaan worden naast het instellen van "PermitEmptyPasswords yes" in het bestand sshd_config.

Er zit een addertje onder het gras bij het gebruik van lege wachtwoorden met PAM-authenticatie: PAM zal elk wachtwoord goedkeuren wanneer een account met een leeg wachtwoord authentiseert. Dit breekt de controle die sshd(8) gebruikt om vast te stellen of een account geen wachtwoord ingesteld heeft en geeft gebruikers toegang tot de account ongeacht de waarde van PermitEmptyPasswords. Hierom is het aan te raden dat u niet de nullok optie toevoegt aan uw PAM-configuratiebestand tenzij u specifiek lege wachtwoorden wilt toelaten.

3.3 - ssh(1) doet lang over de totstandkoming van de verbinding of het inloggen

Grote vertragingen (meer dan 10 seconden) worden gewoonlijk veroorzaakt door een probleem met de naamresolutie:

Vertragingen kleiner dan 10 seconden kunnen andere oorzaken hebben.

Hoe traag is "traag"?

Onder normale omstandigheden is de snelheid van SSH-logins afhankelijk van de snelheid van de CPU van de client en de server. Ter vergelijking zijn dit typische tijden om een verbinding te maken voor time ssh localhost true met een 1024-bit RSA sleutel op hosts die verder geen andere load hebben. OpenSSH en OpenSSL werden gecompileerd met gcc 3.3.x.

CPUTijd (SSHv1)[1] Tijd (SSHv2)
170MHz SPARC/sun4m0.74 sec1.25 sec
236MHz HPPA/8200[2]0.44 sec 0.79 sec
375MHz PowerPC/604e0.38 sec0.51 sec
933MHz VIA Ezra0.34 sec0.44 sec
2.1GHz Athlon XP 2600+0.14 sec0.22 sec

[1] Het SSHv1-protocol is sneller maar cryptografisch zwakker dan SSHv2.
[2] Rond de tijd van schrijven genereerde gcc relatief langzame code op HPPA voor RSA en Diffie-Hellman operaties (zie gcc bug #7625 en discussie op openssh-unix-dev).

3.4 - "Can't locate module net-pf-10" berichten in de log onder Linux.

De Linux kernel zoekt (via modprobe) naar protocolfamilie 10 (IPv6). Laad de juiste kernelmodule, voeg de juiste alias in in /etc/modules.conf of schakel IPv6 uit in /etc/modules.conf.

Om een of andere maffe reden kan /etc/modules.conf ook /etc/conf.modules heten.

3.5 - Wachtwoordauthenticatie werkt niet (bv. onder Slackware 7.0 of Red Hat 6.x)

Indien het wachtwoord juist is en de login nog steeds verboden wordt, is de gewoonlijke oorzaak dat het systeem geconfigureerd is om MD5-type wachtwoorden te gebruiken maar de crypt(3) functie gebruikt door sshd begrijpt ze niet.

Getroffen accounts zullen wachtwoord-strings hebben in /etc/passwd of /etc/shadow die beginnen met $1$. Indien wachtwoordauthenticatie mislukt voor nieuwe accounts of accounts met recent veranderde wachtwoorden, maar wel werkt voor oude accounts, is dit de waarschijnlijke boosdoener.

De onderliggende oorzaak is dat bepaalde versies van OpenSSL een crypt(3) functie hebben die MD5 wachtwoorden niet begrijpt, en de linkvolgorde van sshd betekent dat OpenSSL's crypt(3) gebruikt wordt in plaats van die van het systeem. OpenSSH's configure poogt dit te corrigeren maar dit heeft niet altijd succes.

Er zijn verscheidene mogelijke oplossingen:

3.6 - Configure of sshd(8) zeurt over een gebrek aan ondersteuning voor RSA of DSA

Controleer of uw OpenSSL-bibliotheken gecompileerd zijn om RSA of DSA te ondersteunen, intern of via RSAref.

3.7 - "scp: command not found" foutmeldingen

scp(1) moet in het standaard PATH voorkomen op zowel de client als de server. U moet wellicht de optie --with-default-path gebruiken om een ander pad op te geven om op de server te doorzoeken. Deze optie vervangt het standaardpad, dus u moet alle huidige directories op uw pad aangeven naast de plek waar u scp heeft geinstalleerd. Bijvoorbeeld:

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

Merk op dat de configuratie van de beheerder van de server de voorkeur krijgt over de instelling --with-default-path. Dit kan via een wijziging van PATH in /etc/profile, PATH in /etc/environment op AIX, of (voor 3.7p1 en nieuwer) PATH of SUPATH in /etc/default/login op Solaris of Reliant Unix.

3.8 - Kan de passphrase niet lezen

Sommige besturingssystemen stellen /dev/tty in met verkeerde modes, waardoor wachtwoorden niet kunnen worden ingelezen door de volgende foutmelding:

You have no controlling tty. Cannot read passphrase.

De oplossing is om de permissies van /dev/tty op 0666 te zetten en deze fout te melden bij uw besturingssysteemleverancier.

3.9 - 'configure' ontbreekt of make faalt

Als er geen 'configure' bestand is in het tar.gz-bestand dat u gedownload heeft of make faalt met "missing separator" foutmeldingen, heeft u waarschijnlijk de OpenBSD-distributie van OpenSSH gedownload en probeert u deze te compileren op een ander platform. Zie de informatie over de portable versie.

3.10 - Hangt bij het afsluiten van ssh

OpenSSH kan hangen bij het afsluiten. Dit kan voorkomen wanneer een proces actief is in de achtergrond. Het kan voorkomen op Linux en HP-UX. Het probleem kan geverifieerd worden door het volgende uit te voeren:

$ sleep 20 & exit
Probeer in plaats daarvan dit te gebruiken:
$ sleep 20 < /dev/null > /dev/null 2>&1 &

Een alternatief voor gebruikers van bash is om "shopt -s huponexit" in /etc/bashrc of ~/.bashrc te zetten. Raadpleeg anders de man pagina van uw shell voor een optie om een HUP-signaal te sturen naar een actieve taak bij het afsluiten. Zie bug #52 voor andere tijdelijke oplossingen.

3.11 - Waarom hangt ssh bij het stoppen?

Wanneer

$ ssh host commando
uitgevoerd wordt moet ssh hangen, want het moet wachten:

3.12 - Ik deed een upgrade naar OpenSSH 3.1 en X11-forwarding werkt niet meer.

Vanaf OpenSSH 3.1 luistert de sshd X11-forwarding server standaard op localhost; zie de optie X11UseLocalhost van sshd om terug te schakelen naar het oude gedrag als uw oudere X11-clients niet werken met deze configuratie.

Over het algemeen zouden X11-clients die X11-R6 gebruiken moeten werken met de standaardinstelling. Sommige distributeurs, inclusief HP, leveren X11-clients met R6- en R5-libs, dus sommige clients zullen wel werken en anderen niet. Dit geldt voor HP-UX 11.X.

3.13 - Ik deed een upgrade naar OpenSSH 3.8 en sommige X11-programma's werken niet meer.

Zoals vermeld wordt in de 3.8 release notes, gebruikt ssh nu standaard niet-vertrouwde X11-cookies. Het vorige gedrag kan teruggehaald worden door ForwardX11Trusted yes in ssh_config te zetten.

Mogelijke symptomen zijn onder andere:
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 - Ik kopieerde mijn publieke sleutel naar authorized_keys maar publieke-sleutelauthenticatie werkt nog steeds niet.

Dit komt meestal doordat de permissies van $HOME, $HOME/.ssh of $HOME/.ssh/authorized_keys toegankelijker zijn dan sshd ze standaard toelaat te zijn.

Dit kan opgelost worden door het volgende op de server uit te voeren.

$ chmod go-w $HOME $HOME/.ssh
$ chmod 600 $HOME/.ssh/authorized_keys
$ chown `whoami` $HOME/.ssh/authorized_keys

Als dit om een of andere reden niet mogelijk is kunt u als alternatief StrictModes no in sshd_config zetten, maar dit wordt niet aangeraden.

3.15 - OpenSSH versies en PAM gedrag.

Portable OpenSSH heeft een configuratie-optie om sshd's gebruik van de PAM (Pluggable Authentication Modules) interface in te schakelen.
./configure --with-pam [opties]
Om PAM überhaupt te gebruiken, moet deze optie meegegeven worden bij het bouwen. Het run-time gedrag wanneer PAM ingebouwd is, varieert met de versie van Portable OpenSSH, en bij latere versies moet het ook ingeschakeld worden door UsePAM op yes in te stellen in sshd_config.

Het gedrag van de relevante authenticatie-opties wanneer PAM ondersteuning ingebouwd is, wordt samengevat in de volgende tabel.

Versie UsePAM PasswordAuthentication ChallengeResponseAuthentication
<=3.6.1p2 Niet van toepassing Gebruikt PAM Gebruikt PAM als PAMAuthenticationViaKbdInt ingeschakeld is
3.7p1 - 3.7.1p1 Standaard yes Gebruikt PAM niet Gebruikt PAM als UsePAM ingeschakeld is
3.7.1p2 - 3.8.1p1 Standaard no Gebruikt PAM niet [1] Gebruikt PAM als UsePAM ingeschakeld is
3.9p1 Standaard no Gebruikt PAM als UsePAM ingeschakeld is Gebruikt PAM als UsePAM ingeschakeld is

[1] Bepaalde verkopers, met name Redhat/Fedora, hebben de PasswordAuthentication van 3.9p1 naar hun 3.8x gebaseerde packages gebackported. Indien u een door de verkoper geleverde package gebruikt, raadpleeg dan hun documentatie.

OpenSSH Portable's PAM interface heeft nog steeds problemen met een aantal modules, we hopen echter dat dit aantal in de toekomst zal dalen. Bij de 3.9p1 release zijn de gekende problemen:

U kan ook bugzilla voor huidige PAM problemen nakijken.

3.16 - Waarom toont "w" of "who" op AIX 5.x geen gebruikers die via ssh zijn ingelogd?

Tussen AIX 4.3.3 en AIX 5.x veranderde het formaat van de wtmp struct. Dit betekent dat sshd binaries gebouwd op AIX 4.x wtmp entries niet juist zullen schrijven indien ze op AIX 5.x draaien. Dit kan opgelost worden door gewoon sshd te hercompileren op een AIX 5.x systeem en die te gebruiken.
OpenSSH www@openbsd.org
$OpenBSD: faq.html,v 1.34 2012/04/21 22:25:30 ajacoutot Exp $