ssh verbindung mit sich selbst

Also, ich habe jetzt endlich mal eine Linux-Maschine zum testen nutzen können. Du hättest einfach deine Logdatei finden sollen, oder die Berechtigungen von ~/.ssh posten sollen. Wenn du deine Logdatei gefunden hättest, hättest du folgendes gesehen:

Korrekt wäre etwas in folgender Art:

Beides habe ich in 5min auf einem Linux-System mit LogLevel VERBOSE in der sshd_config erstellen können. Was anderes kann eigentlich nicht der Grund sein. Dazu reicht es, wenn das Verzeichnis von anderen beschreibbar ist, um einen erfolgreichen Login zu verhindern. Hier die Lösung:

Sollte das wider Erwarten nicht die Lösung sein, dann kommen wir ohne Logfile nicht weiter. Aber so oder so, solltest du wissen, wo dein SSH die Meldungen hinschreibt...


Ich habe die Rechte in Post #7 dieses Threads geposted. Habe jetzt die selben rechte wie du:
Code:
administrator@biostat1:/var/log$ ls -la ~/.ssh
total 28
drwx------  2 administrator administrator 4096 Nov  9 14:02 .
drwxr-xr-x 32 administrator administrator 4096 Aug 27 09:30 ..
-rwx------  1 administrator administrator  232 Nov  9 14:01 authorized_keys
-rwx------  1 administrator administrator  887 Nov  9 14:01 id_rsa
-rwx------  1 administrator administrator  232 Nov  9 14:01 id_rsa.pub
-rwx------  1 administrator administrator  232 Nov  9 14:01 id_rsa.self
-rwx------  1 administrator administrator  446 Nov  9 14:02 known_hosts
administrator@biostat1:/var/log$ ssh -i ~/.ssh/id_rsa administrator@10.4.1.168
administrator@10.4.1.168's password: 

administrator@biostat1:/var/log$ ssh administrator@10.4.1.168
administrator@10.4.1.168's password: 

administrator@biostat1:/var/log$ chmod 700 ~.ssh/
chmod: cannot access `~.ssh/': No such file or directory
administrator@biostat1:/var/log$ chmod 700 ~/.ssh/
administrator@biostat1:/var/log$ ssh administrator@10.4.1.168
administrator@10.4.1.168's password:
Ist toll das du das in 5min hin bekommst. Bei dem Rechner funkts halt leider nicht in 5 min. Mit VERBOSE in der sshd_conf logged das ding nicht in /var/log/. Sonst hätte grep ja was gefunden.

Hab jetz auf 2 anderen Rechnern (1x mit Ubuntu 9.04, 1x 8.04) das loglevel auf VERBOSE gesetzt. Da funktionierts dann auch wunderbar sogar in weniger als 5 minuten (guckst du).

Ich setz den jetzt neu auf, dann bin ich in einer Stunde fertig. Das ist nähmlich eine Workstation, auf die viele Leute, auch als root (k.a. warum), Zugang hatten. Ich will den nähmlich jetzt als Masternode für einen PS3 cluster nehmen. Da ists wahrscheinlich eh besser wenn der neu und sauber aufgestzt ist.

Auf jeden Fall danke für deine/eure Hilfe.
 
Zuletzt bearbeitet:
Entschuldige meinen letzen Post. Ich bin etwas ratlos. Mir ist es total schleierhaft, wo denn dann das Log hingeht. Was für ein Linux ist das denn? (Wenn schon weiter oben beantwortet, sorry fürs erneute Fragen, bitte trotzdem beantworten) Installier doch mal syslog-ng und konfigurier es entsprechend.

Eine weitere Idee: Vielleicht stimmt etwas mit dem Key/der authorized_keys nicht? Mach doch einfach die Datei einmal leer und generier den Key neu und trag ihn neu dort ein. Idealerweise mit einem Tool wie ssh-copy-id oder ähnlichem, das geht eigentlich immer glatt. Dann die Berechtigungen nochmal kontrollieren und testen. Es kann eigentlich nur ein Problem mit dem Key oder Berechtigungen sein.

Probier einmal in der sshd_config
Code:
AuthorizedKeysFile .ssh/authorized_keys
einzutragen.
 
Entschuldige meinen letzen Post. Ich bin etwas ratlos. Mir ist es total schleierhaft, wo denn dann das Log hingeht. Was für ein Linux ist das denn? (Wenn schon weiter oben beantwortet, sorry fürs erneute Fragen, bitte trotzdem beantworten) Installier doch mal syslog-ng und konfigurier es entsprechend.
ubuntu 9.04
Eine weitere Idee: Vielleicht stimmt etwas mit dem Key/der authorized_keys nicht? Mach doch einfach die Datei einmal leer und generier den Key neu und trag ihn neu dort ein. Idealerweise mit einem Tool wie ssh-copy-id oder ähnlichem, das geht eigentlich immer glatt. Dann die Berechtigungen nochmal kontrollieren und testen. Es kann eigentlich nur ein Problem mit dem Key oder Berechtigungen sein.
hab ich schon zig mal probiert
auch mit ssh-copy-id
auch unter neuen benutzer
Probier einmal in der sshd_config
Code:
AuthorizedKeysFile .ssh/authorized_keys
einzutragen.
steht schon drinnen.

wie schon gsagt - hab keine zeit und lust noch länger rum zu probieren werd den einfach neu aufsetzen.

trotzdem danke für die hilfe.
 
In der Config steht %h/.ssh/..... drin, daher diese Idee.
 
Hatte noch eine idee befor ich alles neu aufsetze:
  • hab jetz einfach openssh-* deinstalliert
  • bei allen benutzern ~/.ssh/ gelöscht
  • openssh-server neu installiert
jetzt gehts.

thx again
 
war auskommentiert aber hat sich nichts geändert:
**********$ sudo /etc/init.d/ssh restart
* Restarting OpenBSD Secure Shell server sshd [ OK ]
* OpenBSD Secure Shell server not in use (/etc/ssh/sshd_not_to_be_run)

Ist diese Meldung normal bei ubuntu?
 
Nein, ist sie nicht.
Was ist denn dieses ".....not_to_be_run"? Die gibt's bei meinem Ubuntu nicht, vielleicht liegts daran?

/Edit:

Code:
{-alex-|-asterix-} => [/etc/ssh]
(17:01:07) sudo touch /etc/ssh/sshd_not_to_be_run
{-alex-|-asterix-} => [/etc/ssh]
(17:02:29) sudo /etc/init.d/ssh restart
 * Restarting OpenBSD Secure Shell server sshd                           [ OK ] 
 * OpenBSD Secure Shell server not in use (/etc/ssh/sshd_not_to_be_run)
{-alex-|-asterix-} => [/etc/ssh]
(17:02:32) sudo rm /etc/ssh/sshd_not_to_be_run 
{-alex-|-asterix-} => [/etc/ssh]
(17:02:50) sudo /etc/init.d/ssh restart
 * Restarting OpenBSD Secure Shell server sshd                           [ OK ]

/Edit2: Also ja, es liegt daran.

Mal bloed gefragt: Warum will man sich eigentlich mit localhost via ssh verbinden?
 
Zuletzt bearbeitet:
Mal bloed gefragt: Warum will man sich eigentlich mit localhost via ssh verbinden?

Ich kann mir vorstellen, dass z.B. in einem script per ssh mehrere Server abgefragt werden incl. localhost und dafür nicht extra ne if(case)-schleife gebaut werden soll....
Also ssh für alle, auch wenn's der localhost ist.
 
Es gibt einen gnu ssh server. LSH. Der war/ist wohl Standard bei Ubuntu. Bumm, daher keine Log-Ausgaben. Daher keine Wirksamkeit der Konfig, daher alles sch****
 
Mal bloed gefragt: Warum will man sich eigentlich mit localhost via ssh verbinden?

Ich bin gerade dabei einen cluster zu testzwecken zu bauen. Server ist eine handelsübliche HP Workstation mit 4GB Ram. Slaves sind Sony PS3s.

Um Parallele Berechnungen ausführen zu können verwende ich OpenMPI welches die Verteilung übernimmt. Damit OpenMPI dies machen kann muss jeder Knoten im Cluster mit jedem (auch mit sich selbst) über ssh ohne passwortabfrage kommunizieren können.

Habe OpenMPI schon auf einem anderen Rechner (4xAmd Quad Core und 32GB Ram) am laufen und möchte den dann mit den 8 - 16 PS3s um einige Prozessoren erweitern.
 
Zuletzt bearbeitet:
ein strace müsste eigentlich offenbaren wo der sshd versucht seine config/keyfiles zu lesen. *duck un wech*...
 

Ähnliche Themen

Zugriff Ubuntu 16.04. auf Freigabe 18.04. LTS nicht möglich

Zugriff auf Samba Fileserver Freigaben verweigert(Samba 4 Active Directory Domäne)

Samba 4 Gast Zugang unter Ubuntu funktioniert nicht

JBidWatcher: Problem bei loading Auctions in Verbindung mit mySQL

Windows clients können nicht mehr auf lange laufendes System zugreifen

Zurück
Oben