I am trying to deploy a build from bitbucket via bitbucket pipelines.
Basically what I need is to copy the static build files into a remote server.
This server requires a .pem file for authentication.
I have tried specifying this key in the following ways:
As a repository variable
As a file within the repository itself and pointing to it within the build XML.
As a parameter for scp-deploy.
But in all cases the same issue occurs:
Host key verification failed. lost connection error Command failed
with exit code 1.
So, would be a great help if someone could tell me how to specify this within the bitbucket-pipelines.xml file for a smooth build.
Pipelines run within a docker container. There could be 2 ways 2 do it -
You can add the .pem file content in secret repo var, write the content in a file and name it like something.pem, replace the configuration xml file with the generated file location;
Secret repo var looks like: Name - MY_PEM Value - Some encrypted content
In you pipeline:
To write the file locally:
echo $MY_PEM > my.pem
To replace the fiel path in config XML
sed -i "s/{A Placeholder In Your XML}/${MY_PEM_PATH}/g" path/to/your/config.xml
Bundle the .pem file within a docker container and deploy the container in a private container registry(E.g. - Google Cloud, AWS etc.). Use that container as your base image.
I have just purchased a dedicated server from a UK hosting company that uses cPanel and I have root access
I am using scp to copy a huge (> 2tb) website from another hosting company (1&1 IONOS using Plesk not that it should make any difference)
The files are copying over .. using SSH I can use the "ls" command to list all the files that I've copied over
However, when I use the File Manager option via cPanel interface, I can see the first folder name on the left hand side (i.e. public_html/my-copied-site) but on the right hand window it shows the directory as empty
If I use the "ls" command, I can see the files & folders
if I try an access any of the files directly via a web browser then I get a 403 Forbidden message
What have I done wrong?
The answer to this problem is the ownership of the folder
Using scp over SSH meant that I was logged in as "root" and therefore the owner of the folders was also "root"
Changing the owner of the folder (using "chown" command) to the account's name resolved the problem
Hope this helps someone out
In my Google Cloud Platform, vm instance, I accidentally changed the permission of /etc/ssh, and now I can't access it using ssh nor filezilla.
The log is as below:
###########################################################
# WARNING: UNPROTECTED PRIVATE KEY FILE! #
###########################################################
Permissions 0660 for '/etc/ssh/ssh_host_ed25519_key' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
key_load_private: bad permissions
The only thing I can access to is gcloud command or serial console.
I know I need to change the directory's permission back to 644 or 400, but I have no idea how as I can't access the ssh.
How do I change the permission without accessing ssh?
Any help would be much appreciated!
This problem can be solved by attaching the boot disk to another instance.
STEP 1:
Shutdown your instance with the SSH problem. Login into the Google Cloud Console. Go to Compute Engine -> VM instances. Click on your instance and make note of the "Boot disk" name. This will be the first disk under "Boot disk and local disks".
STEP 2:
Create a snapshot of the boot disk before doing anything further.
While still in Compute Engine -> Disk. Click on your boot disk. Click on "CREATE SNAPSHOT".
STEP 3:
Create a new instance in the same zone. A micro instance will work.
STEP 4:
Open a Cloud Shell prompt (this also works from your desktop if gcloud is setup). Execute this command. Replace NAME with your instance name (broken SSH system) and DISK with the boot disk name and ZONE with the zone that the system is in:
gcloud compute instance detach-disk NAME --disk=DISK --zone=ZONE
Make sure that the previous command did not report an error.
STEP 5:
Now we will attach this disk to the new instance that you created.
Make sure that the repair instance is running. Sometimes an instance can get confused on which disk to boot from if more than one disk is bootable.
Go to Compute Engine -> VM instances. Click on your instance. Click Edit. Under "Additional disks" click "Add item". For name enter/select the disk that you detached from your broken instance. Click Save.
STEP 6:
SSH into your new instance with both disks attached.
STEP 7:
Follow these steps carefully. We will mount the second disk to the root file system. Then change the permissions on the /mnt/repair/etc/ssh directory and contents.
Become superuser. Execute sudo -s
Execute df. Make sure that /dev/sdb1 is not mounted.
Create a directory for the mountpoint: mkdir /mnt/repair
Mount the second disk: mount /dev/sdb1 /mnt/repair
Change directories: cd /mnt/repair/etc
Set permissions for /etc/ssh (notice relative paths here): chmod 755 ssh
Change directories: cd ssh
Execute: chmod 644 *.pub
Execute: chmod 400 *key
ssh_config and sshd_config should still be 644. If not fix them too.
Shutdown the repair system: halt
STEP 8:
Now reverse the procedure and move the second disk back to your original instance and reattach. Start your instance and connect via SSH.
Note: To reattach the boot disk you have to use gcloud with the -boot option.
gcloud beta compute instances attach-disk NAME --disk=DISK --zone=ZONE --boot
I am working off the Spinnaker Getting Started guide. Spinnaker is now running on an EC2 instance and accessible via http://localhost:9000.
When I try to create a new Application I understand that expect my-aws-account and my-google-accountoptions. I am however seeing no options on this screen. Any idea about what could be going wrong?
Create an AWS User account for Spinnaker
In AWS Console, open AWS Identity & Access Management -> Users -> Create New Users.
Enter a username and hit Create.
Create an access key for the user.
Click Download Credentials, you will need them later.
Click Close.
Apply permissions to the new user
Click on the username you entered for a more detailed screen.
On the Summary page, click on the Permissions tab.
Attach a managed policy
Click Attach Policy.
Click the checkbox next to PowerUserAccess, then click Attach Policy.
Create an Inline Policy
Click on the Inline Policies header, then click the link to create an inline policy.
Click Select for Policy Generator.
Select AWS Identity and Access Management from the AWS Service pulldown.
Select PassRole for Actions.
Type * (the asterisk character) in the Amazon Resource Name (ARN) box.
Click Add Statement, then Next Step.
Click Apply Policy.
Add AWS credentials to Spinnaker
Connect to the Spinnaker instance (I'm assuming you're using Linux)
Run the command: sudo mkdir /home/spinnaker/.aws
Run the command: sudo vim /home/spinnaker/.aws/credentials
Add the following lines to the file, then save and quit:
Make sure to replace my-aws-account to the name of your AWS account
Make sure to replace the values of the key ID and access key with the credentials you downloaded in Step 1, Part 4
[my-aws-account]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Update the default Spinnaker configuration files
Run the command: sudo vi /etc/default/spinnaker
Locate the line SPINNAKER_AWS_ENABLED, and change the value to true
Locate the line SPINNAKER_AWS_DEFAULT_REGION, and change the value to the region where your Spinnaker instance runs (e.g. us-east-1, without the quotes)
Save and quit
Update the local Spinnaker configuration files (these override the stock YAML files that come with the installation of Spinnaker)
Run the command: sudo vim /opt/spinnaker/config/spinnaker-local.yml
Locate providers, then locate aws beneath that
Beneath aws, locate enabled and change the value to true
Beneath aws, locate defaultRegion and change the value to the region where your Spinnaker instance runs (e.g. us-east-1, without the quotes)
Beneath primaryCredentials, locate name and change the value to my-aws-account
Make sure to replace my-aws-account to the name of your AWS account
Save and quit
Restart Spinnaker
Run the command: sudo /opt/spinnaker/scripts/reconfigure_spinnaker.sh
Run the command: sudo restart spinnaker
Reset the tunnel from your local machine to the Spinnaker instance
I am a newbie to Amazon web services, was trying to launch an Amazon instance and SSH to it using putty from windows. These are the steps I followed:
Created a key pair.
Added a security group rule for SSH and HTTP.
Launched and instance of EC2 using the above key pair and security group.
Using PuTTYgen converted the *.pem file to *.ppk
Using putty tried connecting to the public DNS of the instance and provided the *.ppk file.
I logged in using 'root' and 'ec2-user', and created the PPK file using SSH1 and SSH2, for all these attempts I get the following error in putty,
"Server refused our key"
Can you guys please help, any suggestions would be greatly appreciated.
I assume that the OP figured this out or otherwise moved on, but the answer is to use ubuntu as the user (if the server is ubuntu).
1) Make sure you have port 22 (SSH) opened in Security Group of EC2 Instance.
2) Try connecting with Elastic IP instead of public DNS name.
I hope you have followed these steps Connecting EC2 from a Windows Machine Using PuTTY
Another situation where I got the "Server refused our key" error when using putty, from windows, to ssh to an EC2 instance running ubuntu:
The private key was wrongly converted from .pem to .ppk.
puttygen has two options for "converting keys".
Load your .pem file into puttygen using the File->Load Private Key option and then save as .ppk file using the Save Private Key Button.
DO NOT use the menu option Conversions->Import Key to load the .pem file generated by EC2.
See the puttygen screenshots below, with the two menu options marked.
Check the username, it should be "ubuntu" for your machine.
Check if traffic is enabled on port 22 in Security group.
Check if you are using the correct url i.e ubuntu#public/elasticip
Maybe worth of checking one more thing. Go to AWS console, right mouse click on the instance and choose "Connect...". It will show you the DNS name that you want to use. If you restarted that instance at some point, that DNS name could have changed.
I had a similar problem when I tried to connect an instance created automatically by the Elastic Beanstalk service (EBS). But, once I linked my existing key name to the EBS (under Environment Details -> Edit Configuration -> Server Tab -> Existing Key Pair), I was able to login with 'ec2-user' and my existing key file (converted to .ppk) with putty.
This, however, terminates the running instance and rebuilds a new instance with access through the key pair named above.
Just in case it helps anyone else, I encountered this error after changing the permissions on the home folder within my instance. I was testing something and had executed chmod -R 777 on my home folder. As soon as this had occurred, once I had logged out I was effectively locked out.
You won't face this error if you SSH AWS directly using ".pem" file instead of converted ".ppk" file.
1) Use Git Bash instead of putty. Since you can run all the Linux commands in Git Bash. By installing Git you get to access Git Bash Terminal
2) Right click from the folder where you have ".pem" and select "Git Bash Here".
3) Your key must not be publicly viewable for SSH to work. So run "chmod 400 pemfile.pem".
4) Connect to your instance using its Public DNS - "ssh -i "pemfile.pem" ec2-user#ec2-x-x-x-x.us-west-1.compute.amazonaws.com"
5) Make sure to whitelist your Network IP for SSH in your_instance->security_group->inbound_rules
I assume you're following this guide, and connecting using the instructions on the subsequent page. Verify a couple of things:
You converted the key correctly, e.g. selected the right .pem file, saved as private key, 1024-bit SSH-2 RSA
The Auth settings (step 4 in the connection tutorial) are correct
I was having the same trouble (and took the same steps) until I changed the user name to 'admin' for the debian AMI I was using.
You should lookup the user name ofthe AMI you are using. The debian AMI is documented here
http://wiki.debian.org/Cloud/AmazonEC2Image/Squeeze
I have had this same problem. The AMI you are using is the one that is also used by the "Cloud Formation" templating solution.
In the end I gave up with that, and created a Red Hat instance. I was then able to connect by SSH fine using the user root.
The instructions here: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html work fine using a Red Hat instance but not using an Amazon Linux instance. I assume they have some username that I didn't think to try (root, ec2-user, and many other obvious ones, all were refused)
Hope that helps someone!
I use Debain AMI and I try ec2-user, root but correct login is 'admin'.
I was getting the same error when I tried to create a new key pair and tried to use that new pem/ppk file. I noticed that the Key Pair Name field on the instance was still the old one and in poking around. Apparently, you can't change a key pair. So I went back to the original key pair. Fortunately, I didn't delete anything so this was easy enough.
Try an alternative SSH client, like Poderosa. It accepts pem files, so you will not need to convert the key file.
If you already have a key pair, follow these steps:
Convert *.pem to *.ppk using PuTTYgen (Load pem file key then Save ppk)
Add ppk auth key file to Putty SSH>Auth options
Enter "Host Name (or IP address)" field: ubuntu#your-ip-address-of-ubuntu-ec2-host))