TortiseSVN svn+ssh Error: Unable to connect to a repository at URL … Network connection closed unexpectedly
I'm having problems accessing an SVN repository using TortoiseSVN 1.7.8.
The SVN repository is on a CentOS 6.3 box with openssh 5.3p1:81.el6
and appears to be functioning correctly.
# svnadmin --version
# svnadmin, version 1.6.11 (r934486)
I can access the repository from another CentOS box with this command:
svn list svn+ssh://USER@xxx.xx.xx.xxx/var/svn/joetest
But when I attempt to browse the repository using TortiseSVN from a Win 7 workstation I'm unable to do so using the following path:
svn+ssh://USER@xxx.xx.xx.xxx/var/svn/joetest
I receive the following error from TortoiseSVN:
Unable to connect to a repository at URL
'svn+ssh://USER@xxx.xx.xx.xxx/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
I'm able to login via SSH from the workstation using Putty.
The results are the same if I attempt access as root.
I've given ownership of the repository /var/svn/
to USER:USER
and ranchmod 2700 -R /var/svn/
.
Because I can access the repository via ssh from another Linux box, permissions don't appear to be the problem.
When I watch the log file using tail -fn 2000 /var/log/secure
, I see the following each time TortiseSVN asks for the password:
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
I'm actually able to login, but the session is then closed immediately.
It caught my eye that the session is being opened for USER by root (uid=0)
, which may be correct, but I'll mention it in case it has something to do with the problem.
I looked into modifying the svnserve.conf
, but as far as I can tell, it's not used when accessing the repository via svn+ssh
, a private svnserve instance is created for each log in via this method. From the manual:
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.
The only non-default settings in sshd_config
are:
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
Any thoughts?
bash svn ssh tortoisesvn openssh
|
show 1 more comment
I'm having problems accessing an SVN repository using TortoiseSVN 1.7.8.
The SVN repository is on a CentOS 6.3 box with openssh 5.3p1:81.el6
and appears to be functioning correctly.
# svnadmin --version
# svnadmin, version 1.6.11 (r934486)
I can access the repository from another CentOS box with this command:
svn list svn+ssh://USER@xxx.xx.xx.xxx/var/svn/joetest
But when I attempt to browse the repository using TortiseSVN from a Win 7 workstation I'm unable to do so using the following path:
svn+ssh://USER@xxx.xx.xx.xxx/var/svn/joetest
I receive the following error from TortoiseSVN:
Unable to connect to a repository at URL
'svn+ssh://USER@xxx.xx.xx.xxx/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
I'm able to login via SSH from the workstation using Putty.
The results are the same if I attempt access as root.
I've given ownership of the repository /var/svn/
to USER:USER
and ranchmod 2700 -R /var/svn/
.
Because I can access the repository via ssh from another Linux box, permissions don't appear to be the problem.
When I watch the log file using tail -fn 2000 /var/log/secure
, I see the following each time TortiseSVN asks for the password:
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
I'm actually able to login, but the session is then closed immediately.
It caught my eye that the session is being opened for USER by root (uid=0)
, which may be correct, but I'll mention it in case it has something to do with the problem.
I looked into modifying the svnserve.conf
, but as far as I can tell, it's not used when accessing the repository via svn+ssh
, a private svnserve instance is created for each log in via this method. From the manual:
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.
The only non-default settings in sshd_config
are:
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
Any thoughts?
bash svn ssh tortoisesvn openssh
Just a thought, try taking the USER@ out of the URL and wait for tortoise to prompt for credentials. Not sure if it will work, but it is worth a try.
– Scott
Sep 26 '12 at 17:11
Thanks for the suggestion, but same result.
– codewaggle
Sep 26 '12 at 17:19
When you open the tortoise repo-browser, what error does it give you?
– Scott
Sep 26 '12 at 17:22
I added the error message near the top of the question.
– codewaggle
Sep 26 '12 at 17:41
Can you ssh ok using the same credentials?
– lucidcircus
Sep 28 '12 at 11:16
|
show 1 more comment
I'm having problems accessing an SVN repository using TortoiseSVN 1.7.8.
The SVN repository is on a CentOS 6.3 box with openssh 5.3p1:81.el6
and appears to be functioning correctly.
# svnadmin --version
# svnadmin, version 1.6.11 (r934486)
I can access the repository from another CentOS box with this command:
svn list svn+ssh://USER@xxx.xx.xx.xxx/var/svn/joetest
But when I attempt to browse the repository using TortiseSVN from a Win 7 workstation I'm unable to do so using the following path:
svn+ssh://USER@xxx.xx.xx.xxx/var/svn/joetest
I receive the following error from TortoiseSVN:
Unable to connect to a repository at URL
'svn+ssh://USER@xxx.xx.xx.xxx/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
I'm able to login via SSH from the workstation using Putty.
The results are the same if I attempt access as root.
I've given ownership of the repository /var/svn/
to USER:USER
and ranchmod 2700 -R /var/svn/
.
Because I can access the repository via ssh from another Linux box, permissions don't appear to be the problem.
When I watch the log file using tail -fn 2000 /var/log/secure
, I see the following each time TortiseSVN asks for the password:
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
I'm actually able to login, but the session is then closed immediately.
It caught my eye that the session is being opened for USER by root (uid=0)
, which may be correct, but I'll mention it in case it has something to do with the problem.
I looked into modifying the svnserve.conf
, but as far as I can tell, it's not used when accessing the repository via svn+ssh
, a private svnserve instance is created for each log in via this method. From the manual:
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.
The only non-default settings in sshd_config
are:
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
Any thoughts?
bash svn ssh tortoisesvn openssh
I'm having problems accessing an SVN repository using TortoiseSVN 1.7.8.
The SVN repository is on a CentOS 6.3 box with openssh 5.3p1:81.el6
and appears to be functioning correctly.
# svnadmin --version
# svnadmin, version 1.6.11 (r934486)
I can access the repository from another CentOS box with this command:
svn list svn+ssh://USER@xxx.xx.xx.xxx/var/svn/joetest
But when I attempt to browse the repository using TortiseSVN from a Win 7 workstation I'm unable to do so using the following path:
svn+ssh://USER@xxx.xx.xx.xxx/var/svn/joetest
I receive the following error from TortoiseSVN:
Unable to connect to a repository at URL
'svn+ssh://USER@xxx.xx.xx.xxx/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
I'm able to login via SSH from the workstation using Putty.
The results are the same if I attempt access as root.
I've given ownership of the repository /var/svn/
to USER:USER
and ranchmod 2700 -R /var/svn/
.
Because I can access the repository via ssh from another Linux box, permissions don't appear to be the problem.
When I watch the log file using tail -fn 2000 /var/log/secure
, I see the following each time TortiseSVN asks for the password:
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
I'm actually able to login, but the session is then closed immediately.
It caught my eye that the session is being opened for USER by root (uid=0)
, which may be correct, but I'll mention it in case it has something to do with the problem.
I looked into modifying the svnserve.conf
, but as far as I can tell, it's not used when accessing the repository via svn+ssh
, a private svnserve instance is created for each log in via this method. From the manual:
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.
The only non-default settings in sshd_config
are:
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
Any thoughts?
bash svn ssh tortoisesvn openssh
bash svn ssh tortoisesvn openssh
edited Jan 31 '13 at 6:04
codewaggle
asked Sep 26 '12 at 17:09
codewagglecodewaggle
4,32322243
4,32322243
Just a thought, try taking the USER@ out of the URL and wait for tortoise to prompt for credentials. Not sure if it will work, but it is worth a try.
– Scott
Sep 26 '12 at 17:11
Thanks for the suggestion, but same result.
– codewaggle
Sep 26 '12 at 17:19
When you open the tortoise repo-browser, what error does it give you?
– Scott
Sep 26 '12 at 17:22
I added the error message near the top of the question.
– codewaggle
Sep 26 '12 at 17:41
Can you ssh ok using the same credentials?
– lucidcircus
Sep 28 '12 at 11:16
|
show 1 more comment
Just a thought, try taking the USER@ out of the URL and wait for tortoise to prompt for credentials. Not sure if it will work, but it is worth a try.
– Scott
Sep 26 '12 at 17:11
Thanks for the suggestion, but same result.
– codewaggle
Sep 26 '12 at 17:19
When you open the tortoise repo-browser, what error does it give you?
– Scott
Sep 26 '12 at 17:22
I added the error message near the top of the question.
– codewaggle
Sep 26 '12 at 17:41
Can you ssh ok using the same credentials?
– lucidcircus
Sep 28 '12 at 11:16
Just a thought, try taking the USER@ out of the URL and wait for tortoise to prompt for credentials. Not sure if it will work, but it is worth a try.
– Scott
Sep 26 '12 at 17:11
Just a thought, try taking the USER@ out of the URL and wait for tortoise to prompt for credentials. Not sure if it will work, but it is worth a try.
– Scott
Sep 26 '12 at 17:11
Thanks for the suggestion, but same result.
– codewaggle
Sep 26 '12 at 17:19
Thanks for the suggestion, but same result.
– codewaggle
Sep 26 '12 at 17:19
When you open the tortoise repo-browser, what error does it give you?
– Scott
Sep 26 '12 at 17:22
When you open the tortoise repo-browser, what error does it give you?
– Scott
Sep 26 '12 at 17:22
I added the error message near the top of the question.
– codewaggle
Sep 26 '12 at 17:41
I added the error message near the top of the question.
– codewaggle
Sep 26 '12 at 17:41
Can you ssh ok using the same credentials?
– lucidcircus
Sep 28 '12 at 11:16
Can you ssh ok using the same credentials?
– lucidcircus
Sep 28 '12 at 11:16
|
show 1 more comment
5 Answers
5
active
oldest
votes
I finally came across a solution for this. In the TortoiseSVN FAQ of all places:
TortoiseSVN Frequently asked questions
From the FAQ:
SVN+SSH: Connection closed unexpectedly
It has been reported that svn+ssh connections of the form
svn+ssh://username@server.com 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.
I didn't try the first approach of editing my registry.
The second approach of editing the bash configuration worked for me.
A note about the bash configuration method:
If you're on shared hosting, your user .bashrc file will likely be loading the global /etc/bashrc file. You won't be able to edit the global file, so you'll need to work around that.
Some possible approaches:
Try adding
mesg n
to your user .bashrc file. I'm not sure if this
will work or whether it should be placed before or after the global
file is loaded.Don't include the global file and hard code all the settings in your
user.bashrc
file.Remove the
mesg y
setting from the global /etc/bashrc file as it's
loading. This question discusses how to do that: Use a grepped file
as an included source in bash
I'm trying to do the same exact thing and I'm receiving the identical error message that you posted above. I can, however, connect to my repo by using the gui and browing to it with svn+ssh://user@ip/repo but it will not allow me to do this through the command line. Have you had any luck doing this using the command line?
– hax0r_n_code
Apr 24 '13 at 19:32
@nkon It was a small project and I no longer have access to that server, so I can't test against it. I suggest that you open a question and include all the details about the commands that work and don't work along with log entries and your configuration for SVN, SSH and BASH (similar to what I included in my question and answer). That will give the best opportunity for someone to see what might be causing the problem. Add a comment here after you create the question and I'll take a look at it.
– codewaggle
Apr 24 '13 at 21:28
add a comment |
An old question, but still top of the stack on Google, so I thought I'd share my solution.
Simply, it was because I didn't have a "home" directory for my user on the server. Changing the SSH client to the plink.exe that comes with Putty (right-click on folder | TortoiseSVN | Settings | Network) allowed me to see the error as the windows appeared on screen.
add a comment |
In my case the cause was, that the svnuser hasn't a shell (it was /bin/false).
This isn't visible in the ssh log even with debug ssh -vvv.
When you have this type of problem your debug output will look like this
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 eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
When the shell is set to /bin/bash the log changes to
debug1: Sending env LANG = en_GB.UTF-8
debug1: Sending command: svnserve -t
Path: MyRepo
URL: svn+ssh://svnuser@myServer.com/MyRepo
add a comment |
I had the same issue, and I tried the regedit solution.
In my case the Default Host Name was not to blame, but the regedit showed me a space in the saved session name (%20).
Putty does not care about the session name when you open a connection from there, hence there was no error when connecting from Putty.
But the session name is important in your svn+ssh:// url!
In my case the Putty session name was " server", and when I did a svn checkout I used "svn+ssh://server/srv/svn/repo", hence the error.
add a comment |
Maybe this simple solution will work:
Go to your putty and check whether the saved session name matches with the name (svn saved session name in putty) that you are trying to take checkout with...
E.G.: in svn saved session, the name is saved as coreSvn
, and the checkout url is:
svn+ssh://svnuser@core/COCRETE/branches/R20181121-0.0.2-RELEASE
, this won't work. Change the @core
to @coreSvn
or @coresvn
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f12606950%2ftortisesvn-svnssh-error-unable-to-connect-to-a-repository-at-url-network-c%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
I finally came across a solution for this. In the TortoiseSVN FAQ of all places:
TortoiseSVN Frequently asked questions
From the FAQ:
SVN+SSH: Connection closed unexpectedly
It has been reported that svn+ssh connections of the form
svn+ssh://username@server.com 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.
I didn't try the first approach of editing my registry.
The second approach of editing the bash configuration worked for me.
A note about the bash configuration method:
If you're on shared hosting, your user .bashrc file will likely be loading the global /etc/bashrc file. You won't be able to edit the global file, so you'll need to work around that.
Some possible approaches:
Try adding
mesg n
to your user .bashrc file. I'm not sure if this
will work or whether it should be placed before or after the global
file is loaded.Don't include the global file and hard code all the settings in your
user.bashrc
file.Remove the
mesg y
setting from the global /etc/bashrc file as it's
loading. This question discusses how to do that: Use a grepped file
as an included source in bash
I'm trying to do the same exact thing and I'm receiving the identical error message that you posted above. I can, however, connect to my repo by using the gui and browing to it with svn+ssh://user@ip/repo but it will not allow me to do this through the command line. Have you had any luck doing this using the command line?
– hax0r_n_code
Apr 24 '13 at 19:32
@nkon It was a small project and I no longer have access to that server, so I can't test against it. I suggest that you open a question and include all the details about the commands that work and don't work along with log entries and your configuration for SVN, SSH and BASH (similar to what I included in my question and answer). That will give the best opportunity for someone to see what might be causing the problem. Add a comment here after you create the question and I'll take a look at it.
– codewaggle
Apr 24 '13 at 21:28
add a comment |
I finally came across a solution for this. In the TortoiseSVN FAQ of all places:
TortoiseSVN Frequently asked questions
From the FAQ:
SVN+SSH: Connection closed unexpectedly
It has been reported that svn+ssh connections of the form
svn+ssh://username@server.com 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.
I didn't try the first approach of editing my registry.
The second approach of editing the bash configuration worked for me.
A note about the bash configuration method:
If you're on shared hosting, your user .bashrc file will likely be loading the global /etc/bashrc file. You won't be able to edit the global file, so you'll need to work around that.
Some possible approaches:
Try adding
mesg n
to your user .bashrc file. I'm not sure if this
will work or whether it should be placed before or after the global
file is loaded.Don't include the global file and hard code all the settings in your
user.bashrc
file.Remove the
mesg y
setting from the global /etc/bashrc file as it's
loading. This question discusses how to do that: Use a grepped file
as an included source in bash
I'm trying to do the same exact thing and I'm receiving the identical error message that you posted above. I can, however, connect to my repo by using the gui and browing to it with svn+ssh://user@ip/repo but it will not allow me to do this through the command line. Have you had any luck doing this using the command line?
– hax0r_n_code
Apr 24 '13 at 19:32
@nkon It was a small project and I no longer have access to that server, so I can't test against it. I suggest that you open a question and include all the details about the commands that work and don't work along with log entries and your configuration for SVN, SSH and BASH (similar to what I included in my question and answer). That will give the best opportunity for someone to see what might be causing the problem. Add a comment here after you create the question and I'll take a look at it.
– codewaggle
Apr 24 '13 at 21:28
add a comment |
I finally came across a solution for this. In the TortoiseSVN FAQ of all places:
TortoiseSVN Frequently asked questions
From the FAQ:
SVN+SSH: Connection closed unexpectedly
It has been reported that svn+ssh connections of the form
svn+ssh://username@server.com 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.
I didn't try the first approach of editing my registry.
The second approach of editing the bash configuration worked for me.
A note about the bash configuration method:
If you're on shared hosting, your user .bashrc file will likely be loading the global /etc/bashrc file. You won't be able to edit the global file, so you'll need to work around that.
Some possible approaches:
Try adding
mesg n
to your user .bashrc file. I'm not sure if this
will work or whether it should be placed before or after the global
file is loaded.Don't include the global file and hard code all the settings in your
user.bashrc
file.Remove the
mesg y
setting from the global /etc/bashrc file as it's
loading. This question discusses how to do that: Use a grepped file
as an included source in bash
I finally came across a solution for this. In the TortoiseSVN FAQ of all places:
TortoiseSVN Frequently asked questions
From the FAQ:
SVN+SSH: Connection closed unexpectedly
It has been reported that svn+ssh connections of the form
svn+ssh://username@server.com 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.
I didn't try the first approach of editing my registry.
The second approach of editing the bash configuration worked for me.
A note about the bash configuration method:
If you're on shared hosting, your user .bashrc file will likely be loading the global /etc/bashrc file. You won't be able to edit the global file, so you'll need to work around that.
Some possible approaches:
Try adding
mesg n
to your user .bashrc file. I'm not sure if this
will work or whether it should be placed before or after the global
file is loaded.Don't include the global file and hard code all the settings in your
user.bashrc
file.Remove the
mesg y
setting from the global /etc/bashrc file as it's
loading. This question discusses how to do that: Use a grepped file
as an included source in bash
edited May 23 '17 at 11:52
Community♦
11
11
answered Jan 31 '13 at 5:37
codewagglecodewaggle
4,32322243
4,32322243
I'm trying to do the same exact thing and I'm receiving the identical error message that you posted above. I can, however, connect to my repo by using the gui and browing to it with svn+ssh://user@ip/repo but it will not allow me to do this through the command line. Have you had any luck doing this using the command line?
– hax0r_n_code
Apr 24 '13 at 19:32
@nkon It was a small project and I no longer have access to that server, so I can't test against it. I suggest that you open a question and include all the details about the commands that work and don't work along with log entries and your configuration for SVN, SSH and BASH (similar to what I included in my question and answer). That will give the best opportunity for someone to see what might be causing the problem. Add a comment here after you create the question and I'll take a look at it.
– codewaggle
Apr 24 '13 at 21:28
add a comment |
I'm trying to do the same exact thing and I'm receiving the identical error message that you posted above. I can, however, connect to my repo by using the gui and browing to it with svn+ssh://user@ip/repo but it will not allow me to do this through the command line. Have you had any luck doing this using the command line?
– hax0r_n_code
Apr 24 '13 at 19:32
@nkon It was a small project and I no longer have access to that server, so I can't test against it. I suggest that you open a question and include all the details about the commands that work and don't work along with log entries and your configuration for SVN, SSH and BASH (similar to what I included in my question and answer). That will give the best opportunity for someone to see what might be causing the problem. Add a comment here after you create the question and I'll take a look at it.
– codewaggle
Apr 24 '13 at 21:28
I'm trying to do the same exact thing and I'm receiving the identical error message that you posted above. I can, however, connect to my repo by using the gui and browing to it with svn+ssh://user@ip/repo but it will not allow me to do this through the command line. Have you had any luck doing this using the command line?
– hax0r_n_code
Apr 24 '13 at 19:32
I'm trying to do the same exact thing and I'm receiving the identical error message that you posted above. I can, however, connect to my repo by using the gui and browing to it with svn+ssh://user@ip/repo but it will not allow me to do this through the command line. Have you had any luck doing this using the command line?
– hax0r_n_code
Apr 24 '13 at 19:32
@nkon It was a small project and I no longer have access to that server, so I can't test against it. I suggest that you open a question and include all the details about the commands that work and don't work along with log entries and your configuration for SVN, SSH and BASH (similar to what I included in my question and answer). That will give the best opportunity for someone to see what might be causing the problem. Add a comment here after you create the question and I'll take a look at it.
– codewaggle
Apr 24 '13 at 21:28
@nkon It was a small project and I no longer have access to that server, so I can't test against it. I suggest that you open a question and include all the details about the commands that work and don't work along with log entries and your configuration for SVN, SSH and BASH (similar to what I included in my question and answer). That will give the best opportunity for someone to see what might be causing the problem. Add a comment here after you create the question and I'll take a look at it.
– codewaggle
Apr 24 '13 at 21:28
add a comment |
An old question, but still top of the stack on Google, so I thought I'd share my solution.
Simply, it was because I didn't have a "home" directory for my user on the server. Changing the SSH client to the plink.exe that comes with Putty (right-click on folder | TortoiseSVN | Settings | Network) allowed me to see the error as the windows appeared on screen.
add a comment |
An old question, but still top of the stack on Google, so I thought I'd share my solution.
Simply, it was because I didn't have a "home" directory for my user on the server. Changing the SSH client to the plink.exe that comes with Putty (right-click on folder | TortoiseSVN | Settings | Network) allowed me to see the error as the windows appeared on screen.
add a comment |
An old question, but still top of the stack on Google, so I thought I'd share my solution.
Simply, it was because I didn't have a "home" directory for my user on the server. Changing the SSH client to the plink.exe that comes with Putty (right-click on folder | TortoiseSVN | Settings | Network) allowed me to see the error as the windows appeared on screen.
An old question, but still top of the stack on Google, so I thought I'd share my solution.
Simply, it was because I didn't have a "home" directory for my user on the server. Changing the SSH client to the plink.exe that comes with Putty (right-click on folder | TortoiseSVN | Settings | Network) allowed me to see the error as the windows appeared on screen.
answered Mar 12 '15 at 11:34
Grim...Grim...
11.9k63557
11.9k63557
add a comment |
add a comment |
In my case the cause was, that the svnuser hasn't a shell (it was /bin/false).
This isn't visible in the ssh log even with debug ssh -vvv.
When you have this type of problem your debug output will look like this
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 eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
When the shell is set to /bin/bash the log changes to
debug1: Sending env LANG = en_GB.UTF-8
debug1: Sending command: svnserve -t
Path: MyRepo
URL: svn+ssh://svnuser@myServer.com/MyRepo
add a comment |
In my case the cause was, that the svnuser hasn't a shell (it was /bin/false).
This isn't visible in the ssh log even with debug ssh -vvv.
When you have this type of problem your debug output will look like this
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 eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
When the shell is set to /bin/bash the log changes to
debug1: Sending env LANG = en_GB.UTF-8
debug1: Sending command: svnserve -t
Path: MyRepo
URL: svn+ssh://svnuser@myServer.com/MyRepo
add a comment |
In my case the cause was, that the svnuser hasn't a shell (it was /bin/false).
This isn't visible in the ssh log even with debug ssh -vvv.
When you have this type of problem your debug output will look like this
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 eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
When the shell is set to /bin/bash the log changes to
debug1: Sending env LANG = en_GB.UTF-8
debug1: Sending command: svnserve -t
Path: MyRepo
URL: svn+ssh://svnuser@myServer.com/MyRepo
In my case the cause was, that the svnuser hasn't a shell (it was /bin/false).
This isn't visible in the ssh log even with debug ssh -vvv.
When you have this type of problem your debug output will look like this
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 eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
When the shell is set to /bin/bash the log changes to
debug1: Sending env LANG = en_GB.UTF-8
debug1: Sending command: svnserve -t
Path: MyRepo
URL: svn+ssh://svnuser@myServer.com/MyRepo
answered Nov 30 '16 at 11:07
jebjeb
58.7k13134172
58.7k13134172
add a comment |
add a comment |
I had the same issue, and I tried the regedit solution.
In my case the Default Host Name was not to blame, but the regedit showed me a space in the saved session name (%20).
Putty does not care about the session name when you open a connection from there, hence there was no error when connecting from Putty.
But the session name is important in your svn+ssh:// url!
In my case the Putty session name was " server", and when I did a svn checkout I used "svn+ssh://server/srv/svn/repo", hence the error.
add a comment |
I had the same issue, and I tried the regedit solution.
In my case the Default Host Name was not to blame, but the regedit showed me a space in the saved session name (%20).
Putty does not care about the session name when you open a connection from there, hence there was no error when connecting from Putty.
But the session name is important in your svn+ssh:// url!
In my case the Putty session name was " server", and when I did a svn checkout I used "svn+ssh://server/srv/svn/repo", hence the error.
add a comment |
I had the same issue, and I tried the regedit solution.
In my case the Default Host Name was not to blame, but the regedit showed me a space in the saved session name (%20).
Putty does not care about the session name when you open a connection from there, hence there was no error when connecting from Putty.
But the session name is important in your svn+ssh:// url!
In my case the Putty session name was " server", and when I did a svn checkout I used "svn+ssh://server/srv/svn/repo", hence the error.
I had the same issue, and I tried the regedit solution.
In my case the Default Host Name was not to blame, but the regedit showed me a space in the saved session name (%20).
Putty does not care about the session name when you open a connection from there, hence there was no error when connecting from Putty.
But the session name is important in your svn+ssh:// url!
In my case the Putty session name was " server", and when I did a svn checkout I used "svn+ssh://server/srv/svn/repo", hence the error.
edited Jul 11 '18 at 8:18
answered Jul 11 '18 at 7:20
user1987625user1987625
164
164
add a comment |
add a comment |
Maybe this simple solution will work:
Go to your putty and check whether the saved session name matches with the name (svn saved session name in putty) that you are trying to take checkout with...
E.G.: in svn saved session, the name is saved as coreSvn
, and the checkout url is:
svn+ssh://svnuser@core/COCRETE/branches/R20181121-0.0.2-RELEASE
, this won't work. Change the @core
to @coreSvn
or @coresvn
add a comment |
Maybe this simple solution will work:
Go to your putty and check whether the saved session name matches with the name (svn saved session name in putty) that you are trying to take checkout with...
E.G.: in svn saved session, the name is saved as coreSvn
, and the checkout url is:
svn+ssh://svnuser@core/COCRETE/branches/R20181121-0.0.2-RELEASE
, this won't work. Change the @core
to @coreSvn
or @coresvn
add a comment |
Maybe this simple solution will work:
Go to your putty and check whether the saved session name matches with the name (svn saved session name in putty) that you are trying to take checkout with...
E.G.: in svn saved session, the name is saved as coreSvn
, and the checkout url is:
svn+ssh://svnuser@core/COCRETE/branches/R20181121-0.0.2-RELEASE
, this won't work. Change the @core
to @coreSvn
or @coresvn
Maybe this simple solution will work:
Go to your putty and check whether the saved session name matches with the name (svn saved session name in putty) that you are trying to take checkout with...
E.G.: in svn saved session, the name is saved as coreSvn
, and the checkout url is:
svn+ssh://svnuser@core/COCRETE/branches/R20181121-0.0.2-RELEASE
, this won't work. Change the @core
to @coreSvn
or @coresvn
edited Nov 21 '18 at 17:04
Federico Grandi
3,28531230
3,28531230
answered Nov 21 '18 at 9:26
user10684854user10684854
1
1
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f12606950%2ftortisesvn-svnssh-error-unable-to-connect-to-a-repository-at-url-network-c%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Just a thought, try taking the USER@ out of the URL and wait for tortoise to prompt for credentials. Not sure if it will work, but it is worth a try.
– Scott
Sep 26 '12 at 17:11
Thanks for the suggestion, but same result.
– codewaggle
Sep 26 '12 at 17:19
When you open the tortoise repo-browser, what error does it give you?
– Scott
Sep 26 '12 at 17:22
I added the error message near the top of the question.
– codewaggle
Sep 26 '12 at 17:41
Can you ssh ok using the same credentials?
– lucidcircus
Sep 28 '12 at 11:16