Problem mit OpenSSH auf Solaris 10 (Sparc) - keine Verbindung von none Shell SSH

[avalox]

Hi,

ich hab eine kleines Problem mit OpenSSH (SMCosh561a) auf einer meiner Solaris 10 Kisten.

Ich hab soweit alle nötigen Pakete von sunfreeware installiert und er läuft soweit auch mehr oder weniger problemlos.

Es besteht nur ein Problem mit SSH Clients alá SecureCRT, Putty etc. Mit diesen Clients kann ich mich nicht verbinden. Wenn ich eine SSH Verbindung von einer Shell (Linux, Solaris...) öffne, geht das einwandfrei.

Ich hab den LogLevel schon auf debug gestellt, jedoch sehe ich da keinen Fehler...bzw. kommt mir nichts komisch vor.

Vielleicht kann mir von euch jemand helfen?!

Hier mal eine funktionierende SSH Verbindung zum OpenSSH (von einer Solaris Shell).

http://pastebin.com/er8RzDYY

Hier dann eine Verbindung per SecureCRT

http://pastebin.com/1g5vjbi0

Ich hab 3 verschiedene SSH Clients ausprobiert. Mit keinem kann ich mich verbinden. Von einer Shell klappts immer.

Hoffe jemand von euch hat eine Idee?!

Danke und Gruß
Sebastian

[signal_15]

Servas,

gibt der client (securecrt/putty) eine fehlermeldung aus? wie lautet die?

ct,

[avalox]

leider gar keine Fehlermeldungen

[signal_15]

nur weil's mich interessiert. wieso willst du den ssh server von sunfreeware nutzen? ist der, der bei solaris dabei ist nicht gut genug?

ct,

[avalox]

da ist noch Sun_SSH_1.1 drauf und bisher bin ich daran gescheitert die 1.3 zu finden um den zu updaten. Daher wollte ich stattdessen auf OpenSSH setzen.

[signal_15]

so auf anhieb springt mir aus den logs nichts ins auge. abgesehen davon, dass bei der verbindung mit securecrt die authorized keys nicht gefunden werden.

[avalox]

das ist soweit auch ok..wenn ich die reihenfolge umstelle (also erst passwort) ändert das leider auch nichts

[signal_15]

da ist noch Sun_SSH_1.1 drauf und bisher bin ich daran gescheitert die 1.3 zu finden um den zu updaten. Daher wollte ich stattdessen auf OpenSSH setzen.

das beantwortet nicht meine frage. brauchst du dringend eine funktion, die sun_ssh nicht bietet?

btw: ich bin mittlerweile von sunfreeware ganz weg und nutze nun opencsw.org. das pkgutil ist schon was feines.

ct,

[avalox]

wir hatte ein Audit, welches besagt hat, dass wir 1.1 nicht mehr nutzen dürfen. Ich bin also aktuell gezwungen ein Update zu machen

[avalox]

der tipp mit opencsw ware genial. danke. damit ging die openssh installation ohne problem und es funktioniert alles.

danke nochmal!

[Drusus]

Moin,

wir hatte ein Audit, welches besagt hat, dass wir 1.1 nicht mehr nutzen dürfen. Ich bin also aktuell gezwungen ein Update zu machen

dann solltet ihr euch mal einen Auditor holen der grob Ahnung von dem hat was er macht. Versionsnummer zu vergleichen ist grober Unfug.
Welches Problem soll den SunSSH 1.1.5 (Patch 148096-04) haben?

Leider gibt es einige Auditoren die Tool-Ausgaben wir "Upgrade auf Version 1.1.1 / 1.3" nicht richtig als "Upgrade auf Version 1.1.1 oder 1.3" lesen koennen.

Tschau,
  Drusus.

[signal_15]

dann solltet ihr euch mal einen Auditor holen der grob Ahnung von dem hat was er macht. Versionsnummer zu vergleichen ist grober Unfug.

meiner meinung nach liegt das problem nicht am auditor sondern oft am management, welches nicht in der lage ist einen pruefbericht richtig zu lesen und zu deuten. bei mir ist es so, dass das mutterhaus in texas die firma 'Critical Watch' beauftragt hat unsere internetzugaenge quartalsweise zu pruefen. vier mal im jahr muss ich mich mit einem ungebildetem affen aus texas herumschlagen, der nicht versteht, dass es eine schlechte sache waere den tcp port 443 zum citrix secure gateway zu schliessen. erschwerend kommt hinzu, dass ich bei der hire-and-fire mentalitaet der amis bei jedem zweiten/dritten audit von vorne mit dem erklaeren beginnen kann weil der neue manager genauso wenig ahnung hat wie sein vorgaenger. ich hab es mir angewohnt die erklaerenden mails einfach noch mal an den neuen manager zu schicken. dabei tausche ich mittlerweile nicht einmal mehr die anrede aus.

das letzte mal kam wirklich die frage ob wir wirklich tcp/25 offen haben muessen. das waere ja nicht gut wegen spam-emails.

das audit von critical watch ist gar nicht mal so schlecht. es hat auch ein paar mal sachen offen gelegt wie zum beispiel bei einer apache konfiguration, die uns sonst nicht aufgefallen waeren und boese haetten enden koennen.

ct,

[vab]

Was Ihr da schreibt, klingt traurig... und gibt leider die Realität ziemlich genau wieder.  Der einzige Trost:  Es ist überall so. :-(


Gruß -- Volker