Debain: SSH authorized_keys

[bu1137]

Wie meinst du "nach dem Key mich noch einloggen kann per Passwort?"

Entweder du aktivierst PasswordAuthentication, oder eben nicht. Du kannst es zwar zb. auf bestimmte user oder gar IP Adressen limitieren, aber es funktioniert dann logischerweise immer.

 

[Domi83]

Doh! Nein wie dämlich von mir
Nun mault er rum wenn ich mit einlogge von wegen PublicKey!

Ohh nein...

Und du hast auch das # vor PasswordAuthentication no weggenommen?

Ja.. darauf wollte ich eingehen, aber es sind alle viel zu schnell.. ich hoffe das wurde auch bedacht.

Aber erstmal sichergehen, dass du auch wirklich per Key einloggen kannst...

Nachtrag: Das hatte mir damals bei der ersten Einrichtung geholfen.

 

[[grueni]]

sehr schön

du meinst per SSH-Key und zwingend dann noch das richtige Passwort?

Oder meinst du per SSH-Key oder alternativ per Passwort?

Ich dachte halt nach der Key Auth nochmal Username+Passwort.

@Domi83: Ja, zu schnell und dann leider die Raute übersehen
Genau das! ^^ hatte ich auch als letztes genutzt Lag ja scheinbar nur an dem #

 

[xone92]

Wie meinst du "nach dem Key mich noch einloggen kann per Passwort?"

Entweder du aktivierst PasswordAuthentication, oder eben nicht. Du kannst es zwar zb. auf bestimmte user oder gar IP Adressen limitieren, aber es funktioniert dann logischerweise immer.

Stimmt nicht :-) man kann durchaus beides aktiv haben, es wird dann der richtige SSH-Key UND das Passwort benötigt.

Ich dachte halt nach der Key Auth nochmal Username+Passwort.

Es muß mit RequiredAuthentications2 gehen, das ist ein Config-Keyword in der sshd_config

Ich kenne es von Redhat 6.3, das ist da ein neues Feature:

http://docs.redhat.com/docs/en-US/R...se_Notes/authentication_interoperability.html (hier der Absatz Multiple required methods of authentication for sshd)

Da müßtest du dich mal etwas einlesen. Gehen tut es auf jeden Fall. Ob unter Debian weiß ich aber nicht.

Und vielleicht braucht man diese doppelte Sicherheit ja garnicht? Wenn jemand an deinen private-SSH-Key gekommen ist hast du eh ein größeres Problem.

 

[Domi83]

]Ich dachte halt nach der Key Auth nochmal Username+Passwort.

Hm.. Also möchtest Du eine doppelte Abfrage haben. Mir ist so nichts bewusst, dass man Key-File und anschließend User + Pass angeben kann / muss. Was mir so spontan einfällt ist, Du kannst das Key-File mit einem Kennwort versehen.

Wenn Du Dich dann mit Putty an deinem SSH anmeldest, fragt er erst noch nach dem Kennwort und anschließend verwendet der SSHd dein Keyfile zum identifizieren. Wäre das eine Variante?

Nachtrag: Okay, "RequiredAuthentications2" kannte ich noch nicht.

 

[[grueni]]

Ich lese mich grad ein wenig ein, was mich stutzig macht, ich werde beim Login immer nach der Passphrase von meinem PrivKey gefragt, ich lese aber immer wieder das durch das keyfile meistens kein PW abgefragt wird ?

Kurz gesagt ich öffne Putty, gib den Pfad zu meinem PrivKey an und öffne die Verbindung: Dann meinen Username eintippen und dann fragt er nach dem Passwort für den key.

Edit: Klar hab ihn ja auch verschlüsselt Es wird zu spät...Scheinbar kann nur Red-Hat RequiredAuthentications2 zumindest finde ich nur etwas im Bezug auf Red-Hat

Edit2: Das stimmt, wenn mir den Key jemand klaut Will eigentlich nur ein rel. sicheres System haben, was ich auch mal zu Hause in die Welt los lassen kann, ohne das mir ein Script Kiddi in die Quere kommt! Aber das sollte ja soweit erstmal reichen.

 

[Troublegum]

Man kann Keys mit oder ohne Passphrase erstellen. Wenn man die Passphrase bei der Erstellung weglässt, muss man später natürlich auch nichts eingeben.

 

[xone92]

Ich lese mich grad ein wenig ein, was mich stutzig macht, ich werde beim Login immer nach der Passphrase von meinem PrivKey gefragt, ich lese aber immer wieder das durch das keyfile meistens kein PW abgefragt wird ?

Kurz gesagt ich öffne Putty, gib den Pfad zu meinem PrivKey an und öffne die Verbindung: Dann meinen Username eintippen und dann fragt er nach dem Passwort für den key.

Man kann den PrivKey auch ohne Passwort abspeichern. Braucht man sogar für diverse Fälle so, für alle Sachen wo eine Passwortelose Verbindung nötig ist (automatischer Datenabgleich etc.). Aber man muss dann wissen das jeder der PrivKey hat sich einloggen kann. Da sollte man aufpassen das der Schlüssel nie in die falschen Hände gelangt.

Edit: Klar hab ihn ja auch verschlüsselt Es wird zu spät

geht mir auch so gute Nacht

...Scheinbar kann nur Red-Hat RequiredAuthentications2 zumindest finde ich nur etwas im Bezug auf Red-Hat

kann gut sein, Redhat ist da oft vorne dran.

 

[[grueni]]

Das stimmt, wobei man könnte ja sonst einen Extra User+Key erstellen und verteilen, und per cron dann die Abzugleichenden Sachen in ein "öffentliches" Verzeichnis legen etc.

Aber gut, die Geschichte hier dürfte erledigt sein, wir sehen uns beim n. Problem

@xone92: Ist doch mehr für Unternehmen gedacht, bzw. ist eigentlich nicht DIE Distri für "normale" User
Good Night

 

[xone92]

Das stimmt, wobei man könnte ja sonst einen Extra User+Key erstellen und verteilen, und per cron dann die Abzugleichenden Sachen in ein "öffentliches" Verzeichnis legen etc.

Stimmt exakt, so macht man das. Für Automatisierungen nutzt man separate SSH-Keys, die sind dann auch so eingestellt das Sie nur von bestimmten Quellservern funktionieren.

@xone92: Ist doch mehr für Unternehmen gedacht, bzw. ist eigentlich nicht DIE Distri für "normale" User
Good Night

Auch richtig wenn man mit Linux-Servern allerdings Geld verdienen will (wie ich) muß man eben Redhat Enterprise Linux oder SuSE-SLES nehmen. Alleine schon wegen dem Hardware-Support von den Serverherstellern wie HP oder FTS. Da hat man mit Ubunutu oder anderen Distributionen einfach mal Pech. Meine Lieblingskombination sind HP Proliant-Server mit Redhat, da kann man alles von der Hardware überwachen Mit SuSE-SLES geht es ähnlich - derzeit gefällt mir aber die gesammte Konfiguration von Redhat besser. Das sind aber alles Befindlichkeiten. Sonst sind Redhat + SuSE-SLES ähnlich.

 

[Domi83]

Auch richtig wenn man mit Linux-Servern allerdings Geld verdienen will (wie ich) muß man eben Redhat Enterprise Linux oder SuSE-SLES nehmen.

Naja, es kommt ja auch immer auf die Anwendungsgebiete drauf an. Für root oder vServer reicht auch im Regelfall ein Debian aus. Und wer sich RedHat nicht leisten kann / will, kann ja auch erst einmal mit CentOS anfangen.

Das war zumindest mein Plan, denn damit habe ich persönlich noch nie gearbeitet.. mal die Paketverwaltung anschauen, ob die auch so komfortabel ist wie "aptitude" von Debian.

 

[xone92]

Naja, es kommt ja auch immer auf die Anwendungsgebiete drauf an. Für root oder vServer reicht auch im Regelfall ein Debian aus. Und wer sich RedHat nicht leisten kann / will, kann ja auch erst einmal mit CentOS anfangen.

Stimmt schon, mit Debian kann man auch ganz gut arbeiten. Wenn du dann aber "richtige" Datenbanken wie Oracle oder Informix auf den Servern hast oder Cluster-Software wie Veritas kommst du um Redhat / SuSE-SLES nicht herum. Man bekommt ja ziemlich strikte Vorgaben auf welchem Linux das supportet wird. Und wenn du in einer Firma arbeitest mußt du dich auf wenige Distributionen konzentrieren. Man kann es vielleicht nicht jedem recht machen - aber muß ja vielleicht auch nicht sein.

Das war zumindest mein Plan, denn damit habe ich persönlich noch nie gearbeitet.. mal die Paketverwaltung anschauen, ob die auch so komfortabel ist wie "aptitude" von Debian.

Unter Redhat ist es yum - auch ganze tauglich. Die üblichen Funktionen gehen (update, upgrade, remove). Man kann auch verschiedene Repos haben, Abhängigkeiten werden auch beachtet.

 

[Domi83]

Okay.. gut zu wissen. Dann schaue ich mir mal CentOS an, um schon mal einen geringen Einblick in Redhat zu bekommen Bis dato sind es ja nur Kleinigkeiten die meine Server machen. Die root-Server machen das übliche wie FTP, Apache (php, mysql), postfix und dovecot und der Server im Büro hat z.B. Samba drauf.

Also wäre es mal nicht schlecht, sich mal mit dem System zu befassen..