root login für den Notfall

[achim55]

Hallo,
ich möchte mir eine Plan B erstellen, wenn ich mal mit root nicht mehr auf das Blech komme, warum auch immer.
Dazu fällt mir SSH-Logins auf Public-/Private-Key Basis ein, oder gibt es eine bessere Lösung?

Ich habe das mal gestest und ein Schlüsselpaar erstellt, mit eine Passphrase, was auch klappt.

Aktiviere ich jedoch PasswordAuthentication no komme ich mit dem dem User xyz@xx.xx.xx.xx nicht mehr per ssh aufs Blech.
Deaktiviere ich PasswordAuthentication komme ich zwar wieder mit dem User drauf, jedoch klappt dann nicht mehr Das Public-/Private-Key verfahren, dann kommt eine Passworteingabe die aber nicht funktioniert für root.


Gruß


41049

[uname]

Konfiguriere es mal so, dass sich normale Benutzer anmelden können.
Suche dann "PermitRootLogin" und ändere es wie folgt:

Code: Alles auswählen

PermitRootLogin without-password

Ich sehe im Zugriff über SSH-Keys für root keine Probleme.
Hat auch viele Vorteile, wenn du z. B. ein Backup ziehen willst.

[MSfree]

Wenn man als normaler Benutzer auf die Kiste kommt, reicht doch

Code: Alles auswählen

su

oder

Code: Alles auswählen

su -

oder

Code: Alles auswählen

sudo bash

aus, um root zu sein. Wozu soll ein eigenes root-Login nötig sein?

In der Default /etc/sshd_config ist auch die Anmeldung mit Schlüsseldatei möglich, was einem einen direkten root-Zugang ermöglicht. Eigentlich muß man an dieser Datei rein gar nichts ändern.

[achim55]

Ich mache das ja über einen User und gehe dann mit cu - weiter.
Meine Bedenken sind was mache ich wenn der Userzugang platt ist? Dann war es das mit root!
Deswegen Plan b

[willy4711]

Meine Bedenken sind was mache ich wenn der Userzugang platt ist? Dann war es das mit root!

Unter welchen Umständen sollte ein User Account zerstört werden ?
Dann wird wohl nichts mehr gehen, und du musst dich physisch zu dem "Blech" (=Server ?) hinbewegen.

[MSfree]

Meine Bedenken sind was mache ich wenn der Userzugang platt ist? Dann war es das mit root!Deswegen Plan b

Wie gesagt, du kannst jederzeit einen Root-Zugang über Schlüsseldateien anlegen. Dazu brauchst du an der Default sshd_config gar nichtss zu ändern. Das klappt out of the box. Das Login geht dann mit

Code: Alles auswählen

ssh root@server.name -i clinetkeyfile.rsa

[reox]

Unter welchen Umständen sollte ein User Account zerstört werden ?

Wenn du zB die User über ldap hast und der ldap server eingeht und lokal kein cache konfiguriert ist.

[ingo2]

Du kannst das auch ganz einfach auf nur einen PC oder das lokale Netzwerk beschränken, von dem du dich dann als root (auf Wunsch auch mit Password) einloggen kannst. Beispiel
Häng' einfach am Ende deiner /etc/ssh/sshd_config die Konfiguration dafür an:

Code: Alles auswählen

Match Address 192.168.???.0/24
	PasswordAuthentication yes
	PermitRootLogin yes
	Banner none

Das überstimmt dann die davorstehenden Limitierungen - hier fürs lokale Netz.

[eggy]

Lass den Zugang lieber auf Keys beschänkt. Wenn Du Sorgen hast, dass Du Dir den Useraccount zerbastelst, leg Dir doch einfach nen zweiten User an, den Du nur fürs "su -" benutzt.

[KBDCALLS]

Auch wenns jetzt etwas älter ist . Hab auch daran geknobelt wie ich mich per Root mit dem Public Key einloggen kann.

Als erstes hatte ich in das Verzeichis /etc/ssh/ssh_config.d

folgenden zwei Dateien angelegt.

• PasswordAuthentication.conf

mit dem Inhalt

• Code: Alles auswählen

  PubkeyAuthentication yes
  
  PasswordAuthentication no

• PermitRootLogin.conf

mit dem Inhalt

• Code: Alles auswählen

  PermitRootLogin yes

Mit dem Resultat als User konnte ich mich einloggen als Root aber nicht.


Der wurde dann so quittiert

• Code: Alles auswählen

  root@localhost: Permission denied (publickey).

Lösung war dann die authorized_keys in /root/.ssh angelegt anstatt in /etc/ssh/

1. 41169
2. 41171
3. 41172

[Livingston]

Lösung war dann die authorized_keys in /root/.ssh angelegt anstatt in /etc/ssh/

Nach /etc/ssh hätte die authorized_keys eh nicht gehört, sondern ins jeweilige home-Verzeichnis unter ~/.ssh. Da /root das home-Verzeichnis von root ist, muss das Teilchen da hin.

[MSfree]

Nach /etc/ssh hätte die authorized_keys eh nicht gehört

Nunja, Vorschriften macht einem unter Linux keiner, bestenfalls Vorschläge. Per Default gehen die halt nach ~/.ssh. Man kann aber in der /etc/ssh/sshd_config auch einen anderen Ort dafür festlegen, die Direktive dafür lautet:

Code: Alles auswählen

AuthorizedKeysFile

[ingo2]

So, dazu habe ich auch noch eine Frage - bin gerade am aufräumen meiner gpg- und ssh-keys:

Gibt es eine Möglichkeit, aus den authorized_keys zu rekonstruieren, welcher secret-key auf einem Client dazu gehört (key-ID)?

Und - falls möglich - aus der known_hosts rückwärts aufzulösen, welcher Server sich hinter den Einträgen verbirgt?

Gruß, Ingo