I am trying to connect to a windows machine in my local network from ubuntu with samba client. To send a message I type :
smbclient -M 192.168.1.10
But I get
Connection to 192.168.1.10 failed. Error NT_STATUS_IO_TIMEOUT
This is most likely because the box your trying to do smbclient uses an outdated (and insecure) version of SMB such as SMBv1.
You'll need to edit the smb.conf in your machine and specify the client min protocol into CORE. You'll also need to specify the client max protocol into SMB3.
More information here: https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html
Steps:
On your host machine:
sudo nano /etc/samba/smb.conf
Add the following settings under Global Settings:
client min protocol = CORE client max protocol = SMB3
Write (Ctrl + O) and Exit (Ctrl + X) nano text editor.
Retry smbclient
Related
When I analyze a file using Cuckoo
These error I have.
File "c:\python27\lib\site-packages\cuckoo\auxiliary\sniffer.py", line 157, in stop
(out, err, faq("permission-denied-for-tcpdump"))
CuckooOperationalError: Error running tcpdump to sniff the network traffic during the analysis; stdout = '' and stderr = 'tcpdump.exe: listening on VirtualBox Host-Only Ethernet Adapter\r\ntcpdump.exe: Error opening adapter: \xbd\xc3\xbd\xba\xc5\xdb\xc0\xcc \xc1\xf6\xc1\xa4\xb5\xc8 \xc0\xe5\xc4\xa1\xb8\xa6 \xc3\xa3\xc0\xbb \xbc\xf6 \xbe\xf8\xbd\xc0\xb4\xcf\xb4\xd9. (20)\r\n'. Did you enable the extra capabilities to allow running tcpdump as non-root user and disable AppArmor properly (the latter only applies to Ubuntu-based distributions with AppArmor, see also https://cuckoo.sh/docs/faq/index.html#permission-denied-for-tcpdump)?
My Virtualbox network(guest) name is VirtualBox Host-Only Ethernet Adapter
and my Windows10(host) is installed Windump(renamed as tcpdump.exe), Path is C:\tools\tcpdump.exe
also I set auxiliary.conf file.
# Specify the path to your local installation of tcpdump. Make sure this
# path is correct.
tcpdump = C:/tools/tcpdump.exe
My question is that why I'm getting an error like listening on VirtualBox Host-Only Ethernet Adapter\r\ntcpdump.exe: even though setting a tcpdump.exe path currectly.
I found the answer.
Confugured this line in sniffer.py.
From
err_whitelist_start = (
"tcpdump: listening on ",
"C:/tools/tcpdump.exe: listening on",
)
To
err_whitelist_start = (
"tcpdump: listening on ",
"C:\\tools\\tcpdump.exe: listening on",
)
And my virtualbox interface is wrong. So changed this
virtualbox.conf
From
interface = virtualBox Host-Only Ethernet Adapter
To
interface= \Device\NPF_{ED29CFE9-25EB-4AD9-B2EA-C09A93D465BF}
I am trying to connect to a MySQL server, which is restricted by being connected to a given server. I am trying to connect through this restricting server while not physically connected.
Through the command line this is doable by creating a SSH connection, after which I can run MySQL commands from the command line. For example:
ssh myUsername#Hostname
myUsername#Hostname's password:
[myUsername#Host ~]$ mysql -h mySQLHost -u mySQLUsername -p mySQLPassword
However, I wish to connect to the MySQL database from within R, so I can send queries to read in tables into my current R session. Usually I would run a R session inside of the commandline, but the server does not have R installed on it.
For example, I have this snippet of code that work when I am physically connected to the server (filled in information changed):
myDB <- dbConnect(MySQL(), user="mySQLUsername", password="mySQLPassword", dbname="myDbname", host="mySQLHost")
In essence, I want to run this same command through a pipe, so that the myDB object is a working mySQL connection.
I have been trying to pipe my way into the restricting server from within R, and have been able to read in a csv file. For example:
dat <- read.table(pipe('ssh myUsername#Hostname "cat /path/to/your/file"'))
This prompts me for my password, and the table is read (as is suggested it would here). However, I am unsure how to translate this to a MySQL connection. For example, should I make the pipe part of the host argument? That was my first thought, but have been unable to make that work.
Any help would be appreciated.
I accomplish a similar task with Postgres using SSH tunneling. Effectively, what you're doing with an SSH tunnel is saying "establish a connection to the remote server, and make a port from that server available as a port on my local machine."
You can set up a SSH tunnel using the following command on your local machine:
ssh -L local_port:lochalhost:remote_port username#remote_host
Specifically, what you're doing with this command is creating a Local Port Forwarding SSH tunnel, which is taking the port you'd connect to directly on the machine with your database installed (remote_port), and securely sending it to the machine you have R installed on as local_port.
For example, for a database server with the following options:
hostname: 192.168.1.3
username: mysql
server mysql port: 3306
You could use the following command (at the command line, or in R using system2) to create a tunnel to port 9000 on your machine:
ssh -L 9000:localhost:3306 mysql#192.168.1.3
Depending on what your exact DBI connection looks like in R, you may have to edit the connection configuration slightly to make it connect to your newly created tunneling port. The reason why I use a different localhost port is that it prevents conflicts with a local version of the database, if you've got one.
I am searching for a robust solution to perform extensive computations on a remote server, dedicated to computational tasks. The server is on Windows 2008 R2 and has R x64 3.4.1 installed on it. I've searched for free solutions and am now focusing on the Rserver/RSclient packages solutions.
However, I can't connect any client (using RSclient) to the instanced server.
This is how I'm proceeding at the moment from the server side:
library(Rserve)
run.Rserve(config.file = "Rserv.conf")
using the following Rserv.conf file:
port 6311
remote enable
plaintext enable
control enable
r-control enable
The server is now intanciated using the Rsession (It's a bit ugly, but will change that latter on):
running Rserve in this R session (pid=...), 1 server(s)
Now, i'm trying to connect using a remote computer (Client-side) using:
library(RSclient)
c = RS.connect(host = "...")
The connection then seems to succeed, checking for c:
> c
Rserve QAP1 connection 0x000000000fbe9f50 (socket 764, queue length 0)
The error occurs when i try to eval anything, for example:
> RS.server.eval(c,"0<1")
Error in RS.server.eval(c, "0<1") : command failed with status code 0x4e: no control line present (control commands disabled or server shutdown)
I've read the available guides but still failed in connecting. What is wrong? It seems to be related to control lines but I authorized them in the config file.
for me the problem was solved by initiating the Rserve instance with the command:
R CMD Rserve --RS-port 9000 --RS-enable-remote --RS-enable-control
instead of starting it in the R environment (library(Rserve), run.Rserve(config.file = "Rserv.conf")). You may try this on Windows as well.
Refer https://github.com/s-u/Rserve/wiki/rserve.conf.
port 6311
remote enable -> it should be remote true
plaintext enable
control enable
r-control enable
Likewise refer the link and try with actual values
I am new to using ldap and slapd and I am having some trouble getting my client machine to connect to the server that is hosting slapd.
here is the run down:
on a ubuntu box I have an instance of virtualbox running a vm with CentOS. I have installed and configured slapd on the CentOS vm and as long as I am on the vm I can use the ldapsearch, ldapadd, etc. once I move to the client machine (the ubuntu distro housing the vm) I run the following:
ldapsearch -x -LLL -b 'dc=example,dc=com' 'uid=Al' -d 255 -H ldap://192.168.1.73:389/
and the following is what I get
ldap_url_parse_ext(ldap://192.168.1.73:389/)
ldap_create
ldap_url_parse_ext(ldap://192.168.1.73:389/??base)
ldap_pvt_sasl_getmech
ldap_search
put_filter: "(objectclass=*)"
put_filter: simple
put_simple_filter: "objectclass=*"
ldap_build_search_req ATTRS: supportedSASLMechanisms
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP 192.168.1.73:389
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 192.168.1.73:389
ldap_pvt_connect: fd: 3 tm: -1 async: 0
ldap_close_socket: 3
ldap_msgfree
ldap_err2string
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
I can connect to the vm via ssh and run the ldapsearch, so connecting shouldn't be an issue. I have configured the router to make the machines ip's static (both the vm and the physical)
any help I could get would be very appreciated.
Thanks,
Al
Firewall? It wouldn't be inconceivable that out of the box the firewall would allow ssh through but not ldap. You also need to verify that your ldap server is configured to listen on the outside interface and not just the loop back. Openldap logging can also be setup to be very verbose about the connections it is receiving. You should do that and monitor your syslog while attempting to connect. That should give you enough information to figure out where the connection is being blocked.
I connect to a solaris (10) server through SSH from my linux machine.
However, when I attempt to open another terminal using " xterm" , then it does not work.
I set the DISPLAY env variable to 127.0.0.1:0.0, but it gives the following error:xterm Xt
error: Can't open display: 127.0.0.1:0.0
Please suggest a solution to rectify this.
Thanks
-Mike
That's the address of the X server on the target machine. You need to address the X server on the client machine on which you're working. The easiest way is to just use ssh -X or -Y, (see man ssh(1)) as
client: ssh -Y solaris
in order to connect to the remote machine; you need login info too
This just sets up an X connection, tunneled through ssh.
Otherwise, you can do it by hand as
client:
$ echo $DISPLAY
client:3:4
remember it's not *always* 0.0
$ xhost +solaris
You have to allow connections from the remote machine
$ ssh solaris
sets up a remote shell, you still need ssh login info
solaris:
$ export DISPLAY client:3.4
make sure its the server on 'client' you're using
$ xterm
This should now give you a 'solaris' xterm window on 'client'
As Charlie mentioned, use ssh -X hostname when connecting.
If all else fails enter xhost + on your remote machine. Hope that helps.
Set the display to your linux IP address, not localhost.
127.0.0.1 is localhost : therefore on the Solaris server, it's the server itself.