ubuntuusers.de

Einträge in ssh config

Status: Ungelöst | Ubuntu-Version: Ubuntu 18.04 (Bionic Beaver)
Antworten |

Christofer

Avatar von Christofer

Anmeldungsdatum:
2. Februar 2007

Beiträge: 185

Hallo Community,

ich steh auf'm Schlauch. Ich arbeite von einem Linux-Client (Linux Mint 18.2) auf unterschiedlichen Linux-Servern (Ubuntu 18.04). Um das leben einfacher zu gestalten habe ich dazu in meiner ~/.ssh/conf die Server vorkonfiguriert. In der Form:

1
2
3
4
5
6
7
# Server xyz
Host name
    HostName 195.201.xx.xxx
    Port 10022
    User USERNAME
    IdentityFile ~/.ssh/id_rsa_system
    ServerAliveInterval 120

Das klappt auch alles wunderbar. Nun habe ich einen temporären Server den ich für einen Serverumzug benötige um Daten zwischenzuspeichern. Für diesen Server habe ich keinen SSH-Schlüssel generiert und auch nur root-Zugriff, ist ja nur eine temporäre Angelegenheit. Der Server soll möglichst einfach zu handhaben sein. Auf den Server kann ich direkt über die Kommadozeile:

1
user@client:$ sudo ssh root@serverip

ohne Probleme zugreifen. Aber bei folgendem Eintrag in der ssh config:

1
2
3
4
5
# Zwischenserver
Host name
    HostName 195.201.xx.xx
    User root
    ServerAliveInterval 120

bekomme ich mit dem Aufruf folgenden Fehler:

1
2
3
4
user@client:$  ssh NAME
[sudo] Passwort für user:          
Received disconnect from 195.201.xx.xx port 22:2: Too many authentication failures
Disconnected from 195.201.xx.xx port 22

Warum macht er das nicht?

PS: Mit "ssh root@serverip" also ohne "sudo" macht er im übrigen den gleichen Fehler.

Danke schon mal für Eure Hilfe und Euer Wissen.

Gruß

Christofer

Into_the_Pit Team-Icon

Ehemalige
Avatar von Into_the_Pit

Anmeldungsdatum:
25. Juni 2008

Beiträge: 9490

Wohnort: Bochum

Christofer schrieb:

1
user@client:$ sudo ssh root@serverip

sudo ist absolut unnötig für eine ssh Session zu einem anderen Host, selbst wenn der Remote User root ist.

1
2
3
4
user@client:$  ssh NAME
[sudo] Passwort für user:          
Received disconnect from 195.201.xx.xx port 22:2: Too many authentication failures
Disconnected from 195.201.xx.xx port 22

Warum macht er das nicht?

Gute Frage, lässt sich mit mehr Verbose rausbekommen, Stichwort ist hier LogLevel für die Config oder direkt als Command aufgerufen mit -vvv.

Cranvil

Anmeldungsdatum:
9. März 2019

Beiträge: 990

Christofer schrieb:

1
2
3
4
user@client:$  ssh NAME
[sudo] Passwort für user:          
Received disconnect from 195.201.xx.xx port 22:2: Too many authentication failures
Disconnected from 195.201.xx.xx port 22

Warum macht er das nicht?

Im besten Fall, weil der Server mehr Schutzmechanismen aktiviert hat, als du aushebeln konntest. Im schlechtesten Fall verbreitet er gerade Spam, Malware und Kinderpornos.

PS: Mit "ssh root@serverip" also ohne "sudo" macht er im übrigen den gleichen Fehler.

Mich würde nicht überraschen, wenn sudo ssh mittlerweile auch nicht mehr funktioniert.

Aber warum vermute ich das? Deine gekürzte IP-Adresse sieht nach einer öffentlichen IP-Adresse aus (195.201.0.0/16 gehört laut RIPE NCC zu Hetzner). Deine Beschreibung macht weiterhin den Eindruck, dass auf dem Server die Anmeldung von root mit einem Passwort aktiviert ist.

Im Internet gibt es viel automatisiertes Scannen und Einbrechen, daher dürfte dein SSH-Dienst sehr viele Anmeldeversuche für 0815-Accounts wie root, sysop, admin und vergleichbare erhalten. Je nach Konfiguration von ssh und den damit verbundenen Teilen kann es dann dazu kommen, dass zum Schutz dynamische Firewallregeln greifen oder Benutzeraccounts gesperrt werden. Das ist übrigend der beste Fall.

Der schlechteste Fall bedeutet, dass mindestens einer dieser automatisierten Angriffe erfolgreich einloggen und deinen Host übernehmen konnte. Und ab dem Zeitpunkt ist eigentlich alles möglich, was sich in das Spektrum zwischen Skriptkiddies über Schwerverbrecher bis hin zu staatlichen Akteuren pressen lässt.

Aus den vorgenannten Gründen ist es mittlerweile unüblich, über das Internet erreichbare Hosts mittels Passwort-Authentifizierung auf root zugreifen zu lassen. Aus Gewohnheit und in Fortsetzung des Sicherheitsgedankens ist das genauso im internen Netzwerk zu vermeiden.

Nun wieder zum Problem: Wenn dein sudo ssh noch funktioniert, solltest du nochmal schauen, welche ssh config dein lokaler root hat und wo du schonmal auf dem Server bist, auch gleich schauen, was dort in den Logs zu finden ist. Zusätzlich kannst du es auch mit ssh -v versuchen, um die Gesprächigkeit zu erhöhen. Mehr v, mehr Meldungen.

In jedem Fall würde ich den Server über das Admininterface ausradieren und neu installieren, bevor ich irgendetwas anderes damit unternehme.

Antworten |