Laden...

Wieso wird bei einer SSH Verbindung über C# das Password denied?

Erstellt von Rico913 vor 3 Jahren Letzter Beitrag vor 3 Jahren 1.897 Views
R
Rico913 Themenstarter:in
95 Beiträge seit 2020
vor 3 Jahren
Wieso wird bei einer SSH Verbindung über C# das Password denied?

Hi,

ich versuche eine SSH-Verbindung aufzubauen, aber ich bekomme folgende Fehlermeldung:

Fehlermeldung:
Renci.SshNet.Common.SshAuthenticationException: "Permission denied (password)."

Mein Code ist folgender:


string code;
            string host = "dedehog01";
            string username = "ABC";
            string password = "XXX";
  
            using (var ssh = new SshClient(host, 22, username, password))

            {
                ssh.Connect();
                ........
                ........
                ssh.Disconnect();
            }
           
        }

Uber Putty habe ich die Verbindung mit Passwort getestet - funzt. Warum wird dann trotzdem verweigert?

R
Rico913 Themenstarter:in
95 Beiträge seit 2020
vor 3 Jahren

Appropos Passwort

Wie kann ich den Usernamen und das Password einfach aus der Windowssession übernehmen?
Der Nutzer muss sich ohnehin in seinem Windowskonto anmelden und ich würde es gerne vermeiden, dass er seine Anmeldedaten nochmal eingeben muss. Geht das überhaupt?

T
2.219 Beiträge seit 2008
vor 3 Jahren

Welche Antwort sollten wir dir hier geben können?
Der Code muss ja richtig sein, nur dann sind scheinbar deine Einstellungen falsch.
Hast du ggf. einen anderen Port in Putty eingestellt, also keinen Default Port 22?
Dann wäre es klar warum es nicht geht.

Ansonsten lässt sich dies nicht am Code erkennen, da die Umgebung und Einstellungen nicht einsehbar sind.

Nachtrag:
Zu deinem zweiten Post:
Wird so nicht funktionieren.
Nimm doch lieber eine Key Anmeldung, da du dann keine Passwörter kennen musst.
Einen Key zu generieren und zu speichern ist dann kein Aufwand und sichert dich auch gleich gegen Brute Force Anmeldungen ab.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

16.807 Beiträge seit 2008
vor 3 Jahren

Wie kann ich den Usernamen und das Password einfach aus der Windowssession übernehmen?

Nein, natürlich kannst Du kein Passwort aus der Windows Session auslesen.

Wenn Deine Gegenstelle kein Single Sign On (über welches Protokoll auch immer) unterstützt, dann bleint Dir nichts anderes als die Passwortabfrage.
Alles andere generelle kannst Du prinzipiell den Microsoft Docs entnehmen; da ist von Kerberos bis Windows Hello alles erklärt - meistens sogar mit C# relevanten Code.
Macht ja wenig Sinn, dass wir Dir abtippen was in der Doku steht.

Bezüglich dem Problem würde ich pauschal raten es liegt am Zertifikat.
Aber letzten Endes bräuchte ich bei den Infos, die Du zur Verfügung stellst, eine Glaskugel um hellsehen zu können 😉

R
Rico913 Themenstarter:in
95 Beiträge seit 2020
vor 3 Jahren

Okay ... trotzdem Danke für die hilfreichen und vor allem schnellen Antworten 😃

R
Rico913 Themenstarter:in
95 Beiträge seit 2020
vor 3 Jahren

Ich bin das Problem umgangen und benutze Putty als Verbindung.
Mein Code sieht nun so aus:


bool Username_DomainCheck = Username.ToLower().Contains(@"....\");
            if (Username_DomainCheck == true)
            {
                Username = Username.Remove(0, 11);
            }
if (File.Exists(@"C:\Program Files\PuTTY\plink.exe"))
            {
                Process cmd = new Process();
                cmd.StartInfo.FileName = @"C:\Program Files\PuTTY\plink.exe";
                cmd.StartInfo.UseShellExecute = false;
                //cmd.StartInfo.CreateNoWindow = true;
                cmd.StartInfo.RedirectStandardInput = true;
                cmd.StartInfo.RedirectStandardOutput = true;
                cmd.StartInfo.Arguments = "-ssh dedehog01 -l " + Username + " -m " + "\\\\.........\\command.txt";
                cmd.Start();
                cmd.StandardInput.WriteLine("/...../get_code");
                cmd.StandardInput.WriteLine("exit");

                string output = cmd.StandardOutput.ReadToEnd();

                label5.Text = output;
            }
            else
            {
                MessageBox.Show("Bitte PUTTY installieren und erneut versuchen.");
            }
        }

T
2.219 Beiträge seit 2008
vor 3 Jahren

Ist dann aber eine reine Krückenlösung und alles andere als sauber.
Damit zwingst du auch den Nutzer deiner Anwendung auf bestimmte Anwendungen, was in dem Fall doch unnötig ist.
Prüf doch bitte mal ob du ggf. noch extra Einstellungen für den SSH Client in deinem Code hinterlegen muss, eben wie der Port etc.

So baust du dir irgendwas zu sammen, was ggf. zukünftig bei neuen Putty Versionnen nicht mehr supportet wird.
Dann hängst du auf einer uralt Krückenlösung fest und zwingst deinen Nutzern oder gar dir selbst eine Sicherheitslücke auf.
Du löst also das Grundproblem nicht, schaffst dir aber neue Probleme.

Lieber einmal mehr Zeit in die Analyse investieren als hitnerher sich selbst eine Grube zu graben.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

R
Rico913 Themenstarter:in
95 Beiträge seit 2020
vor 3 Jahren

Das ist völlig richtig, aber ich kann es unseren Nutzern schon mal als Zwischenlösung zur Verfügung stellen.
Ich behalte das auf dem Schirm und versuche es sauber zu lösen - bin ja noch in den Kinderschuhen und bisher am Basteln, um so Stück für Stück Erfahrungen zu sammeln.

Zum Glück gibt es solche Foren, die einen unglaublich weiterhelfen. Geht zumindest mir so!
Es muss nicht immer der vorgekaute Code sein, sondern es reicht oft ein Schubs in die richtige Richtung. Danke 👍

T
2.219 Beiträge seit 2008
vor 3 Jahren

Dann liefere am besten Putty als portable Version gleich mit aus.
Dann müssen die User nicht extra noch das Programm installieren.
Und du kannst auch sicher sein, welche Version gerade läuft.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

16.807 Beiträge seit 2008
vor 3 Jahren

Dann liefere am besten Putty als portable Version gleich mit aus.

Bei solchen Empfehlungen auch immer die Lizenzbestimmungen beachten.
Im Falle von Putty ist das MIT. Auch wenn MIT relativ unproblematisch ist: immer abklären.

Und da es sich hier nach Unternehmensanwendung anhört: Unternehmen hassen es, wenn Anwendungen einfach so Zeugs mitliefern.
Dependencies müssen angegeben werden und werden über entsprechende Automatismen oft zentral verwaltet.

Gibt genug Unternehmen für die ist ein "Mitliefern" von Portable Apps (und damit Schatten-IT) ein absolutes No Go.

T
2.219 Beiträge seit 2008
vor 3 Jahren

Dann wäre es sogar noch wichtiger es direkt sauber zu lösen anstelle dieser Zwischenlösung.
Nur dazu muss sich der Te die Zeit nehmen.
Da er dies aber scheinbar lieber schieben will, kann ich keine saubere Lösung vorschlagen.

Für den aktuellen Ansatz sehe ich schon wieder neue Probleme, die vermutlich in Zukunft für neue Probleme sorgen werden.
Hier sind fixe Parameter und Pfade im Code, die man eigentlich über eine Config einpflegen sollte.
Sobald ein Admin/Anwender putty an einem anderen Ort installiert, ist das Programm nicht nutzbar.
Sich hier auf feste Pfade zu verlassen, ist selten eine gute Idee, da es auch mal technische Gründe dagegen geben kann.
Auch irgendeine command.txt auszulesen sieht etwas abenteuerlich aus.
Wenn jemand diese böswillig manipuliert, kann er damit einiges an Schaden an richten.

Ich würde immern och empfehlen die Ursache zu ermitteln und zu beheben.
Ansonsten kann das thema dicht gemacht werden oder?

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

R
Rico913 Themenstarter:in
95 Beiträge seit 2020
vor 3 Jahren

Noch fix:

Dann liefere am besten Putty als portable Version gleich mit aus.

Installationen erlaubt und managed unsere IT-Abteilung. Wir "suchen" uns im SoftwareCenter nur was wir haben wollen und IT installiert es. Somit ist auch schon mal sichergestellt, dass alle Nutzer denselben Softwarepfad haben.

Die Command.txt hat den Grund, dass ich, aus welchem Grund auch immer, keine Befehlseingabe zustandekommt bzw. ich nichts auslesen kann. Command.txt liegt auf einem schreibgeschützten Laufwerk -> Schutz vor Manipulation.

Wie schon gesagt - Zwischenlösung - das heißt nicht, dass die Lösung über einen langen Zeitraum auf sich warten lässt. Ich bin dran, aber in der Zwischenzeit, hilft es uns im Arbeitsleben.

Jetzt kann's geschlossen werden. VG