Nee - Miss(t)verständnis.
Das ist ne Installation - sowohl bei Cosinus wie auch bei mir.
Installation: Port frei, sshd läuft nicht (aber installiert).
Live: Port zu, sshd läuft auch nicht.
Das hier: CentOS-6.3-x86_64-LiveDVD.iso ist nur das von mir benutzte Installationsmedium.

stimmt. 
würde aber auch nicht wirklich Sinn machen bei einem Live-System.
Ansonsten ist es aber kein Problem, da sshd nicht einfach gestartet wird.

Wieso macht es denn dann Sinn per default im installierten System? Wenn schon so eine Firewall in CentOS drin ist, dann wäre wohl keine Ausnahme als default imho sinniger.
Wer den sshdaemon einrichtet wird wohl auch hoffentlich von selber auf die Idee kommen die FW-Settings zu checken und uhhh...wenn mal wieder "versehentlich" () oder so der sshserver nachinstalliert wurde ist die Kiste ja offen wie ein Scheunentor   

Sinn ist da eine Ansichtssache - für nen Server ist das schon richtig so.
Aber da der Dienst nicht läuft, machts keinen.

Kannste mal bitte bei Dir checken, ob der Dienst installiert ist und ob er läuft? Welche Iso hast Du genommen?

Ich hab die 32-Bit-Variante in meiner Test-VM benutzt
Also laufen tut der sshdaemon nicht.
Ich kann ihn aber starten, d.h. also er ist installiert aber nicht per default aktiv

 

Wieso macht es denn dann Sinn per default im installierten System? Wenn schon so eine Firewall in CentOS drin ist, dann wäre wohl keine Ausnahme als default imho sinniger.
Wer den sshdaemon einrichtet wird wohl auch hoffentlich von selber auf die Idee kommen die FW-Settings zu checken und uhhh...wenn mal wieder "versehentlich" () oder so der sshserver nachinstalliert wurde ist die Kiste ja offen wie ein Scheunento

Lies' Antwort #42!

 

SSH ist deswegen aktiviert, damit man auf den frisch installierten Rechner zugreifen kann - das w re ansonsten nicht m glich.

zum 4. Mal: das Ding läuft nicht
openssh-daemon wurde beendet
sshd            0:Aus 1:Aus 2:Aus 3:Aus 4:Aus 5:Aus 6:Aus ist nix mit Zugriff, wenn man's nicht selber startet/ändert

Ja hab ich doch gelesen Knuti. Wieso wird aber ein Loch in die FW gebohrt wenn der ssh-server eh nicht automatisch startet? Wer ssh benötigt kann ja selbst ssh starten und ein Loch bohren oder  ???

ich hatte gerade die 32-Bit Versionen am wickel
Installvariante
dort läuft er und es ist auch ein Löchlein in der FW

hab' gerad' mal die 64-Bit Version installiert
ssh läuft und loch in FW

So wär's i.O. und auch nachvollziehbar.
Ist ja interessant. 
Welche Iso haste denn genommen?
Haste benutzerdefieniert installiert oder wie wir DAUs?

Bei dir läuft der sshserver???  ??? ???
Komisch, ich hab CentOS 2x installiert weil ihr mir ja wieder nicht glauben wolltet 
 Immer schon weiter geklickt. Alles möglichst default. Ergebnis wie SQL auch schon sagte:

Live: sshd inaktiv / FW sperrt 22/tcp
Inst: sshd inaktiv / FW erlaubt 22/tcp

Von welcher Torrentka..e hast du DAS CentOS-Image?! "dein" CentOS ist ja noch unsicherer als "unser" CentOS

ftp.hosteurope.de

Install Variante Desktop-Minimal

 

CentOS ist ja noch unsicherer als "unser" CentOS

es entspricht den Vorgaben.

 

Live: sshd inaktiv / FW sperrt 22/tcp

Würde ja, wie bereits gesagt keinen Sinn machen
 

Inst: sshd inaktiv / FW erlaubt 22/tcp

das eigentlich auch nicht

Wie hast du das ermittelt?

Also wie man ermittelt, dass der sshserver nicht läuft sollte ja eigentlich klar sein zB:

1) ps -ef | grep -i ssh  ==> NIX!
2) netstat -tulpen | grep -i ssh ==> NIX!


/etc/init.d/sshd start ==> sshd wurde dann bei mir gestartet
(was ist eigentlich "besser" bzw. empfohlen? über /etc/init.d oder den "service" Befehl?)

 

das eigentlich auch nicht

Ähm doch! 
Firewallsettings geöffnet nachdem centOS frisch installiert wurde => Haken drin bei 22/tcp für ssh

=> nmap gemacht von meinem Wirt auf die centOS-VM => 22/tcp CLOSED
Wäre da keine Ausnahme stünde da FILTERED 
Natürlich OPEN als ich sshd gestartet habe 

Soweit nachvollziehbar? SQL-Freak hatte das ja auch so beobachtet. Nur du hast das wohl irgendwie anders 

Wie hast du das ermittelt?

/etc/init.d/sshd status nach Fehlermeldung "No route to host" bei Zugriffsveruch.

gehen wir mal von der Annahme aus, dass wir einen laufenden Dienst von einem nicht laufenden unterscheiden können 

(was ist eigentlich "besser" bzw. empfohlen? über /etc/init.d oder den "service" Befehl?)

guck Dir mal z.B. mit less das Script /sbin/service an

@Knut, warum bist denn so still? 
Verhält sich dein CentOS jetzt wirklich anders als bei SQL und mir? 

Bei der Minimal-Variante läuft der SSH-Server auch bei mir.
Wird wohl wirklich nur eine kleine Schlamperei in "unseren" Versionen sein.