How to use the webUI for Heritrix remotely - linux

Hello I have been playing with Heritrix, and would like to include it on a website/allow remote web access to it.
I have a Linux based server where I have a hosted webpage, and I have built a version of Heritrix.
The issue is I am at home now and would like to be able to offer access to the webUI in Heritrix via the hosted webpage.
I looked through the manual and discovered the -b command to bind it to remote hosts however the documentation could be better.
So what I was hoping for was a little explanation/elaboration on how this command works and if it would be possible to bind the webUI to existing webpage
Thanks for your time in advance
(Here is a link to the documentation im working from: https://webarchive.jira.com/wiki/display/Heritrix/HOWTO+Launch+Heritrix )

You should use -b <public ip address> like -b 192.168.1.1

If you don't want to use a public IP, you can use SSH port forwarding to do this. When creating a PuTTY session, under Connection > SSH > Tunnels enter the following:
Source port: 8443 (or the port Heritrix is installed on, if different)
Destination: localhost:8443 (it's good practice to match the port you're forwarding)
Back on the Session window, make sure you save the session. Now whenever you SSH onto your server you can access the Heritrix web UI by hitting https://localhost:8443

Related

node inspect on google cloud console setup firewall

I am trying to setup the firewall for accessing node inspect using my local chrome browser.
Does anybody have a good short guide and which tcp protocol do I need to enable.
I have a firewall rule active where the compute instance enables tcp:80. It worked in the past of a http server. How do I know which port to use for node inspect and how to enable it.
If found it myself. I have to use an ssh tunnel. https://nodejs.org/en/docs/guides/debugging-getting-started/#enabling-remote-debugging-scenarios
Enabling remote debugging scenarios
We recommend that you never have the debugger listen on a public IP address. If you need to allow remote debugging connections we
recommend the use of ssh tunnels instead. We provide the following
example for illustrative purposes only. Please understand the security
risk of allowing remote access to a privileged service before
proceeding.
Let's say you are running Node on remote machine, remote.example.com, that you want to be able to debug. On that
machine, you should start the node process with the inspector
listening only to localhost (the default).
$ node --inspect server.js
Now, on your local machine from where you want to initiate a debug client connection, you can setup an ssh tunnel:
$ ssh -L 9221:localhost:9229 user#remote.example.com
This starts a ssh tunnel session where a connection to port 9221 on your local machine will be forwarded to port 9229 on
remote.example.com. You can now attach a debugger such as Chrome
DevTools or Visual Studio Code to localhost:9221, which should be able
to debug as if the Node.js application was running locally.

Jenkins SSH-authenticated node on non-standard port

Is it possible to configure a Jenkins ssh node (slave) to authenticate on a port which is different than 22?
After choosing “Launch method” to be “Launch slave agents via SSH”, it is possible to enter the host on which we want to configure node. However there is no “port” field anywhere around, and syntax “ip:port” doesn’t want to work either.
After setting host field to ip:port, Jenkins tries to connect to ip:port:22
Opening SSH connection to IP:PORT:22.
IP:PORT: invalid IPv6 address
Any tips? Or is it necessary to just stick to using the standard ssh port?
The reason for wanting to use different ssh port is using Docker container on a remote machine.
Jenkins - 2.89 with SSH slaves plugin
If i understood your question correctly, you ignored advanced button on the new node config form via SSH slave plugin.
Adding node -
Click on Advanced & you should be able to define a port via GUI -

Accessing a server as localhost?

I use ssh keys to access a server at lets say 200.200.200.200. It works fine. How can i access that server in my host as 127.0.0.1?
I have tried my best but couldn't make it work.
You normally do this via port forwarding so you forward the remote port (the one from the server) that you are interested in to your local machine. Then you can access it via 127.0.0.1:
Example tutorial:
https://help.ubuntu.com/community/SSH/OpenSSH/PortForwarding
In putty it is also straight forward:
http://www.cs.uu.nl/technical/services/ssh/putty/puttyfw.html
You could also modify your local hosts file to point to this server but that often causes hick ups with local services.

linux command to connect to another server using hostname and port number

what is the Linux command to connect to another server using host name and port number?
how to connect to another server using only host name and port number then check if an existing process is running? the only way i see it working is to log in to the server and run the PS command. but is there a way to do it without logging in directly to the other server and connect only with host name and port number and check the running process?
If you just want to try an arbitrary connection to a given host/port combination, you could try one nmap, telnet or nc (netcat).
Note that you can't necessarily determine whether or not a process is running remotely - it might be running on that port, but simply ignore anything it sees over the port. To really be sure, you will need to run ps or netstat or etc. via ssh or etc.
If you want to use SSH from e.g. a script or, more generally, without typing in login information, then you will want to use public key authentication. Ubuntu has some good documentation on how to set this up, and it's very much applicable to other distrobutions as well: https://help.ubuntu.com/community/SSH/OpenSSH/Keys.
If you have no access to the server you're trying to list processes on at all, then I'm afraid there isn't a way to list running processes remotely (besides remote tools like nmap and so on, as mentioned earlier - you can always probe public ports without authentication [although you might make people angry if you do this to servers you don't own]). This is a feature, not a problem.
telnet connects to most of services. With it you can ensure that port is open and see hello message (if any). Also nc is more low level.
eri#eri-macro ~ $ telnet smtp.yandex.ru 25
Trying 87.250.250.38...
Connected to smtp.yandex.ru.
Escape character is '^]'.
220 smtp16.mail.yandex.net ESMTP (Want to use Yandex.Mail for your domain? Visit http://pdd.yandex.ru)
helo
501 5.5.4 HELO requires domain address.
HELO ya.ru
250 smtp16.mail.yandex.net
MAIL FROM: <someusername#somecompany.ru>
502 5.5.2 Syntax error, command unrecognized.
If there is plain text protocol you cat talk with service by keyboard. If connection is secured try openssl.
openssl s_client -quiet -connect www.google.com:443
depth=1 /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
verify error:num=20:unable to get local issuer certificate
verify return:0
GET /
<HTML><HEAD>
If protocol is not known you may see much of hieroglyphs or just Connected to ... message.
Try this :
ssh <YOUR_HOST_NAME> 'ps auxwww'
Like Dark Falcon said in the comments, you need a protocol to communicate with the server, a port alone is useless in this case.
By default on unix (and unix like) servers, ssh is the way to go.
Remote Shell with this command. Example is cat a file on the remote machine.
rsh host port 'cat remotefile' >> localfile
host and port self explainitory
remotefile: name of some file on the machine remote logging to in home directory
localfile: name of file cat information to.
Use monitoring software (like Nagios). It looks at your processes, sensors, load and thatever you configured to watch. It continuously stores log. It alerts you by email\sms\jabber if something fails. You can access it with browser or by HTTP API.

Noob questions for SVN checkout and network issues regading it

We have a local server with SVN installed on it that we are using for development/testing purpouses. We would like to checkout the data from it to the live server that is somewhere out there.
The only way to do that which I thought of was to use "svn checkout" from the live server, right? This way we do not need to FTP the changes to it, that may cause problems is we forget to upload some of the changes. And if we found a problem we can alway go back to previous stable version, right? Correct me if I am wrong about any of these.
The problem is that our local server (Ubuntu) does not have a IP that is reachable from outside. We have a router from out ISP, but we can not use that to access the local server from the live. We are willing to ask the ISP provider to setup a second IP for the local server, but for security sake they want to setup a separate machine with Windows and windows base security software (firewall - http://www.kerio.com/control/ and antivirus) that will cost us a lot. Can we just setup a free firewall on the local server (Ubuntu as I said) and solve the problem without spending additional money?
I hope I was clear.
It's always hard to comment without knowing the exact situation, but this sounds a bit crazy.
What you would usually do is set up port forwarding for one port to the local server. The server would then be reachable (for example) through 123.45.67.89:3690
That's a three-minute task to set up in a normal household router.
As long as the Ubuntu server is closed otherwise, and Subversion or whatever you are using for authentication is properly configured and up to date, this should not create security issues.
In any case, putting a Windows machine in between to act as a firewall sounds really unnecessary. Ubuntu comes with everything necessary to secure the setup properly.
If the remote server has an ssh server, then you can use ssh forwarding.
From the internal svn server:
ssh -R 7711:localhost:3690 {REMOTE_SERVER}
7711 is an arbitrary port (you can use any free port on the remote system) that will be forwarded from the remote system to port 3690 (svn) on the svn server.
3690 is the port on the internal svn server that you want to talk to (via svn://).
If you are using subversion over http:// then use port 80 instead of 3690.
If you are using subversion over https:// then use port 443 instead of 3690.
After setting up the forward, then you can do this on the remote system:
svn checkout {SCHEME}://localhost:7711/{PATH}
{SCHEME} is svn, http, https, etc.
{PATH} is the normal svn path you want to check out.
Notes:
the forwarded traffic is tunneled through the ssh connection (on a different "channel") so it is also encrypted which is a nice benefit.
by default, the remote end of the forward will listen on the loopback interface so only processes on that system will be able to use the port forwarded port.
As soon as you close the ssh session, the forwarded port will also close. It only lasts the duration of the ssh connection.
ssh forwarding is very powerful. If you can ssh between two systems, then you can get around any sort of connection problem like this.
Do man ssh and read about the -L and -R options.
Useful links about ssh forwarding:
http://www.rzg.mpg.de/networkservices/ssh-tunnelling-port-forwarding:
http://www.walkernews.net/2007/07/21/how-to-setup-ssh-port-forwarding-in-3-minutes/
check if your ISP router provide some port forwarding abilities,
You should probably forward the ssh port ( after ensuring that everyone password is secure/or enforcing login with ssh keys file), and use SVN+SSH protocol to access your repository.
You should be able to open up and forward a single port (3690 by default) on your existing IP to the local server, as pointed out by Pekka. This depends on your router, and your ability to access the configuration interface on the router.
Instead of having to deal with SSH and worry about people trying to access your local server from anywhere, you could setup a firewall to only allow incoming traffic from your single remote server. Depending on the router setup, you could simply use the builtin firewall on the local server. It would still be advisable to have some svn authentication, though.
The SSH forwarding method described by kanaka prevents the entire issue about remote access to the local machine, but it requires you to execute the forwarding command from the local server every time you need to access svn on the remote server.

Resources