I'm having trouble checking out a project via svn. I have a repository set up at svn://consideropen.com/home/consider/rvsubversion/project/trunk.
I have no problem checking out the project in NetBeans, but, when I ssh to another server (not the same server as the repository) and run
svn checkout svn://example.com/home/consider/rvsubversion/project/trunk
I get a connection refused error.
Why is this happening?
Possibly your server is behind a firewall that only permits certain ports through such as 22, 80, and 8080 for example. It might not permit the standard svn protocol port 3690 to pass through.
Try telnet consideropen.com 3690 and see if you get:
( success ( 1 2 ( ANONYMOUS ) ( edit-pipeline svndiff1 absent-entries ) )
If you don't then you are blocked. Your other option would be to set up the repository using subversion with WebDAV. Then your server would be able to access it over port 80 which is usually open.
I recommend to master nmap - very powerful port scanning tool
In your case it will be:
$ nmap -sT -r -n -vv -p80,8080 example.com
where -sT mean direct TCP connection, -sS - SYNC or silience
-vv - very verbose
-r - don't randomize ports
-n - don't make DNS resolve
-p{xxx} - ports to scan, different masks are supported, e.g. 80,8081-8088,8090
optional -P0 means don't ping a target host
Related
Using Docker 1.12.1, I face a strange behaviour trying to access a host port created with ssh -R.
Basically I try to access a service running on port 12345 on my local machine from a docker container running on a server.
I opened a ssh connection with ssh -R *:12345:localhost:12345 user#server to open a port 12345 on server that forwards to port 12345 on my local machine.
Now when I try curl https://172.17.42.1:12345 inside the container (172.17.42.1 is the IP to access the docker host from the docker container) I get :
root#f6873fe1109b:/# curl https://172.17.42.1:12345
curl: (7) Failed to connect to 172.17.42.1 port 12345: Connection refused
But on server the command curl http://localhost:12345 succeeds (eg. no Connection refused)
server$ curl http://localhost:12345
curl: (52) Empty reply from server
I don't really understand how the port binding done with ssh differs from a test with nc on server (it works) :
# on server
nc -l -p 12345
# inside a container
root#f6873fe1109b:/# curl http://172.17.42.1:12345
curl: (52) Empty reply from server
NB: the container was started with docker run -it --rm maven:3-jdk-8 bash.
What can I do to allow my container to access the host port corresponding to a ssh binding ?
From man ssh:
-R [...]
... Specifying a remote bind_address will only succeed if the server's GatewayPorts option is enabled
And man sshd_config:
GatewayPorts
Specifies whether remote hosts are allowed to connect to ports forwarded for the client. By default, sshd(8) binds remote port forwardings to the loopback address. This prevents other remote hosts from connecting to forwarded ports. GatewayPorts can be used to specify that sshd should allow remote port forwardings to bind to non-loopback addresses, thus allowing other hosts to connect. The argument may be “no” to force remote port forwardings to be available to the local host only, “yes” to force remote port forwardings to bind to the wildcard address, or “clientspecified” to allow the client to select the address to which the forwarding is bound. The default is “no”.
This means that a default sshd server installation only allows to create forwards that bind to the local interface. If you want to allow forwards to other interfaces then loopback, you need to set the GatewayPorts option to yes or clientspecified in your /etc/ssh/sshd_config
I'd like to copy my config.yml file from my local django app directory to my heroku server, but I'm not sure how to get the user#host.com format for heroku.
I've tried running 'heroku run bash'
scp /home/user/app/config.yml
I'm not sure how I can get it in the
scp user#myhost.com:/home/user/dir1/file.txt user#myhost.com:/home/user/dir2'
format
As #tamas7 said it's firewalled, but your local machine is probably also firewalled. So unless you have a private server with SSH accessible from the Internet, you won't be able to scp.
I'm personally using transfer.sh free and open source service.
Upload your config.yml to it:
$ curl --upload-file ./config.yml https://transfer.sh/
https://transfer.sh/66nb8/config.yml
Then download it back from wherever you want:
$ wget https://transfer.sh/66nb8/config.yml
According to http://www.evans.io/posts/heroku-survival-guide/ incoming connections are firewalled off. In this case you need to approach your local machine from the Heroku server.
heroku run bash
scp user#mylocalmachine:/home/user/dir/file.txt .
This is a bit late to answer this question, but I use services like localtunnel - https://localtunnel.github.io/www/ to copy files from local machine to heroku.
First, run a python HTTP server in the directory where the file is located.
cd /path/to/file
python3 -m http.server
This starts a server in port 8000. Configure localtunnel to connect to that port.
lt -s mylocal -p 8000
Now from your heroku machine, you can fetch the file via curl.
curl -XGET http://mylocal.localtunnel.me/myfile.txt > myfile.txt
You could also use a service like https://ngrok.com/ to open up a TCP tunnel into your local machine.
You will need to enable Remote Login as in simlmx answer.
On your local machine open the TCP tunnel just like this:
$ ngrok tcp 22
And then, on the Heroku console, just use SCP with the PORT and HOST that Ngrok provided.
$ scp -P [PORT] username#[HOST]:~/path/to/file.ext .
If you need to download your entire repo, for example to recover an app that you no longer have locally, use heroku git:clone -a myapp. Docs.
Expanding on tamas7's answer:
You can connect to your computer from the heroku server.
If your computer is behind a router, you'll also need to forward the connection to your computer.
1. You computer must accept ssh connections
On my mac it was as simple as enabling it in the Preferences / Sharing panel.
2. Your router needs to forward the connection to your computer.
Go to your router's settings page in your browser (typically 192.168.0.1 but varies depending on the router). Find the port forwarding section and forward some port to your computer on port 22.
This is how it looked on my tp-link:
Here I am making sure that port 22000 is forwarded to my computer (192.168.0.110) on port 22.
3. Find your external IP
Simply google "what is my IP".
4. Scp your file from heroku
heroku run bash
scp -P 22000 your_user#your_external_IP:/path/to/your/file .
5. Undo everything!
Once you're done it's probably good practice to disable the port forwarding and remote login.
I am using agent forwarding, it works fine. But the ssh client is sharing all registered (ssh-add) keys with the remote server. I have personal keys that I don't want to share with the remote server. Is there a way to restrict with keys are being forwarded?
I have multiple github accounts and aws accounts. I don't want to share all the ssh-keys.
Looks like it is possible with OpenSSH 6.7 - it supports unix socket forwarding. We could start secondary ssh-agent with specific keys and forward it's socket to remote host. Unfortunately this version is not available for my server/client systems at the time of writing.
I have found another possible solution, using socat and standard SSH TCP forwarding.
Idea
On local host we run secondary ssh-agent with only keys we want to see on remote host.
On local host we set up forwarding of TCP connections on some port (portXXX) to secondary ssh-agent's socket.
On remote host we set up forwarding from some socket to some TCP port (portYYY).
Then we establish ssh connection with port forwarding from remote's portYYY to local portXXX.
Requests to ssh agent go like this:
local ssh-agent (secondary)
^
|
v
/tmp/ssh-.../agent.ZZZZZ - agent's socket
^
| (socat local)
v
localhost:portXXX
^
| (ssh port forwarding)
v
remote's localhost:portYYY
^
| (socat remote)
v
$HOME/tmp/agent.socket
^
| (requests for auth via agent)
v
SSH_AUTH_SOCK=$HOME/tmp/agent.socket
^
| (uses SSH_AUTH_SOCK variable to find agent socket)
v
ssh
Drawbacks
It is not completely secure, because ssh-agent becomes partially available through TCP: users of remote host can connect to your local agent on 127.0.0.1:portYYY, and other users of your local host can connect on 127.0.0.1:portXXX. But they will see only limited set of keys you manually added to this agent. And, as AllenLuce mentioned, they can't grab it, they only could use it for authentication while agent is running.
socat must be installed on remote host. But looks like it is possible to simply upload precompiled binary (I tested it on FreeBSD and it works).
No automation: keys must be added manually via ssh-add, forwarding requires 2 extra processes (socat) to be run, multiple ssh connections must be managed manually.
So, this answer is probably just a proof of concept and not a production solution.
Let's see how it can be done.
Instruction
Client side (where ssh-agent is running)
Run new ssh-agent. It will be used for keys you want to see on remote host only.
$ ssh-agent # below is ssh-agent output, DO NOT ACTUALLY RUN THESE COMMANDS BELOW
SSH_AUTH_SOCK=/tmp/ssh-qVnT0UsgV6yO/agent.22982; export SSH_AUTH_SOCK;
SSH_AGENT_PID=22983; export SSH_AGENT_PID;
It prints some variables. Do not set them: you will loose your main ssh agent. Set another variable with suggested value of SSH_AUTH_SOCK:
SSH_AUTH_SECONDARY_SOCK=/tmp/ssh-qVnT0UsgV6yO/agent.22982
Then establish forwarding from some TCP port to our ssh-agent socket locally:
PORT=9898
socat TCP4-LISTEN:$PORT,bind=127.0.0.1,fork UNIX-CONNECT:$SSH_AUTH_SECONDARY_SOCK &
socat will run in background. Do not forget to kill it when you're done.
Add some keys using ssh-add, but run it with modified enviromnent variable SSH_AUTH_SOCK:
SSH_AUTH_SOCK=$SSH_AUTH_SECONDARY_SOCK ssh-add
Server side (remote host)
Connect to remote host with port forwarding. Your main (not secondary) ssh agent will be used for auth on hostA (but will not be available from it, as we do not forward it).
home-host$ PORT=9898 # same port as above
home-host$ ssh -R $PORT:localhost:$PORT userA#hostA
On remote host establish forwarding from ssh-agent socket to same TCP port as on your home host:
remote-host$ PORT=9898 # same port as on home host
remote-host$ mkdir -p $HOME/tmp
remote-host$ SOCKET=$HOME/tmp/ssh-agent.socket
remote-host$ socat UNIX-LISTEN:$SOCKET,fork TCP4:localhost:$PORT &
socat will run in background. Do not forget to kill it when you're done. It does not automatically exit when you close ssh connection.
Connection
On remote host set enviromnent variable for ssh to know where agent socket (from previous step) is. It can be done in same ssh session or in parallel one.
remote-host$ export SSH_AUTH_SOCK=$HOME/tmp/ssh-agent.socket
Now it is possible to use secondary agent's keys on remote host:
remote-host$ ssh userB#hostB # uses secondary ssh agent
Welcome to hostB!
The keys themselves are not shared by forwarding your agent. What's forwarded is the ability to contact the ssh-agent on your local host. Remote systems send challenge requests through the forwarding tunnel. They do not request the keys themselves.
See http://www.unixwiz.net/techtips/ssh-agent-forwarding.html#fwd for a graphical explanation.
When i run the jboss-cli.sh,
I get this message.
[root bin]# sh jboss-cli.sh
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /] connect localhost
The controller is not available at localhost:9999
[disconnected /] connect
The controller is not available at localhost:9999
[disconnected /] connect localhost:9999
The controller is not available at localhost:9999
[disconnected /]
Also i have another installation of jboss5 GA. I hope that is not interfering.
Although that is totally shut down for now.
Native management interface is :9999 in standalone.sh
Please throw light on this issue.
#
EDITED
#
When i stop my service with "service jboss stop"
i get this message
[root# bin]# *** JBossAS process (7302) received KILL signal ***
grep: /var/run/jboss-as/jboss-as-standalone.pid: No such file or directory
I Dont know how to check whether server is listening on the port 9999 or not.
Few more details
[root bin]# netstat -anp |grep 9999
tcp 0 0 127.0.0.1:9999 0.0.0.0:* LISTEN 7931/java
[root bin]# netstat -anp |grep 8080
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 7931/java
JBoss processs id and the server id acquiring these ports is same.
This question has two issues ,
First, i have provided debuging parameter in the startup script.
If you see 8787 that means you have somewhere provided debuging argument.
Second and the most important one controller not available #localhost or #IPADDRESS .
Please check if you have used port offset, as it increments all the ports by the number with with you have set port offset.
Suppose port offset is 2
Then try to access connect localhost:10001 Port i.e 9999+2
On my production server sometimes it does not works with localhost , but works with IP address.
Then try to access connect IPADDRESS:9999
OR
Then try to access connect 127.0.0.1:9999
Please check in the firewall weather the port 9999 or what ever with port offset, if the port is not open in the firewall it gives error,
I asked this question 6 months back and the above checks has solved
the problem always.
This is probaby because you have changed your binding configuration and jboss does not bind to 127.0.0.1.
In case your jboss instance is not binding to 127.0.0.1, you may use --controller option as follows:
./jboss-cli.sh --controller=YOUR_IP:9999
Use netstat -anp |grep 9999 to find out if port 9999 is in use and by which process id. You could also check the host.xml used by the controller to configure the proper native port.
In the host xml, you should find the default port:
<native-interface security-realm="ManagementRealm">
<socket interface="management" port="${jboss.management.native.port:9999}"/>
./jboss-cli.sh --controller=localhost:9999 --connect
You open the debug-port with jboss-cli.sh. Either you activated in jboss-cli.sh:
# Sample JPDA settings for remote socket debugging
# JAVA_OPTS="$JAVA_OPTS -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n"
or you set JAVA_OPTS with such an option in you environment. See
echo $JAVA_OPTS
I guess you did this for two jboss-processes, and you get a port-conflict. See
netstat -nap | grep 8787
I recently faced this issue and the root cause that I found was completely different than it is listed above. It is because for some other project I shifted to JDK 1.8 from 1.7. Boom! and error started coming up...I took hell lot of time figuring out why it is coming up before finally realizing I changed my JDK version.
It might be because JBOSS 7 doesn't work with 1.8 of which I have limited knowledge but yes this might prove useful for some cases.
In open source project,project open, I'm trying to run the server on port 80 for http and 443 for https which gave an error
[-nssock:driver-] Error: nssock: failed to listen on 0.0.0.0:80: Permission denied
and also is there anything else required to enable https port(like certification,etc)
Are there any other applications which already used the port 80? run below command to find out what applicaiton use the resource
netstat -an |grep "\.80 "
lsof -i:80
Probably you are trying to run AolServer as non-root user, but AolServer is configured to use "privileged" ports 80 and 443 (ports below 1024 are "privileged").
You may either configure your system to allow non-root process to bind to "privileged" ports, or just run AolServer as root. For the first approach also check discussion of the capabilities system.