BITFOX® | LÖSUNGEN | SERVICE | LOGIN | BLOG | KONTAKT

Sonntag, 5. Juni 2016

Der Klassiker: ssh und password-less login
und Probleme dabei.... :-)

Wochenende -
"Mal eben" ein neues System einrichten...
"Mal eben" das Backup der User zurück ziehen...
"Mal eben" passwordless login...

Mal eben - klar ;-)

Und ssh zeigte mir mal wieder, dass das nicht "Mal eben" wird -
sondern eine Stunde suchen. Grrrrh! :-)



Eines der Basics ist auf Linux-Systemen das Kennwortlose login.
Dafür konfiguriert man lediglich quick und dirty seine Datei /etc/ssh/sshd_config ungefähr so

  Protocol 2
  LoginGraceTime 2m
  MaxAuthTries 4
  MaxSessions 5
  PubkeyAuthentication yes
  GSSAPIAuthentication yes
  UsePAM yes 
  X11Forwarding yes
  PermitRootLogin no
  AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

und startet seinen Service via

    service sshd restart

oder

   systemctl restart sshd

neu durch - und das sollte es fast schon gewesen sein.
Noch schnell die Schlüssel einander bekannt machen.

  client: ssh-keygen
  client: ssh-copy-id -i server
  client: ssh server

oder oldfashioned

  client: ssh-keygen
  client: cd $HOME/.ssh
  client: cat id_rsa.pub (ausgabe kopieren)
  client: ssh server
  server: cd $HOME/.ssh
  server: vi authorized_keys (ausgabe von vorhin als neue Zeile einfügen)
  server: ssh-agent bash
  server: ssh-add $HOME/.ssh/id_rsa

fertig.

Und... es funktioniert doch nicht :-)
Man kann nun mit den üblichen Hilfsmitteln "ssh -v(vvvv) ziel" lange lange suchen...
Natürlich gibt es da die Klassiker, wie nicht richtig gesetzte Rechte im $HOME/.ssh/ , die schnell auf Server- und Client-Seite mit


  chmod -R 600 $HOME/.ssh
  chown -R username:username $HOME/.ssh/
  service sshd restart

oder

  systemctl restart sshd


gefixed sind.

Und wenn man dann noch immer Probleme hat, wird es auf einmal sehr still und man kann die Strohräder durch die Wüste rollen sehen...

Genau so erging es mir dann heute mal wieder...
Niemand hatte noch eine Idee, keiner wusste mehr weiter... "Das MUSS klappen" -
nein.. leider nicht... loggt euch ein... schauts euch selbst mal an...

Nach langem wuseln und suchen war mir aufgefallen, dass der "root" - sofern man ihn aktivierte - noch normal mit dem Schlüsselaustausch arbeiten konnte; nur die User nicht.
Und dann überlegte ich weiter -
Ja - die User aus /home waren aus einem Backup restaruert worden; der /root hatte keine restaurierten Daten - der wurde neu angelegt.
Es muss also ein Rechteproblem sein.

Check von /var/log/messages und /var/log/audit brachten aber keine Erkenntnisse.

Ein

  ls -alZ

auf /root und /home/user am server, client und einer Testmaschine verrieten mir jedoch, dass hier Differenzen bestanden.... Veni vidi vici! DA ist wohl das Problem.

Nach ein wenig grade-Rücken der Attribute war alles wieder okay.


Wer also das nächste Mal ein Backup "hervorzaubert" bzw. vorher "sichert", sollte darauf achten, dass wirklich alle SE-Linux Kontexte, Attribute /ACLs / xattrs gesichert werden...

  rsync -aAvXz quelle ziel
oder
  tar --preserve —acls —xattrs —selinux —gzip


können hier ein sehr guter Freund sein...!

  restorecon -R -v /home

und

  matchpathcon -v /home

sind hier ebenfalls bedingt hilfreich...


Schönes Wochenende! :-)



Keine Kommentare:

Aktuelles