24
An Konsole geht der Root Account über SSH Permission denied
Hallo,
wenn ich bei Ubuntu 16.04 über SSH einlogge, kommt Permission denied. Bin ich aber direct an der Konsole im VMWARE geht der Root User.
Weiss wer was zu tun ist ?
Gruss
Jonas
wenn ich bei Ubuntu 16.04 über SSH einlogge, kommt Permission denied. Bin ich aber direct an der Konsole im VMWARE geht der Root User.
Weiss wer was zu tun ist ?
Gruss
Jonas
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 1262908705
Url: https://administrator.de/contentid/1262908705
Printed on: April 26, 2024 at 16:04 o'clock
24 Comments
Latest comment
Moin,
Du willst Dich nicht per Password authentication über SSH einloggen. Eigentlich gar nicht als root per SSH, sondern als User und dann mit su oder sudo root werden. Deswegen ist das per Default deaktiviert in der sshd.conf
Wenn, dann solltest Du zumindest über Zertifikat als root draufgehen.
lks
Du willst Dich nicht per Password authentication über SSH einloggen. Eigentlich gar nicht als root per SSH, sondern als User und dann mit su oder sudo root werden. Deswegen ist das per Default deaktiviert in der sshd.conf
Wenn, dann solltest Du zumindest über Zertifikat als root draufgehen.
lks
Solche Anleitungen nicht leichtfertig posten. Es gibt schon genug Bots im Internet.
lks
root über ssh ist schon ok, nur nicht im Internet eben.
Zu dem Link gehört also der klare Hinweis, die Firewall zu zu lassen.
+1 für lks i.S. Zertifikat
@itnirvana, bitte nächstes mal erst selbst googlen, sollte man als (angehender) Admin ja schaffen
Wenn's dann noch klemmt, immer gerne.
Viele Grüße, commodity
Zu dem Link gehört also der klare Hinweis, die Firewall zu zu lassen.
+1 für lks i.S. Zertifikat
@itnirvana, bitte nächstes mal erst selbst googlen, sollte man als (angehender) Admin ja schaffen
Wenn's dann noch klemmt, immer gerne.
Viele Grüße, commodity
Ist dir eigentlich klar, dass dein System aus dem Support ist?
Ist so wie bei Windows XP.
Die SSH-Konfig verbietet meines Wissens standardmäßig den root-Login, dort ggf. mal nachsehen, wenn du dann deinen Server mit 20.04 neu aufgesetzt hast.
Ist so wie bei Windows XP.
Die SSH-Konfig verbietet meines Wissens standardmäßig den root-Login, dort ggf. mal nachsehen, wenn du dann deinen Server mit 20.04 neu aufgesetzt hast.
Hallo Marco.
Es nervt, bei jeder Erwähnung von Ubuntu 16.x oder früher oder Win7 oder früher gleich drauf rumzureiten, daß es aus dem Support wäre.
Zum einen gibt es manchmal gute Gründe die alten Systeme weiterzuverwenden udn zum anderen weiß ein guter Admin, auch "veraltete" Systeme zu schützen. Und bei Testsystemen ist es eh wurst.
Also. bevor Du losdonnerst, vielleich vorher nachfragen, ob es eine Grund gibt, das veraltete System weiterzunutzen.
lks
Moin,
1. neuen User einrichten.
2. den neuen User zum sudoer machen.
3. root /dev/null als Standardkonsole zuweisen (ist das bei Ubuntu nicht Standard)
4. root abmelden. (vielleicht besser im letzten Schritt )
5. den neuen sudoer anmelden.
6. ssh so einrichten, dass es nur mit key geht.
7. key pair für den neuen User erzeugen und den public key beim Server hinterlegen.
8. ssh client so einrichten, dass er den key kennt.
9. ssh mit dem neuen sudoer betreiben.
So kurz hingerotzt. Genauere Anleitungen, wie man das macht, gibt es im Internet gefühlt Millionen.
Liebe Grüße
Erik
Zitat von @itnirvana:
wenn ich bei Ubuntu 16.04 über SSH einlogge, kommt Permission denied. Bin ich aber direct an der Konsole im VMWARE geht der Root User.
Weiss wer was zu tun ist ?
wenn ich bei Ubuntu 16.04 über SSH einlogge, kommt Permission denied. Bin ich aber direct an der Konsole im VMWARE geht der Root User.
Weiss wer was zu tun ist ?
1. neuen User einrichten.
2. den neuen User zum sudoer machen.
3. root /dev/null als Standardkonsole zuweisen (ist das bei Ubuntu nicht Standard)
4. root abmelden. (vielleicht besser im letzten Schritt
)5. den neuen sudoer anmelden.
6. ssh so einrichten, dass es nur mit key geht.
7. key pair für den neuen User erzeugen und den public key beim Server hinterlegen.
8. ssh client so einrichten, dass er den key kennt.
9. ssh mit dem neuen sudoer betreiben.
So kurz hingerotzt. Genauere Anleitungen, wie man das macht, gibt es im Internet gefühlt Millionen.
Liebe Grüße
Erik
Moin,
Dem würde ich vehement widersprechen, sofern es sich nicht um einen Singel-Haushalt handelt. Ca. 70 - 80% aller Angriffe kommen aus dem Firmennetz selbst und nicht von außen.
Liebe Grüße
Erik
Dem würde ich vehement widersprechen, sofern es sich nicht um einen Singel-Haushalt handelt. Ca. 70 - 80% aller Angriffe kommen aus dem Firmennetz selbst und nicht von außen.
Liebe Grüße
Erik
Zitat von @erikro:
... Ca. 70 - 80% aller Angriffe kommen aus dem Firmennetz selbst und nicht von außen.Da stimme ich Dir zu. Was bedeutet das Deiner Meinung nach für einen public key based root-Zugang über netzinternes ssh?
Viele Grüße, commodity
Moin,
Dass der direkte Zugang per ssh als root ein NoGo ist. Und nicht nur deshalb. Dass man sich erst mit seinem key und seinem User anmelden muss, hat auch den Zweck, dass man hinterher weiß, wer den Unsinn gemacht hat. Loggen sich alle als root ein, kann man das nicht mehr nachvollziehen.
Zitat von @commodity:
Da stimme ich Dir zu. Was bedeutet das Deiner Meinung nach für einen public key based root-Zugang über netzinternes ssh?
Zitat von @erikro:
... Ca. 70 - 80% aller Angriffe kommen aus dem Firmennetz selbst und nicht von außen.Da stimme ich Dir zu. Was bedeutet das Deiner Meinung nach für einen public key based root-Zugang über netzinternes ssh?
Dass der direkte Zugang per ssh als root ein NoGo ist. Und nicht nur deshalb. Dass man sich erst mit seinem key und seinem User anmelden muss, hat auch den Zweck, dass man hinterher weiß, wer den Unsinn gemacht hat. Loggen sich alle als root ein, kann man das nicht mehr nachvollziehen.
Das ist keine Begründung. Warum ist das Deiner Meinung nach so?
Ergo kann man das problemlos nachvollziehen.
Viele Grüße, commodity
Dass man sich erst mit seinem key und seinem User anmelden muss, hat auch den Zweck, dass man hinterher weiß, wer den Unsinn gemacht hat. Loggen sich alle als root ein, kann man das nicht mehr nachvollziehen.
Das wäre eine gute Begründung, wenn sie richtig wäre. Tatsächlich wird auch beim root-login protokolliert, mit welchem Key das erfolgt ist.sshd[815]: Accepted publickey for root from 192.168.3.22 port 1655 ssh2: RSA SHA256:.....Viele Grüße, commodity
1
Zitat von @Lochkartenstanzer:
Es nervt, bei jeder Erwähnung von Ubuntu 16.x oder früher oder Win7 oder früher gleich drauf rumzureiten, daß es aus dem Support wäre.
Es nervt, bei jeder Erwähnung von Ubuntu 16.x oder früher oder Win7 oder früher gleich drauf rumzureiten, daß es aus dem Support wäre.
Hi lks,
wenn Fragen zu veralteten System gestellt werden wundert es Dich das Hinweise dazu kommen?
Aus meiner Sicht sollte ein verantwortungsvoller Helfer natürlich zwingend darauf hinweisen.
Vielleicht sollte doch in so einem Fall der Fragesteller gleich mal darauf verweisen das der alte Versionsstand bekannt ist.
Macht, denke ich, viel mehr Sinn als anders herum.
mfg
kowa
Zitat von @KowaKowalski:
Hi lks,
wenn Fragen zu veralteten System gestellt werden wundert es Dich das Hinweise dazu kommen?
Zitat von @Lochkartenstanzer:
Es nervt, bei jeder Erwähnung von Ubuntu 16.x oder früher oder Win7 oder früher gleich drauf rumzureiten, daß es aus dem Support wäre.
Es nervt, bei jeder Erwähnung von Ubuntu 16.x oder früher oder Win7 oder früher gleich drauf rumzureiten, daß es aus dem Support wäre.
Hi lks,
wenn Fragen zu veralteten System gestellt werden wundert es Dich das Hinweise dazu kommen?
Es ist ja nicht sdagegen zu sagen, daß man auch darauf hinweist, aber wenn das der Hauptzweck der Antwort ist, nervt es. Abgesehen davon, daß 16.04 gerade frisch aus dem Support herausgefallen ist un von daher das gleiche Recht hat, noch weiterzulaufen, wie Windows 7.
(Ich rede natürlich von Serversystemen, was der Betrieb als VM und ssh-zugriff impilziert.)Aus meiner Sicht sollte ein verantwortungsvoller Helfer natürlich zwingend darauf hinweisen.
Aber wie gesagt, nicht als Hauptzweck der Antwort.
Vielleicht sollte doch in so einem Fall der Fragesteller gleich mal darauf verweisen das der alte Versionsstand bekannt ist.
Das wäre natürlich sinnvoll, statt sich dutzendmal anhören zu müssen, da sein System veraltet ist.
Macht, denke ich, viel mehr Sinn als anders herum.
Bei Marco ist mir halt in seinen letzten Posts aufgefallen, daß außer dem Hinweis auf eine veraltete Linux-version kaum Info udn Hilfe kam.
lks
vielen Dank. Das mit SSH Root ging nun. Bin eben nun am viel testen und lernen.
Gruss
Jonas
Gruss
Jonas
wahrscheinlich hätte der SCP Befehl gereicht. Muss eben paar Dateien da runterkopieren.
Gruss
jonas
Gruss
jonas
Zitat von @itnirvana:
vielen Dank. Das mit SSH Root ging nun. Bin eben nun am viel testen und lernen.
vielen Dank. Das mit SSH Root ging nun. Bin eben nun am viel testen und lernen.
mit welcher Lösung hast Du es denn gemacht?
- Root mit Paßwort zugelassen?
- root mit zertifikat zugelassen?
- User mit Paßwort zugelassen und sudo verwendet?
- User mit Zertifikat zugelassen und sudo verwendet?
Wie schon weiter oben gesagt, soltest Du die erste variant emöglichst gar nicht einsetzen, die zweite nur eingeschränkt, von der dritten würde ich auch abraten und die 4. empfehlen.
lks
PS: Du sollest noch einen Backupmachen und dann anschließend mit "sudo updatemanager -d" Dein System upgraden.
Moin,
Weil es sicherer ist, wenn sich root überhaupt nicht einloggen kann. Oder schärfer formuliert: Im Firmenumfeld ist es ein NoGo, dass root sich auf einer Konsole, sei es per ssh, sei es direkt am Server, einloggt. Das sollte immer so laufen, dass sich erst ein eingeschränkter User anmeldet, der sich dann die Rechte bei Bedarf mit sudo holt.
Um gleich Dein nächstes "Warum" zu beantworten: Admin hat Sprühdurchfall und muss ganz schnell auf's Klo. Deshalb versäumt er es, den Rechner zu sperren und sein Büro abzuschließen. Das kriegt der gerade gekündigte Kollege mit. Ist er nun als eingeschränkter User eingeloggt, dann ist das zwar auch nicht schön. Aber der pöse Pursche kann nicht viel machen. Ist er als root eingeloggt, dann reicht ein kurzes rm -r /* und aus die Maus. Ein Beispielszenario. Derer gibt es noch einige.
Ergo kann man das problemlos nachvollziehen.
Da hast Du allerdings auch wieder recht. Das war einer der Gründe, warum das geteilte PW ein NoGo ist.
Liebe Grüße
Erik
Weil es sicherer ist, wenn sich root überhaupt nicht einloggen kann. Oder schärfer formuliert: Im Firmenumfeld ist es ein NoGo, dass root sich auf einer Konsole, sei es per ssh, sei es direkt am Server, einloggt. Das sollte immer so laufen, dass sich erst ein eingeschränkter User anmeldet, der sich dann die Rechte bei Bedarf mit sudo holt.
Um gleich Dein nächstes "Warum" zu beantworten: Admin hat Sprühdurchfall und muss ganz schnell auf's Klo. Deshalb versäumt er es, den Rechner zu sperren und sein Büro abzuschließen. Das kriegt der gerade gekündigte Kollege mit. Ist er nun als eingeschränkter User eingeloggt, dann ist das zwar auch nicht schön. Aber der pöse Pursche kann nicht viel machen. Ist er als root eingeloggt, dann reicht ein kurzes rm -r /* und aus die Maus. Ein Beispielszenario. Derer gibt es noch einige.
Dass man sich erst mit seinem key und seinem User anmelden muss, hat auch den Zweck, dass man hinterher weiß, wer den Unsinn gemacht hat. Loggen sich alle als root ein, kann man das nicht mehr nachvollziehen.
Das wäre eine gute Begründung, wenn sie richtig wäre. Tatsächlich wird auch beim root-login protokolliert, mit welchem Key das erfolgt ist.sshd[815]: Accepted publickey for root from 192.168.3.22 port 1655 ssh2: RSA SHA256:.....Da hast Du allerdings auch wieder recht. Das war einer der Gründe, warum das geteilte PW ein NoGo ist.
Liebe Grüße
Erik
Ist das das Argument? Wenn der Admin Sprühdurchfall hat, oder sonst wie schusselig, dann ist der Rechner auch unter sudo frei. Hand aufs Herz, welcher Kollege gibt vor jedem Befehl sudo ein? Der geht, wie Du ja auch schreibst, vom user in den root und arbeitet dann da. Wenn administriert wird, ist er root und als was anderes ist der admin nicht auf dem Rechner.
Ich respektiere natürlich total Deinen Weg, wollte nur mal wissen, welche technischen Gründe Dein
Schönes Wochenende und viele Grüße, commodity
Ich respektiere natürlich total Deinen Weg, wollte nur mal wissen, welche technischen Gründe Dein
Dem würde ich vehement widersprechen
tragen. Wenn Du noch ein paar hast, sehr gerne.Schönes Wochenende und viele Grüße, commodity
Moin,
Das technische Argument ist, dass root /dev/null als Standardshell zugewiesen bekommt und sich deshalb überhaupt nicht direkt einloggen kann. Das ist afaik bei Ubuntu die Voreinstellung.
Liebe Grüße
Erik
Zitat von @commodity:
Ich respektiere natürlich total Deinen Weg, wollte nur mal wissen, welche technischen Gründe Dein
Ich respektiere natürlich total Deinen Weg, wollte nur mal wissen, welche technischen Gründe Dein
Dem würde ich vehement widersprechen
tragen. Wenn Du noch ein paar hast, sehr gerne.Das technische Argument ist, dass root /dev/null als Standardshell zugewiesen bekommt und sich deshalb überhaupt nicht direkt einloggen kann. Das ist afaik bei Ubuntu die Voreinstellung.
Liebe Grüße
Erik
Zitat von @erikro:
Das technische Argument ist, dass root /dev/null als Standardshell zugewiesen bekommt und sich deshalb überhaupt nicht direkt einloggen kann. Das ist afaik bei Ubuntu die Voreinstellung.
Nein.
root:x:0:0:root:/root:/bin/bashIn der /etc/shadow ist vor dem PW ein Ausrufezeichen, das verhindert, dass sich jemand einloggen kann, weil es niemals einen passenden Hash geben wird.
Zitat von @Windows10Gegner:
Nein.
root ist aber unter Ubuntu deaktiviert (passwd -u hebt das auf) und dann muss auch noch ein PW gesetzt werden.
In der /etc/shadow ist vor dem PW ein Ausrufezeichen, das verhindert, dass sich jemand einloggen kann, weil es niemals einen passenden Hash geben wird.
Zitat von @erikro:
Das technische Argument ist, dass root /dev/null als Standardshell zugewiesen bekommt und sich deshalb überhaupt nicht direkt einloggen kann. Das ist afaik bei Ubuntu die Voreinstellung.
Nein.
root:x:0:0:root:/root:/bin/bashIn der /etc/shadow ist vor dem PW ein Ausrufezeichen, das verhindert, dass sich jemand einloggen kann, weil es niemals einen passenden Hash geben wird.
Wieder was gelernt. Danke
Zitat von @erikro:
Moin,
Das technische Argument ist, dass root /dev/null als Standardshell zugewiesen bekommt ...
Moin,
Zitat von @commodity:
Ich respektiere natürlich total Deinen Weg, wollte nur mal wissen, welche technischen Gründe Dein
Ich respektiere natürlich total Deinen Weg, wollte nur mal wissen, welche technischen Gründe Dein
Dem würde ich vehement widersprechen
tragen. Wenn Du noch ein paar hast, sehr gerne.Das technische Argument ist, dass root /dev/null als Standardshell zugewiesen bekommt ...
Nein, default ist /bin/bash.
Üblich ist /bin/false oder /bin/true, wenn man das Login deaktivieren will.
Ich nehme meistens /bin/false (selten /bin/true)
lks
Zitat von @Lochkartenstanzer:
Nein, default ist /bin/bash.
Üblich ist /bin/false oder /bin/true, wenn man das Login deaktivieren will.
Ich nehme meistens /bin/false (selten /bin/true)
Zitat von @erikro:
Das technische Argument ist, dass root /dev/null als Standardshell zugewiesen bekommt ...
Das technische Argument ist, dass root /dev/null als Standardshell zugewiesen bekommt ...
Nein, default ist /bin/bash.
Üblich ist /bin/false oder /bin/true, wenn man das Login deaktivieren will.
Ich nehme meistens /bin/false (selten /bin/true)
So war das auch gemeint, dass das so konfiguriert wird, dass root sich nicht mehr einloggen kann. Ich dachte halt, dass Ubuntu diesen "Trick" nutzt. Aber damit kenne ich mich nicht wirklich aus. Ich nehme lieber das original Debian.
Zitat von @erikro:
Das technische Argument ist, dass root /dev/null als Standardshell zugewiesen bekommt und sich deshalb überhaupt nicht direkt einloggen kann. Das ist afaik bei Ubuntu die Voreinstellung.
Davon abgesehen, dass die Aussage (wie schon festgestellt) nicht zutrifft, wäre das Argument also: "es ist so, weil es so ist"?Das technische Argument ist, dass root /dev/null als Standardshell zugewiesen bekommt und sich deshalb überhaupt nicht direkt einloggen kann. Das ist afaik bei Ubuntu die Voreinstellung.
Halten wir fest: Es ist nicht so und das von Dir bevorzugte (von mir auch)
Ich nehme lieber das original Debian.
hat überhaupt nichts dagegen. Wie wir ja schon rausgearbeitet haben, ist sudo bei Sprühdurchfall ebensowenig besser, wie bei der Protokollierung des Zugriffs.Korrekt ist:
Voreinstellung in der sshd_config ist
PermitRootLogin noFür den ambitionierten User, der auf seinem System zu Hause ab und zu als root agieren möchte, sieht das natürlich anders aus. Da finde ich den Ubuntu-Ansatz auch angemessen.
Viele Grüße, commodity