I am using CHEF 12 and trying to bootstrap an EC2 instance (Win server 2012 R2) from my workstation. However, I am getting the below error.
> Waiting for remote response before
> bootstrap.....................ERROR: No response received from remote
> node after 2.08 minutes, giving up. ERROR: Network Error: No
> connection could be made because the target machine actively refused
> it. - connect(2) (http://52.76.1.57:5985) Check your knife
> configuration and network settings
I have two CHEF servers (Hosted as well as on-premises); I have tried bootstraping the EC2 instance using each of these, but get the same result.
Chef bootstrap command issued via power-shell:
PS ~\chef-repo> knife bootstrap windows winrm 52.76.1.57 --winrm-user Administrator --winrm-password '******' --node-name node_145 --run-list 'recipe[ie::esc],recipe[install_iis]'
As far as I researched, it is because I am not able to establish a WINRM connection from my workstation to the Ec2 instance. I am however able to connect to another Win 2012 server within my office network and bootstrap successfully.
have already logged in remotely to the EC2 instance and run winrm quickconfig from powershell.
have set the Administrator password to a desired one.
Have opened inbound firewall rule for WIndows remote management on ports 5985 and 5986
Set up setcurity group and allowed inbound Custom TCP rule for ports 5985 and 5986 on AWS
you took all the necessary steps for this, would it be possible that you are getting filtered by a firewall (e.g company firewall)?
fyi, I managed to bootstrap a machine with the following steps:
# configure winrm for using knife winrm
winrm set winrm/config/service/auth '#{Basic="true"}'
winrm set winrm/config/service '#{AllowUnencrypted="true"}'
set-item WSMan:\localhost\Client\allowunencrypted $true
#turn off firewall
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False
EDIT: to sum up below comments, the problem was the company firewall that was blocking the traffic
Windows 2012 R2 introcuced changes within WinRM security, which rendered some of old articles / readme examples explaining usage of knife-ec and knife-windows unusable.
This article http://blog.coderinserepeat.com/2015/07/15/chef-knife-ec2-and-knife-windows/ pretty much sums up how to deal with this in recent versions of knife plugins.
Related
I've followed the AWS DocumentDB docs for connecting outside VPC:
I created an EC2 instance in the same security group and VPC as the DocDB cluster
In the security group I opened 22 port access for my IP, and also opened port 27017 for communication inside the security so EC2 instance can SSH tunnel to the DocDB
I ran ssh -f -i "ssh-tunneling-access.pem" -L 27017:{doc-db-cluster}:27017 {ec2-instance-user}#{ec2-instance-dns} -N to open the SSH tunnel
In another terminal I tried to connect using Mongo shell with mongosh "mongodb://{credentials}!#localhost:27017/?tls=true&tlsAllowInvalidHostnames=true&tlsCAFile=rds-combined-ca-bundle.pem"
I got an error "MongoServerSelectionError: read ECONNRESET"
I'm running on Windows 11, and my terminal is Powershell Core.
Any ideas what did I miss and/or how to troubleshoot it?
First of all, make sure you can connect to DocumentDB from the EC2 instance. The security group attached to the DocumentDB cluster has to allow port 27017 with source the EC2 instance (or the security group of the EC2).
Second, is not clear from where you're initiating the tunnel. Did you execute step 3. on the Windows 11 machine? Have you installed OpenSSH on Windows?
How about using a GUI client, like Robo 3t, which has SSH tunneling support? Instructions on how to connect can be found here.
I have two non-domain VMs. Both running the same version of PowerShell. One of the VMs is hosting a transparent-networked Docker container of WindowsServerCore. The non-Docker VM has * for the trusted machines. The Docker container has Enable-PSRemoting run and is hosting a self-signed certificate. Both Docker VM ports 5985 and 5986 are accessible to the non-Docker VM as proven with a telnet session to the Docker IP on those ports. I've added new users to the Docker VM and set them up in the Administrators group. I've reset the WinRM service.
No matter what username/password combo I use, I always get access denied when trying to establish a remote PowerShell session on either HTTP or HTTPS from the non-Docker VM.
Has anyone been able to get this to work?
I'm having trouble connecting to a mongo instance running on a windows azure vm running Windows Server 2012 R2. I've verified the following things
The network security group has rule allowing port 27017 inbound (* -> 27017)
The VM has TCP port 27017 inbound open on all profiles (currently, my firewall is completely disabled)
Mongo is running as a windows service. I've verified it is up and running. I was able to connect, insert, and find records in the shell on the remote vm that's running Mongo
When I run netstat -a, I can see 0.0.0.0:27017 with the status "LISTENING"
If I try to ping the VM, it times out (I believe this is expected)
Port 22 is open in the firewall and in the network security group rules
I am not running any 3rd party anti-virus software on my local machine
I tried restarting the VM both from the OS and from azure portal
I tried removing the rules from network security group and readding them
I've tried connection via SSH in bash on my local machine running windows 10 using the most basic command mongo <ip-address>. It times out with the message ssh: connect to host x.x.x.x port 22: Resource temporarily unavailable
I've tried connection via Putty/SSH. Same result
I've tried connection via MongoDB Compass which gives a similar error Could not connect to MongoDB on the provided host and port
any ideas?
Here's the config I'm using
systemLog:
logAppend: true
verbosity: 0
traceAllExceptions: true
path: c:\MongoLogs\mongolog.log
destination: file
net:
port: 27017
bindIp: [127.0.0.1, <external-ip>]
http:
enabled: true
JSONPEnabled: false
RESTInterfaceEnabled: true
storage:
dbPath: c:\MongoData\
As it turns out, the VM had multiple network security group profiles attached to it. When I click "Effective security rules" it showed a second tab that had another profile that appears to have been inherited from the subnet -- sufficed to say, it did not have the permissions that are needed. By opening the correct ports on that profile as well, connections we then going through just fine. We're gonna clean that up, but in short, there was a conflict of permissions.
I am trying to bootstrap a windows winrm using knife command.
I have enabled the tcp port 5985.
But i still get the following error:
ERROR: Network Error: Connection refused - connect(2) (http://:5985)
I am able to remotely login to the machine as well by providing username and password
I could not resolve. Has anyone come across this problem and found a solution?
Check that you can telnet remote_host 5985. This should open a dumb session into which you can enter "quit". If not, look again at how you have enabled winrm and the firewall on the remote host.
I got winrm bootstrap working on Windows VMs which did not have firewall enabled like this:
All the following on the remote Windows machine you want to bootstrap...
Enable winrm:
winrm quickconfig -q
Enable and start the firewall service (so we can successfully config winrm):
sc config mpssvc start= demand
sc start mpssvc
Configure winrm per chef recommendations:
winrm set winrm/config/winrs #{MaxMemoryPerShellMB="300"}
winrm set winrm/config #{MaxTimeoutms="1800000"}
winrm set winrm/config/service #{AllowUnencrypted="true"}
winrm set winrm/config/service/auth #{Basic="true"}
Stop the firewall service again:
sc stop mpssvc
... or configure it to allow to winrm connections from the workstation.
Now, on your workstation, validate the set up:
Validate that remote host is listening on default winrm port
telnet remote_host 5985
(If connection is successful, a blank telnet session will open. You can enter "quit" to exit it.)
Optionally validate that knife winrm can connect to the remote host (e.g. to list the c:\ directory)
knife winrm -m remote_host -x remote_user -P remote_password 'dir c:\'
Bootstrap the node
knife bootstrap windows winrm remote_host -x remote_user -P remote_password
Since you ask for an answer drawing from credible and/or official sources here are the references I found useful when figuring out how to get winrm bootstrap to work:
http://docs.opscode.com/install_windows.html
http://docs.opscode.com/plugin_knife_windows.html
http://developer.rackspace.com/blog/step-by-step-walkthrough-to-using-chef-to-bootstrap-windows-nodes-on-the-rackspace-cloud.html
I have faced the similar issue.One of the reasons for this might be you knife-windows gem is not installed in expected location.
knife-windows resolves target hostname.if its not properly installed winrm knife cant resolve targetname.So to overcome this install knife-windows as below
To install the knife windows plugin using RubyGems, run the following command:
$ /opt/chef/embedded/bin/gem install knife-windows
if properly installed you should be able to find knife-windows at /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/
I am trying to run putty on Windows 7.
I need to run some SSH commands to upgrade Magento. Every time putty gives me this fatal error:
network error: connection refused
I have even tried to use it through winSCP. Note that putty is running fine on my client's side, but for me it's giving me that error every time.
I tried using port 22, 23 and a few others without success. I have also tried with Windows Firewall both enabled and disabled.
Thank you.
Install open-ssh or ssh in target Linux machine solved my problem .
Use below commands:
sudo apt install ssh
sudo systemctl status ssh
sudo systemctl enable ssh
The following are the list of possibilities of this error:
1) Common cause is - Your IP is blocked or not whitelisted in the server which can be done by editing the file at /etc/csf/csf.conf
2) Disable the windows firewall settings and check..
The above two things should work in most of the cases
3) This is very unusual and when the above two options fails it is very difficult to find the solution
In this case the traceroute to the server host or IP works usually but putty fails
port 22 looks normal and working but connection fails and restarting SSH (service ssh restart) also does not work
reboot or restart the server but still fails
Adding IP in firewalls or whitelisting the local IP may not workout
This case generally happens when the server is migrated or new server. IP of the old server might be whitelisted locally, but don't have port 22 open, or some other local filtering is occurring for this new IP but not the old server IP..
In this case you need to change the port to some 522 or 530 some unusual port will help in sorting it out.. The same port you have to use for the SFTP connection also .. where as FTP connections works normally..
or you have to whitelist the IP locally or open the TCP in and out to port 22 if you want to use the port 22..