2012-09-26 7 views
6

Ich habe Probleme beim Zugriff auf ein SVN-Repository mit TortoiseSVN 1.7.8.TortiseSVN svn + ssh Fehler: Verbindung zu einem Repository unter URL nicht möglich ... Netzwerkverbindung unerwartet geschlossen

Das SVN-Repository befindet sich auf einer CentOS 6.3-Box mit openssh 5.3p1:81.el6 und scheint ordnungsgemäß zu funktionieren.

# svnadmin --version 
# svnadmin, version 1.6.11 (r934486) 

ich das Repository von einem anderen CentOS-Box mit diesem Befehl aufrufen:

svn list svn+ssh://[email protected]/var/svn/joetest 

Aber wenn ich TortiseSVN von einer Workstation Win 7 mit nicht in der Lage, das Repository zu durchsuchen versuchen, ich bin so zu tun, mit der folgende Pfad:

svn+ssh://[email protected]/var/svn/joetest 

ich erhalte den folgenden Fehler von TortoiseSVN:

Unable to connect to a repository at URL 'svn+ssh://[email protected]/var/svn/joetest' To better debug SSH connection problems, remove the -q option from 'ssh' in the [tunnels] section of your Subversion configuration file. Network connection closed unexpectedly

Ich kann über SSH von der Arbeitsstation mit Putty anmelden.

Die Ergebnisse sind die gleichen, wenn ich versuche, Zugriff als root.

Ich habe das Eigentum an dem Repository /var/svn/ zu USER:USER gegeben und lief
chmod 2700 -R /var/svn/.

Da ich über ssh von einer anderen Linux-Box auf das Repository zugreifen kann, scheinen Berechtigungen nicht das Problem zu sein.

Wenn ich die Protokolldatei mit tail -fn 2000 /var/log/secure sehen, sehe ich die folgende jedes Mal TortiseSVN nach dem Passwort fragt:

Sep 26 17:34:31 dev sshd[30361]: Accepted password for USER from xx.xxx.xx.xxx port 59101 ssh2 
Sep 26 17:34:31 dev sshd[30361]: pam_unix(sshd:session): session opened for user USER by (uid=0) 
Sep 26 17:34:31 dev sshd[30361]: pam_unix(sshd:session): session closed for user USER 

ich tatsächlich in der Lage bin zu melden, aber die Sitzung wird dann sofort geschlossen.

Es fiel mir auf, dass die Sitzung für USER von root (uid=0) geöffnet wird, die richtig sein kann, aber ich werde es erwähnen, falls es etwas mit dem Problem zu tun hat.

Ich schaute in die Änderung der svnserve.conf, aber soweit ich sagen kann, es ist nicht beim Zugriff auf das Repository über svn+ssh verwendet, wird eine private Svnserve-Instanz für jede Anmeldung über diese Methode erstellt. Aus dem Handbuch:

There's still a third way to invoke svnserve, and that's in “tunnel mode”, with the -t option. This mode assumes that a remote-service program such as RSH or SSH has successfully authenticated a user and is now invoking a private svnserve process as that user. The svnserve program behaves normally (communicating via stdin and stdout), and assumes that the traffic is being automatically redirected over some sort of tunnel back to the client. When svnserve is invoked by a tunnel agent like this, be sure that the authenticated user has full read and write access to the repository database files. (See Servers and Permissions: A Word of Warning.) It's essentially the same as a local user accessing the repository via file:/// URLs.

Die einzigen Nicht-Standardeinstellungen in sshd_config sind:

Protocol 2 # to disable Protocol 1 

SyslogFacility AUTHPRIV 

ChallengeResponseAuthentication no 

GSSAPIAuthentication yes 
GSSAPICleanupCredentials yes 

UsePAM yes 

AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES 
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT 
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE 
AcceptEnv XMODIFIERS 

X11Forwarding no 

Subsystem  sftp /usr/libexec/openssh/sftp-server 

Irgendwelche Gedanken?

+0

Nur ein Gedanke gesetzt ist, versuchen Nimm den USER @ aus der URL und warte darauf, dass tortoise nach den Zugangsdaten fragt. Nicht sicher, ob es funktioniert, aber es ist einen Versuch wert. – Scott

+0

Danke für den Vorschlag, aber das gleiche Ergebnis. – codewaggle

+0

Wenn Sie den Tortoise Repo-Browser öffnen, welchen Fehler gibt es? – Scott

Antwort

4

Ich fand endlich eine Lösung dafür.In der TortoiseSVN FAQ aller Plätze:
TortoiseSVN Frequently asked questions

Aus der FAQ:
SVN+SSH: Connection closed unexpectedly

It has been reported that svn+ssh connections of the form svn+ssh://[email protected] which were previously working, stop working with TortoiseSVN 1.5. This seems to be related to plink, and occurs if you have a default hostname set in PuTTY.

If this is the case you can fix it by using regedit or regedt32 to clear HKEY_CURRENT_USER/Software/SimonTatham/Putty/Sessions/Default%20Settings/HostName.


Another user has reported the following server-side fix:

  • ssh into your account
  • cd ~
  • cp /etc/bashrc .bashrc
  • nano .bashrc
  • put a # before the line "mesg y" (which comments it out)
  • Ctrl+X to exit, press Y when prompted to save.

versuchte ich nicht den ersten Ansatz meiner Registrierung bearbeiten.

Der zweite Ansatz der Bearbeitung der Bash-Konfiguration funktionierte für mich.

Eine Notiz über die Bash-Konfigurationsmethode:

Wenn Sie auf Shared-Hosting, Ihre Benutzer .bashrc geeignet, die globalen/etc/bashrc werden geladen wird. Sie können die globale Datei nicht bearbeiten, daher müssen Sie das umgehen.

Einige mögliche Ansätze:

  • Try mesg n Ihrem Benutzer .bashrc-Datei hinzufügen. Ich bin mir nicht sicher, ob das funktioniert oder ob es vor oder nach dem globalen Datei geladen werden sollte.

  • Fügen Sie nicht die globale Datei und hard-code alle Einstellungen in Ihrem Benutzer .bashrc Datei.

  • Entfernen Sie die Einstellung mesg y aus der globalen Datei/etc/bashrc, da sie geladen wird. Diese Frage diskutiert, wie das tun: Use a grepped file as an included source in bash

+0

Ich versuche genau dasselbe zu tun und erhalte die identische Fehlermeldung, die Sie oben gepostet haben. Ich kann jedoch eine Verbindung zu meinem Repo herstellen, indem ich die GUI benutze und mit svn + ssh: // user @ ip/repo darauf blicke, aber es wird mir nicht erlauben, dies über die Befehlszeile zu tun. Hattest du Glück dabei, die Befehlszeile zu verwenden? –

+0

@nkon Es war ein kleines Projekt und ich habe keinen Zugriff mehr auf diesen Server, also kann ich nicht dagegen testen. Ich schlage vor, dass Sie eine Frage öffnen und alle Details über die Befehle, die funktionieren und nicht zusammen mit den Protokolleinträgen und Ihrer Konfiguration für SVN, SSH und BASH (ähnlich wie ich in meiner Frage und Antwort enthalten). Das wird die beste Gelegenheit für jemanden geben, um zu sehen, was das Problem verursachen könnte. Fügen Sie hier einen Kommentar hinzu, nachdem Sie die Frage erstellt haben, und ich werde einen Blick darauf werfen. – codewaggle

2

eine alte Frage, aber immer noch oben auf den Stapel auf Google, so dass ich dachte, dass ich meine Lösung teilen würde.

Einfach, weil ich kein "Home" -Verzeichnis für meinen Benutzer auf dem Server hatte. Durch das Ändern des SSH-Clients in die mit Putty gelieferte plink.exe (Rechtsklick auf den Ordner | TortoiseSVN | Einstellungen | Netzwerk) konnte ich den Fehler sehen, als die Fenster auf dem Bildschirm erschienen.

0

In meinem Fall war der Grund, dass der Svnuser keine Shell hat (es war/bin/false).
Dies ist im ssh-Protokoll nicht sichtbar, selbst wenn ssh -vvv debuggt.

Wenn Sie diese Art von Problem Ihr Debug-Ausgabe wie diese

debug1: Entering interactive session. 
debug1: Remote: Forced command. 
debug1: Remote: Port forwarding disabled. 
debug1: Remote: Agent forwarding disabled. 
debug1: Remote: X11 forwarding disabled. 
debug1: Remote: Pty allocation disabled. 
debug1: Remote: Forced command. 
debug1: Remote: Port forwarding disabled. 
debug1: Remote: Agent forwarding disabled. 
debug1: Remote: X11 forwarding disabled. 
debug1: Remote: Pty allocation disabled. 
debug1: Sending environment. 
debug1: Sending env LANG = en_GB.UTF-8 
debug1: Sending command: svnserve -t 
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0 
debug1: channel 0: free: client-session, nchannels 1 

aussehen wird, wenn die Shell/bin/bash die Protokolländerungen

debug1: Sending env LANG = en_GB.UTF-8 
debug1: Sending command: svnserve -t 
Path: MyRepo 
URL: svn+ssh://[email protected]/MyRepo 
Verwandte Themen