Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have an apache svn server running on a shared hosting linux account.
The symptom is that i can connect to the server that is hosting svn with PuTTY just fine,
but the TortoiseSVN Repository Browser can't connect.
I have tried svn, svn+ssh,
If I try just svn I get:
E730060: Unable to connect to a repository at URL
'svn://50.97.138.99:36901 /test' svn: E730060: Can't connect to host
'50.97.138.99': A connection attempt failed because the connected
party did not properly respond after a period of time, or established
connection failed because connected host has failed to respond.
If I try svn+ssh,
I get repeatedly prompted for the password and end up having to cancel the pwd dialog several times, and the error is:
Unable to connect to a repository at URL 'svn+ssh://wren.arvixe.com'
To better debug connection problems, remove the -q option from ssh in
the [tunnels] section of your Subversion configuration file. Network
connection closed unexpectedly
I've been working on this two whole days now, googled my heart out, and am starting to get delirious.
Thanks for any help. Ill be happy to provide more details / do experiments / etc.
I didn't know what details anyone would want to get started, so sorry if not enough details initially.
There seems to be some confusion about how your repository is accessible. You can't simply browse via svn+ssh:// without someone setting it up. Did someone set this up?
I'm surprised you can log onto the server via SSH (using PuTTY) since it's a shared hosting server. That's usually not allowed. Most shared hosting sites don't allow shell access.
You mention apache svn server in your opening statement. Then, you try both svn:// and svn+ssh://. There are FOUR separate ways of setting up a Subversion server and accessing Subversion:
Use Apache httpd as the server. To do this, you need Apache httpd to be configured and compiled correctly. You need several Apache plugins such as mod_dav_svn.so and mod_dav.so. Do you have this setup? If you do, you need to access your repository with http:// and not svn:// as you show.
Use svnserve as the server. This is simple to setup. You access your repository with svn:// as you show. Did someone configure svnserve and have it running?
Use svnserve over ssh. This uses the svnserve, but integrates with ssh and can use the Unix file access. This is very, very tricky to setup, and I have seen extremely few instances of people actually using this. Each user, when they access the repository, fires off their own svnserve process. The repository has direct access to it, and you must set up the individual accounts to prevent any shell access. Otherwise users could directly manipulate the repository.
Use direct file access This is highly not recommended when sharing a repository since all users must be granted direct read/write access on the repository.
The problem is that it becomes impossible to help you without knowing how Subversion was setup on your system. Did you create the repository? If so, did you start a svnserve process to access it? Did someone else setup your Subversion repository on that system? If someone else setup the repository, you'll have to get the exact directions from them on how to access it.
If you are the one who setup the repository, did you setup Apache or did you setup svnserve? If you have setup svnserve, did you use the default port 3690, or setup another port to use? Can you determine if this port is blocked by your firewall? You can use the telenet command to try accessing the port directly:
C> telnet 50.97.138.99 3690
If you can't connect, you'll see an "Unable to connect to remote host" message, and that means either svnserve isn't running, or your firewall is blocking that port. Since you can log into the server, try logging into the server, and acesssing that repository directly:
$ svn log svn://localhost
If you can access the repo, you have svnserve running, but your firewall blocking it. If you can't access svnserve, you might not have it running.
Try that and see what you get.
Related
I downloaded the Fabric server jar file to a GitHub Codespace and am able to run the server without trouble. However, I am unable to determine the IP needed to connect to the server. Starting the server automatically forwards port 25565 and I make the port public. However, I can't figure out which IP to paste into Minecraft to connect to it. How do I figure out the IP of the server?
I found an answer thanks to inspiration from this question.
Steps:
Set up the fabric server jar as you normally would, but on the codespace. Start the server.
Split the terminal so one is running Java (server console) and the other is running bash.
Install ngrok via npm i ngrok --save-dev.
Once the server is finished setting up, run the command ./node_modules/.bin/ngrok tcp 25565.
Copy the ip shown under Forwarding (minus the tcp:// part and including the port). This should look something like 4.tcp.ngrok.io:17063.
You now have the ip of the serve!
Note: The free version of ngrok has URLs which change every time, as well as a limit, but for small-scale servers this shouldn't be an issue. You are also limited by the free codespace usage limit GitHub puts in place. However, you can easily get around this by creating a secondary account that you use codespaces on only for the server.
I recently deployed an AWS EC2 Ubuntu instance for a new intranet wiki. I installed java, tomcat, mySQL, and XWiki for this specifically.
I closed the SSH connection with PuTTY as I was setting up the XWiki and branding it appropriately but when I went to access it again, all I get is timeouts. SSH inbound rules are set to accept from all sources so I am almost certain it is not a network error, but I can't figure out what it is!
This has happened twice now, does anyone know of XWiki disallowing the ubuntu#ip.add.re.ss login with public key authentication?
XWiki certainly does not do anything like this nor it could even if it wanted to if you installed tomcat properly (it's usually not supposed to run as root).
This issue may be relevant for other Duplicati users:
Duplicati is configured to backup via SSH on a Debian webserver. After this webserver was updated, the backup failed with the error message "Algorithm negotiation fail".
SFTP via FileZilla is still possible, using the same credentials.
The problem is that "insecure" algorithms were disabled for SSH (in 2014/15): https://stackoverflow.com/a/26607212/336311
One possible solution may be to re-enable these algorithms (see link above). But if you cannot (or do not want to) mess around with the SSH configuration, there is a more simple solution:
Download psftp.exe form the PuTTY Download Page
In Duplicati select the "Duplicati Options" -> "SSH" and select the pdftp.exe as SFTP program.
Using the "Duplicati Assistant", edit your backup to use the external SFTP program.
It took me an hour to track this issue, so I created this "share your knowledge" question on Stack Overflow. Hope it helps someone.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Is there any way to execute a ssh connection with out use interactive password autentification and non public keys, I need too run a command in the remote server all this with out manual intervention, I know that i can use a script but I don´t have any example. The application will be running in different machines so it's a bit hard creating a key public for every machine.
Everything is possible with the right configurations, but there are some security points to consider.
You certainly don't want everyone on the net to be able to execute any command on your server. So simply allowing everything is not a good idea.
Everyone who has your application on a computer in her control can do everything what your application can do ... and maybe more, if the application has limits only build in itself, not the server side.
You can distribute a private key with your application (and pass to SSH on connection), but of course then anyone having the application can extract this key. (If the application can access it, so can do any attacker who has control over it.)
You could also distribute a password with your application and somehow pass it to ssh, but still, in principle anyone who has the application can get the password.
If there is always the same command to be executed (maybe with different inputs), you can force this specific command at the server-side - for example, for a specific public key in the authorized_keys file. Or you could create a SSH subsystem and only allow this by server configuration.
On the server side, you can put additional limits by IP address or host name, but this is not really secure (IP adresses can be faked, for example). If the computers on which the application is to be run have already existing SSH installations, they should have host keys, and maybe you can do host authentication. But this is still only really useful if these hosts are under your control, more or less.
For security issues, a password (if you don't use a certificate) will always asked to you interactively, unless you configure server in an advanced way.
You can use a certificate, by inserting password one time.
Take a look at this
On debian, a tool exists for this and it's called sshpass (a noninteractive ssh password provider)
It comes with lots of warnings and caveats though! Be sure you assess the risks properly before continuing down this path...
I have Solr running on my server on localhost in the Jetty container.
This seems like an obvious question, but how do I access the web interface from outside the server itself, like from an external IP address? Obviously, authentication will be important as part of any solution.
I am also running Apache2 on the server, if that is a good solution. I'm surprised I can't find anything about this.
I finally stumbled upon an answer to this. I don't really need persistent access to the Solr admin panel, so I can easily access it using local port forwarding in SSH.
All I had to do was run the following from a terminal on my local machine:
ssh -L 8983:localhost:8983 mlissner#IP-OF-SERVER-RUNNING-SOLR -N
And then open my browser to http://localhost:8983/solr/
Much easier than setting up an Apache config, doing proxies, and whatever else.
It depends on your Jetty ContextPath. For example:
....
WebAppContext explorerWebapp = new WebAppContext();
explorerWebapp.setContextPath("/solr");
....
and then just navigate to your index:
http://localhost:PORT/solr/