Waarom is mijn SSH login traag?

Probeer UseDNS in no of /etc/sshd_config in te stellen.

Toen ik ssh -vvv draaide op een server met een soortgelijke trage performance zag ik hier een hang:

debug1: Next authentication method: gssapi-with-mic

Door /etc/ssh/ssh_config te bewerken en die authenticatie methode uit te sluiten kreeg ik de login prestaties weer normaal. Dit is wat ik in mijn /etc/ssh/ssh_config op de server heb staan:

GSSAPIAuthentication no

Je kunt dit globaal op de server instellen, zodat hij geen GSSAPI accepteert om te authenticeren. Voeg gewoon GSSAPIAuthentication no toe aan /etc/ssh/sshd_config op de server en herstart de service.

Bij mij was IPv6 resolutie de boosdoener, het was aan het timen. (Slechte DNS instelling bij mijn host provider, denk ik.) Ik ontdekte dit door ssh -v te doen, wat liet zien welke stap er hing.

De oplossing is om ssh te doen met de -4 optie:

ssh -4 me@myserver.com

Met systemd, kan inloggen hangen op dbus communicatie met logind na sommige upgrades, dan moet je logind herstarten

systemctl restart systemd-logind

Zag dat op debian 8, arch linx, en op een suse lijst

Je kunt altijd ssh starten met de -v optie die weergeeft wat er op dat moment wordt gedaan.

$ ssh -v you@host

Met de informatie die je gaf kan ik alleen maar wat client side configuraties voorstellen:

• Aangezien je schrijft dat je wachtwoorden handmatig invoert, zou ik willen voorstellen dat je, indien mogelijk, publieke sleutel authentificatie gebruikt. Dit verwijdert u als een snelheid knelpunt.

• Je zou ook X-forwarding met -x en authentication forwarding met -a kunnen uitschakelen (deze zijn misschien al standaard uitgeschakeld). Vooral het uitschakelen van X-forwarding kan je een grote snelheidsverbetering geven als je client een X-server moet starten voor het ssh commando (bijv. onder OS X).

Al het andere hangt echt af van wat voor vertragingen je waar en wanneer ondervindt.

Wat betreft punt 2., hier is een antwoord waarvoor je de server niet hoeft aan te passen en waarvoor je geen root/administrative rechten nodig hebt.

Je moet je “user ssh_config” bestand bewerken dat is:

vi $HOME/.ssh/config

(Opmerking: je moet de directory $HOME/.ssh aanmaken als die niet bestaat)

En voeg toe:

Host *
  GSSAPIAuthentication no
  GSSAPIDelegateCredentials yes

Je kunt dit per host doen als dat nodig is :) voorbeeld:

Host linux-srv
  HostName 192.158.1.1
  GSSAPIAuthentication no
  GSSAPIDelegateCredentials yes

Zorg ervoor dat het IP adres overeenkomt met het IP van je server. Een cool voordeel is dat ssh nu autocomplete zal bieden voor deze server. Dus je kunt ssh lin + Tab typen en het zou automatisch moeten aanvullen tot ssh linux-srv.

Controleer /etc/resolv.conf op de server om er zeker van te zijn dat de DNS server, vermeld in dit bestand, goed werkt, en verwijder alle niet-werkende DNS.

Soms is dat erg nuttig.

Naast de DNS problemen die reeds vermeld werden, als u ssh’t op een server met veel NFS mounts, kan er een vertraging zijn tussen het paswoord en de prompt omdat het quota commando uw gebruik/quota controleert op alle bestandssystemen die niet gemount zijn met de noquota. Op Solaris systemen kunt u dit zien in de standaard /etc/profile en het overslaan door touch $HOME/.hushlogin uit te voeren.

Als geen van de bovenstaande antwoorden werkt en je hebt problemen met dns reverse lookup, dan kun je ook controleren of nscd (name service cache daemon) geïnstalleerd is en draait.

Als dit het probleem is, dan komt dat omdat je geen dns cache hebt, en iedere keer dat je een hostnaam opvraagt die niet in je hostfile staat, stuur je de vraag naar je naamserver in plaats van in je cache te kijken

Ik heb alle bovenstaande opties geprobeerd en de enige verandering die werkte was het starten van nscd.

Je moet ook de volgorde controleren om dns query resolutie in /etc/nsswitch.conf te maken om eerst hosts file te gebruiken.

Dit is waarschijnlijk alleen specifiek voor de Debian/Ubuntu OpenSSH, die de user-group-modes.patch bevat die geschreven is door een van de Debian package-beheerders. Deze patch staat toe dat de ~/.ssh bestanden de schrijfbare bit van de groep ingesteld krijgen (g+w) als er slechts één gebruiker is met dezelfde gid als die van het bestand. De secure_permissions() functie van de patch doet deze controle. Eén van de fasen van de controle is om door elke passwd entry te gaan met getpwent() en de gid van de entry te vergelijken met de gid van het bestand.

Op een systeem met veel entries en/of trage NIS/LDAP authenticatie zal deze controle traag zijn. nscd slaat getpwent() aanroepen niet op in een cache, dus elke passwd entry zal over het netwerk gelezen worden als de server niet lokaal is. Op het systeem waar ik dit aantrof, voegde het ongeveer 4 seconden toe voor elke aanroep van ssh of inloggen op het systeem.

De oplossing is om de schrijfbare bit te verwijderen van alle bestanden in ~/.ssh door chmod g-w ~/.ssh/* te doen.

Opmerking: Dit begon als een “Hoe te debuggen”, tutorial, maar eindigde als de oplossing die me hielp op een Ubuntu 16.04 LTS server.

TLDR : Voer landscape-sysinfo uit en controleer of het lang duurt voordat dat commando klaar is; het is de systeeminformatie die wordt afgedrukt bij een nieuwe SSH login. Merk op dat dit commando niet op alle systemen beschikbaar is, het landscape-common pakket installeert het. (“Maar wacht, er is meer…”)

• *

Start een tweede ssh server op een andere poort op de machine die het probleem heeft, doe dit in debug mode, waardoor het niet fork en debug boodschappen zal uitdraaien:

sudo /usr/sbin/sshd -ddd -p 44321

maak verbinding met die server vanaf een andere machine in verbose mode:

ssh -vvv -p 44321 username@server

Mijn client geeft de volgende regels af vlak voordat hij begint te slapen:

debug1: Entering interactive session.
debug1: pledge: network

Googlen helpt niet echt, maar de serverlogs zijn beter:

debug3: mm_send_keystate: Finished sending state [preauth]
debug1: monitor_read_log: child log fd closed
debug1: PAM: establishing credentials
debug3: PAM: opening session
---- Pauses here ----
debug3: PAM: sshpam_store_conv called with 1 messages
User child is on pid 28051

Ik heb gemerkt dat als ik UsePAM yes verander in UsePAM no dan is dit probleem opgelost.

Niet gerelateerd aan UseDNS of een andere instelling, alleen UsePAM heeft invloed op dit probleem op mijn systeem.

Ik heb geen idee waarom, en ik laat UsePAM ook niet op no staan, omdat ik niet weet wat de neveneffecten zijn, maar dit laat me verder onderzoek doen.

Dus beschouw dit alstublieft niet als een antwoord, maar als een eerste stap om uit te zoeken wat er mis is.

• *

Dus ging ik verder met het onderzoek, en liep sshd met strace (sudo strace /usr/sbin/sshd -ddd -p 44321). Dit leverde het volgende op:

sendto(4, "<87>Nov 20 20:35:21 sshd[2234]: "..., 110, MSG_NOSIGNAL, NULL, 0) = 110
close(5) = 0
stat("/etc/update-motd.d", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
umask(022) = 02
rt_sigaction(SIGINT, {SIG_IGN, [], SA_RESTORER, 0x7f15dce784b0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN, [], SA_RESTORER, 0x7f15dce784b0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD, parent_tidptr=0x7ffde6152d2c) = 2385
wait4(2385, # BLOCKS RIGHT HERE, BEFORE THE REST IS PRINTED OUT # [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 2385

De regel /etc/update-motd.d maakte me achterdochtig, blijkbaar wacht het proces op het resultaat van de dingen die in /etc/update-motd.d

staan, dus ik cd‘d in /etc/update-motd.d en liep een sudo chmod -x * om PAM te remmen om alle bestanden uit te voeren die deze dynamische Message Of The Day genereren, waaronder systeembelasting en of pakketten geüpgrade moeten worden, en dit loste het probleem op.

Dit is een server gebaseerd op een “energiezuinige” N3150 CPU die 24/7 veel werk te doen heeft, dus ik denk dat het verzamelen van al deze motd-data gewoon te veel was voor hem.

Ik ga misschien selectief scripts in die map aanzetten, om te zien welke minder schadelijk zijn, maar speciaal het aanroepen van landscape-sysinfo is erg traag, en 50-landscape-sysinfo roept dat commando wel aan. Ik denk dat dat degene is die de grootste vertraging veroorzaakt.

Na het opnieuw aanroepen van de meeste bestanden kwam ik tot de conclusie dat50-landscape-sysinfo en 99-esm de oorzaak van mijn problemen waren. 50-landscape-sysinfo deed er ongeveer 5 seconden over om uit te voeren en 99-esm ongeveer 3 seconden. Alle andere bestanden samen ongeveer 2 seconden.

Noch 50-landscape-sysinfo en 99-esm zijn cruciaal. 50-landscape-sysinfo drukt interessante systeem statistieken af (en ook als je weinig ruimte hebt!), en 99-esm drukt berichten af die gerelateerd zijn aan Ubuntu Extended Security Maintenance

Tenslotte kun je een script maken met echo '/usr/bin/landscape-sysinfo' > info.sh && chmod +x info.sh en die afdruk op verzoek krijgen.

Ik heb alle antwoorden geprobeerd maar geen van hen werkte. eindelijk heb ik mijn probleem gevonden:

eerst draai ik sudo tail -f /var/log/auth.log zodat ik het log van ssh kan zien dan in een andere sessie draai ik ssh 172.16.111.166 en merkte op dat ik wacht op

/usr/bin/sss_ssh_knownhostsproxy -p 22 172.16.111.166

na het zoeken vond ik deze regel in /etc/ssd/ssh_config

ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h

ik becommentarieerde het en de vertraging verdween

Werkt prima.

# uname -a
SunOS oi-san-01 5.11 oi_151a3 i86pc i386 i86pc Solaris
# ssh -V
Sun_SSH_1.5, SSH protocols 1.5/2.0, OpenSSL 0x009080ff
# echo "GSSAPIAuthentication no" >> /etc/ssh/sshd_config
# echo "LookupClientHostnames no" >> /etc/ssh/sshd_config
# svcadm restart ssh

UseDNS no werkt niet met OpenIndiana !!!

Lees “man sshd_config” voor alle opties

“LookupClientHostnames no” als je server niet kan oplossen

ssh -vvv verbinding ging echt goed totdat hij minstens 20 Seconden bleef hangen op het systeem om te proberen de terminal te krijgen:

debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
... waiting ... waiting ... waiting

Na het doen van een systemctl restart systemd-logind op de server had ik direct weer verbinding!

Dit was op debian8! Dus systemd was het probleem hier!

Note: _Bastien Durel heeft al een antwoord gegeven voor dit probleem, maar het mist de debug informatie. Ik hoop dat iemand hier iets aan heeft.

Het kan zijn dat de voorkeursmethode voor naamresolutie niet het host-bestand is en dan DNS.

Dit zou bijvoorbeeld de gebruikelijke configuratie zijn:

[root@LINUX1 ~]# cat /etc/nsswitch.conf|grep hosts
#hosts: db files nisplus nis dns
hosts: files dns myhostname

Eerst wordt het hosts bestand bereikt (optie: files) en dan DNS (optie: dns), maar we kunnen ontdekken dat er een ander naamresolutiesysteem is toegevoegd dat niet operationeel is en ons de traagheid bezorgt bij het proberen te doen van de reverse resolution.

Als de volgorde van de naamresolutie niet juist is, kunt u deze wijzigen in: /etc/nsswitch.conf

Afkomstig van: http://www.sysadmit.com/2017/07/linux-ssh-login-lento.html

Deze thread geeft al een heleboel oplossingen, maar de mijne is hier niet gegeven =). Dus hier is het. Mijn probleem (het duurde ongeveer 1 minuut om in te loggen op mijn raspberry pi), was te wijten aan een corrupt .bash_history bestand. Aangezien het bestand wordt gelezen bij het inloggen, veroorzaakte dit de vertraging bij het inloggen. Toen ik het bestand verwijderd had, was de inlogtijd weer normaal, bijna onmiddellijk.

Hoop dat dit andere mensen helpt.

Om alle antwoorden aan te vullen die aantonen dat DNS resoluties je ssh login kunnen vertragen, soms ontbreekt er een firewall regel. Bijvoorbeeld, als je standaard alle INPUT paquets DROPT

iptables -t filter -P INPUT DROP

dan zul je INPUT moeten accepteren voor ssh poort en DNS verzoek

iptables -t filter -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT

Ik heb onlangs een andere oorzaak gevonden van trage ssh logins.

Zelfs als je UseDNS no in /etc/sshd_config hebt, kan sshd nog steeds reverse DNS lookups uitvoeren als /etc/hosts.deny een entry heeft zoals:

nnn-nnn-nnn-nnn.rev.some.domain.com

Dat zou kunnen gebeuren als je DenyHosts op je systeem geïnstalleerd hebt.

Het zou geweldig zijn als iemand wist hoe je DenyHosts kan laten vermijden om dit soort entry in /etc/hosts.deny te zetten.

Hier is een link, naar de DenyHosts FAQ , over hoe entries te verwijderen uit /etc/hosts.deny - zie Hoe kan ik een IP adres verwijderen dat DenyHosts geblokkeerd heeft?

Ik ontdekte dat het herstarten van systemd-logind.service het probleem slechts voor een paar uur oploste. Het veranderen van UsePAM van yes naar no in sshd_config heeft geresulteerd in snelle logins, hoewel motd niet langer wordt weergegeven. Opmerkingen over veiligheidsproblemen?

Bij mij was er een probleem in mijn lokale /etc/hosts bestand. Dus ssh probeerde twee verschillende IP’s (een verkeerde), wat een eeuwigheid duurde voordat de time-out.

ssh -v gebruiken deed de truc hier:

$ ssh -vvv remotesrv
OpenSSH_6.7p1 Debian-5, OpenSSL 1.0.1k 8 Jan 2015
debug1: Reading configuration data /home/mathieu/.ssh/config
debug1: /home/mathieu/.ssh/config line 60: Applying options for remotesrv
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to remotesrv [192.168.0.10] port 22.
debug1: connect to address 192.168.0.10 port 22: Connection timed out
debug1: Connecting to remotesrv [192.168.0.26] port 22.
debug1: Connection established.

Voor mij had ik GSSAPI nodig, en ik wilde reverse DNS lookups niet uitschakelen. Dat leek me gewoon geen goed idee, dus keek ik op de hoofdpagina voor resolv.conf. Het bleek dat een firewall tussen mij en de servers waar ik naartoe SSHte, DNS verzoeken verstoorde, omdat ze niet in een vorm waren die de firewall verwachtte. Uiteindelijk hoefde ik alleen maar deze regel toe te voegen aan resolv.conf op de servers waar ik naartoe aan het SSH-en was:

options single-request-reopen

Opmerkelijk is dat een package update van bind op CentOS 7 named kapot maakte, en nu in het logboek vermeldde dat /etc/named.conf een probleem had met de rechten. Het had maandenlang goed gewerkt met 0640. Nu wil het 0644. Dit is logisch omdat de named daemon bij de ‘named’ gebruiker hoort.

Met named uit was alles traag, van ssh-logins tot het serveren van pagina’s vanaf de lokale webserver, trage LAMP-apps enzovoort, waarschijnlijk omdat elk verzoek op de dode lokale server zou uitwerken voordat er naar een externe, secundaire DNS werd gekeken die is geconfigureerd.