2012-09-26 29 views
6

Mam problemy z dostępem do repozytorium SVN przy użyciu TortoiseSVN 1.7.8.TortiseSVN svn + ssh Błąd: nie można połączyć się z repozytorium pod adresem URL ... Połączenie sieciowe zostało nieoczekiwanie zamknięte

Repozytorium SVN znajduje się na pudełku CentOS 6.3 z openssh 5.3p1:81.el6 i wygląda na prawidłowe funkcjonowanie.

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

mogę uzyskać dostęp do repozytorium z innego pole CentOS z tym poleceniem:

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

ale gdy próbuję przeglądać repozytorium korzystając TortiseSVN z Win 7 stacji roboczej jestem w stanie to zrobić za pomocą następujące ścieżki:

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

otrzymuję następujący błąd z 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

Jestem w stanie zalogować się przez SSH ze stacji roboczej za pomocą programu Putty.

Wyniki są takie same, jeśli próbuję uzyskać dostęp jako root.

Dałem własność repozytorium /var/svn/ do USER:USER i pobiegł
chmod 2700 -R /var/svn/.

Ponieważ mogę uzyskać dostęp do repozytorium przez ssh z innego Linux-a, uprawnienia nie wydają się być problemem.

Kiedy oglądam plik dziennika używając tail -fn 2000 /var/log/secure, widzę po każdym TortiseSVN prosi o hasło:

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 

Właściwie jestem w stanie się zalogować, ale sesja jest wtedy zamknięty natychmiast.

Przyłapałem się na tym, że sesja jest otwierana dla użytkownika USER przez root (uid=0), co może być poprawne, ale wspomnę o tym na wypadek, gdyby miało to związek z problemem.

Zajrzałem do modyfikacji svnserve.conf, ale z tego co wiem, nie jest używane podczas uzyskiwania dostępu do repozytorium poprzez svn+ssh, prywatna instancja svnserve jest tworzona dla każdego logowania za pomocą tej metody. Z instrukcji:

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.

Jedyne ustawienie niestandardowe w sshd_config są:

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 

Wszelkie myśli?

+0

tylko myśl, spróbuj usuwając UŻYTKOWNIKa @ z adresu URL i czekając, aż żółw poprosi o poświadczenia. Nie jestem pewien, czy to zadziała, ale warto spróbować. – Scott

+0

Dzięki za sugestię, ale ten sam wynik. – codewaggle

+0

Kiedy otwierasz przeglądarkę repo Tortoise, jaki błąd ci daje? – Scott

Odpowiedz

4

W końcu znalazłem rozwiązanie tego problemu.W TortoiseSVN FAQ wszystkich miejscach:
TortoiseSVN Frequently asked questions

Z 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.

nie próbowałem pierwsze podejście edycji mojego rejestru.

Drugie podejście do edycji konfiguracji bash zadziałało dla mnie.

Uwaga na temat sposobu konfiguracji bash:

Jeśli jesteś na dzielonego hostingu, plik .bashrc użytkownik prawdopodobnie ładowania globalnego pliku/etc/bashrc. Nie będziesz w stanie edytować pliku globalnego, więc musisz to obejść.

Niektóre z możliwych podejść:

  • spróbuj dodać mesg n do pliku .bashrc użytkownika. Nie jestem pewien, czy ten będzie działał, czy powinien być umieszczony przed lub po załadowaniu globalnego pliku .

  • Nie dołączaj pliku globalnego i kodu źródłowego do wszystkich ustawień w pliku użytkownika .bashrc.

  • Usuń ustawienie mesg y z pliku globalnego/etc/bashrc w trakcie ładowania . To pytanie omawia, jak to zrobić: Use a grepped file as an included source in bash

+0

Próbuję zrobić dokładnie to samo i otrzymuję identyczny komunikat o błędzie, który napisałeś powyżej. Mogę jednak połączyć się z moim repo poprzez użycie gui i przeglądanie go za pomocą svn + ssh: // user @ ip/repo, ale nie pozwoli mi to zrobić za pomocą wiersza poleceń. Czy miałeś szczęście, robiąc to za pomocą wiersza poleceń? –

+0

@nkon To był mały projekt i nie mam już dostępu do tego serwera, więc nie mogę go przetestować. Sugeruję, abyś otworzył pytanie i zawarł wszystkie szczegóły dotyczące poleceń, które działają i nie działają razem z wpisami do dziennika i twoją konfiguracją dla SVN, SSH i BASH (podobnie do tego, co zawarłem w moim pytaniu i odpowiedzi). Da to najlepszą okazję, aby ktoś mógł zobaczyć, co może być przyczyną problemu. Dodaj komentarz tutaj po utworzeniu pytania, a ja go przyjrzę. – codewaggle

2

Stare pytanie, ale wciąż do góry stosu w Google, więc pomyślałem, że dzielę rozwiązanie.

Po prostu dlatego, że nie miałem katalogu "home" dla mojego użytkownika na serwerze. Zmiana klienta SSH na plik plink.exe dołączony do aplikacji Putty (kliknięcie prawym przyciskiem myszy na folderze | TortoiseSVN | Ustawienia | Sieć) umożliwił mi zobaczenie błędu, gdy okna pojawiły się na ekranie.

0

W moim przypadku przyczyną było to, że svnuser nie ma powłoki (było to/bin/false).
Nie jest to widoczne w logu ssh nawet przy debugowaniu ssh -vvv.

Gdy masz tego typu problem twoje wyjście debugowania będzie wyglądać następująco

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 

Gdy powłoka jest ustawiony na/bin/bash zmiany dziennika do

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