Praktijkgevalletje: een gebruiker klaagt er over dat de ene keer hij zonder problemen met SSH een sessie kan opzetten naar een server, een andere keer volgt er een time-out en kan hij dus geen verbinding krijgen. De keer erop kan het soms weer probleemloos gaan. De server heeft zelf geen problemen, die draait, heeft het niet heel druk, er is geen volgelopen partitie of disk kortom op de server is de oorzaak van het probleem niet te vinden. Wel blijkt dat als de gebruiker wil inloggen en een time-out krijgt er in de logfiles op de server van die inlogpoging niets te vinden is. 

Later blijft dat hij met SSH een connectie naar de servernaam opzet: ssh user@server en dan blijkt dat de server met twee ipadressen in de DNS beheertool staat maar de server maar één actieve netwerkinterface heeft. Na het verwijderen uit de DNS van het niet in gebruikzijnde ipadres was het probleem verholpen. 

Wachtwoordmanager

Voor het gebruik van een (centrale) wachtwoordmanager is veel te zeggen. Op al je devices één plek met als je logins en wachtwoorden kan heel veilig zijn. Ook kan een wachtwoordmanager sterkte wachtwoorden genereren en opslaan die je niet hoeft te onthouden terwijl je wel gewoon overal kan inloggen. 

Tot voor kort was er eentje die ik zelf ook gebruikte en vele met mij, LastPass.

Echter LastPass is overgenomen door een LogMeIn en dat bedrijf heeft een erg twijfelachtige reputatie. Daarnaast wil LogMeIn allerlei functionaliteit toevoegen aan LastPass waardoor er twijfel is over de betrouwbaarheid maar nog meer over de veiligheid. Kortom, tijd om LastPass te laten voor wat het is en op zoek te gaan naar een alternatief.

Alternatief

LinuxPro is onlangs voor de Cloud dienst overgestapt op Nextcloud en heeft de Passman applicatie daarmee beschikbaar gestelt voor een groter publiek. Het gebruik van de LinuxPro Cloud en Passman is overigens gewoon gratis en draait op servers in een nederlands datacenter (GlobalSwitch)

Aanmelden

Meld je aan op https://cloud.linuxpro.nl Dat is eenvoudig, vul je emailadres in en je ontvangt op het door je opgegeven emailadres een link waarmee je je account kan activeren. Naast Passman heb je ook beschikking over oa. een agenda, adresboek en bestandsopslag. Al deze diensten kan je benaderen via de website, via de Owncloud app (iOS en Android) en je kan bijv. de agenda op je smartphone gebruiken of je vakantiefoto's delen met anderen al dan niet beveiligd met een wachtwoord of verloopdatum.

Passman

Na het inloggen kies je het sleutelsymbooltje om een wachtwoordkluis aan te maken. Deze kluis komt dan ge-encrypt op onze server. Door de versleutelingis de data voor niemand te gebruiken behalve door jezelf.  Maak een kluis aan, geef 'm een naam en vergeet vooral je passphrase niet. Je kan ook je aanwezige inlogs vanuit LassPass exporteren naar een csv bestand en dat vervolgens in Passman inlezen. Je hebt dan 1x al je al aanwezige logins en wachtwoorden beschikbaar in Passman. 

Extensie

Voor oa. Google Chrome is de gratis Passman extensie beschikbaar waardoor je eigenlijk dezelfde functionaliteit terug hebt als met LastPass, enige verschil is dat je nu een door jezelf aangemaakte wachtwoordkluis gebruikt die draait op een server in Nederland en er verder niemand bij jouw data kan anders dan jijzelf. Wel zo'n prettig gevoel

Gebeurd het je wel 's dat je op een server bent ingelogd en de connectie wordt verbroken en je bent wat je aan het doe was kwijt of bestanden raken beschadigd? Dan wordt het tijd voor een ondergewaardeerde maar oh zo handige tool: screen

Log in op de server, start screen door screen te tikken en je terminal is als het ware een apart proces op de server geworden en draait door ook als is je ssh/putty sessie verbroken. Log opnieuw in, attach je screen sessie en je zal zien dat wat je ook draaide, gewoon is doorgegaan en je kan de draad weer oppakken. Je kan ook als je in een screen sessie zit deze detachen (loslaten) en een andere beginnen. Je kan ook door diverse lopende screen sessie heen bladeren. Hoe? Dat vertei ik je hieronder. 

screen -ls : Opvragen van lopende screen sessies
screen -r <pid.tty> : re-attach een screen sessie, geef je geen pid.tty op (via screen -ls) dan wordt de eerte screen sessie gebruikt

In een screen sessie kan je daarnaast de volgende commando's gebruiken:

<Ctrl> a c : start een nieuwe screen sessie in screen 

<Ctrl> a n : loop door screen sessies heen 

<Ctrl> a d : de-attach screen, keer terug naar de 'normale' terminal prompt (de screen sessie lopen uiteraard door)

<Ctrl> a h : log wat er gebeurd in screen

<Ctrl> a x : lock een screen sessie zodat niet iemand anders 'm kan overnemen 

<Ctrl> a k : kill screen sessie, er wordt om een bevestiging gevraagd, gewoon exit typen kan overigens ook.

Het komt soms voor dat de netwerk grafieken die door MRTG gemaakt worden spontaan worden ge-reset en/of verdwijnen. Dit kan veroorzaakt worden doordat in /etc/cron.d een mrtg cronjob staat die, doordat deze soms tegelijk met een eigen cron job of doordat bijv. MRTG in daemon mode wordt gedraaid er een lock ontstaat op de MRTG logfiles (standaard in /var/lib/mrtg). 

Zorg er dus voor dat MRTG of als daemon draait en verwijder in /etc/cron.d het mrtg bestand of gebruik de standaard cron.d mrtg job of definieer er eentje zelf zoals in onderstaand voorbeeld.

*/5 * * * * env LANG=C /usr/bin/mrtg /etc/mrtg/mrtg.cfg

Intro

In oudere versies van Linux is lastiger om users te authenticeren met behulp van de Active Directory van Windows. Echter uit bijvoorbeeld beheersoogpunt is het soms wel gewenst dat dit gebeurd. Users hebben dan 1 inlog voor Windows en Linux. Deze uitleg is bruikbaar voor Redhat/CentOS 6.x servers en soortgelijken.

Software

Om middels sssd te kunnen authenticeren zijn een aantal packages nodig die als volgt geinstalleerd kunnen worden:

yum -y install authconfig  pam_krb5 samba-common oddjob-mkhomedir sssd 

De Kerberos configuratiefile moet er zo uit zien in /etc/krb5.conf:

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = example.ORG
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true

[realms]
 example.ORG = {
  kdc = dc-01-p.example.org:88
 }

[domain_realm]
 example.org = example.ORG
 .example.org = example.ORG

Het [global] gedeelte van /etc/samba/smb.conf dient er zo uit te zien:

[global]
   workgroup = EXAMPLE-DOMAIN
   realm = example.ORG
   security = ads
   idmap config * : range = 16777216-33554431
   template homedir = /home/%U
   template shell = /bin/bash
   winbind use default domain = true
   winbind offline logon = false

Let op dat onder Standalone Server de volgende parametes zijn uitgecommentarieerd:

;security = user
;passdb backend = tdbsam

De configuratiefile van sssd moet er zo uitzien in /etc/sssd/sssd.conf (deze configuratiefile bestaat meestal nog niet)

chmod 600 /etc/sssd/sssd.conf

Joinen van het example.org domein

Restart het e.e.a. om alle wijzigingen actief te maken:

service sssd restart
service winbind restart 

Om het example.org domein te joinen geef je:

net ads join example.org -U <admin user>

Om te controleren of het joinen geslaagd is geef je: (foutmeldingen over dns ed kunnen genegeerd worden)

net ads testjoin

Als het joinen daadwerkelijk geslaagd is kan de authenticatie worden aangepast met:

authconfig --enablesssd --enablesssdauth --enablemkhomedir --update

Opmerking: Het kan zijn dat het restarten voor het stop gedeelte een foutmelding geeft, zolang de tweede stap, het starten maar een Ok geeft.

Om ervoor te zorgen dat na een reboot het authenticeren tegen de AD blijft werken:

Toegang beperken tot groepen

Dit gaat anders dan onder CentOS 7 / Redhat 7. We beperken de toegang tot groepen door de ssh daemon configuratie aan te passen en de volgende regel toe te passen:

AllowGroups developers administrators root

In dit voorbeeld kan root inloggen, administrators en de developers via hun AD account. Laat bijv. developers weg als deze op de betreffende server niets te zoeken hebben

Problemen oplossen

Een enkele keer wordt /etc/nsswitch.conf niet geupdate, deze dient er als volgt uit te zien (voor CentOS/Redhat 6):

#
# /etc/nsswitch.conf
#
passwd:     files sss winbind
shadow:     files sss winbind
group:      files sss winbind
hosts:      files dns
bootparams: nisplus [NOTFOUND=return] files
ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files sss
netgroup:   files sss
publickey:  nisplus
automount:  files sss
aliases:    files nisplus

Controleer of een AD user herkend wordt op een linux server:

id <ad-account>

Je krijgt dan iets terug als (de Windows AD groepen waartoe iemand lid van is):