I'm trying to set up cloud hosting with Digital Ocean.
Please skip to the bold part with asterisks (***) for the actual problem. Everything below here, above that part is background info.
I need to generate an RSA key pair, so I navigate to my cd ~/.ssh/ directory, then:
ssh-keygen -t rsa
I already have existing id_rsa and id_rsa.pub files, so when prompted:
Enter file in which to save the key (/demo/.ssh/id_rsa):
I enter the following to create a new pair:
~/.ssh/id_cloudhosting
I'm then asked for a passphrase, which I simply press return for "no password":
Enter passphrase (empty for no passphrase):
I repeat the above for confirmation, and the final output looks as follows (just a demo image):
Now that I have two new files, id_cloudhosting and id_cloudhosting.pub I need to copy the contents of the public file to my Digital Ocean hosting 'Add SSH console'. I do that like so:
cat ~/.ssh/id_cloudhosting.pub
Which returns the contents of the file:
ssh-rsa
bUnChOFcOd3scrambledABCDEFGHIJKLMNOPQRSTUVWXYZnowIknowmy
ABCnextTIMEwontyouSINGwithmeHODOR demo#a
I paste the key into my hosting console and it saves successfully.
The next step is where the permission issues start: ****************
I need to "spin up a new server" - step four from their docs. So I enter the following:
cat ~/.ssh/id_worker.pub | ssh root#[my.hosting.ip.address] "cat >> ~/.ssh/authorized_keys"
Which should copy the public key as root to a newly created file called authorized_keys
This step never gets created because I'm immediately asked for a password to my host. I didn't ever create one! I pressed return (or enter) at that point, so I do the same when prompted, and get permission denied!
root#[host.ip.address]'s password:
Permission denied, please try again.
root#[host.ip.address]'s password:
Permission denied, please try again.
root#[host.ip.address]'s password:
Permission denied (publickey,password).
How can I rectify these permission denied issues?
EDIT: FIX BELOW
It seems as though, by using an unconventional (other than id_rsa) file, I needed to explicitly identify the file by doing the following:
ssh root#droplet.ip.address -i /path/to/private_key_file
...be sure not to use the public_key_file there. I am not connected to the server from my terminal. This is after destroying my previous droplet, creating a fresh one, with fresh key files, as #will-barnwell suggested
Assuming you have followed the linked guide up to and through Step Three, when you create a new server from their Web UI use the "Add SSH Keys" option and select the key you added to your account previously.
When actually spinning up a new server, select the keys that you would
like installed on your server from the "Create a Droplet" screen. You
can select as many keys as you like:
Once you click on the SSH key, the text saying, "Your
root password will be emailed to you" will disappear, and you will not
receive an email confirmation that your server has been created.
The command you were using was to add an ssh key to pre-existing server. Judging from the above quote I bet the password that you are being prompted for is in your email.
Why?
When you create a server on Digital Ocean ( or really most cloud hosting services ) a root password is automatically generated for you, unless you set the server up with an authorization key.
Using key authentication is definitely a good security choice, but make sure to read the instructions carefully, don't just copy/paste commands and expect it all to work out.
EDIT: OP's comments on the question have shed additional light on the matter.
New Advice: Blow your server away and set up the SSH keys as suggested, your server is probably unusable if it is not accepting your old SSH key and is prompting you for a password you don't have.
Be careful messing around with your last auth key, add a new one before removing an old one.
Related
Can someone please give me an example for corporatePasswordStore that is mentioned here:
https://docs.corda.net/node-administration.html?fbclid=IwAR0gRwe5BtcWO0NymZVyE7_yMfthu2xxnU832vZHdbuv17S-wPXgb7iVZSs#id2
I've been doing a lot of research in the last few days on how to hide the plain passwords from node.conf; it's a new topic for me and this is what I came up with so far:
Create a priv/pub key with gpg2
Create a password store with pass (using the key that I generated earlier).
Store all the plain passwords from node.conf inside that password store.
Replace the plain passwords in node.conf with environment variables (e.g. keyStorePassword = ${KEY_PASS})
Create a script file (e.g. start_node.sh) that will do the following:
a. Set an environment variable to one of the passwords from the password store: export key_store_password=$(pass node.conf/keyStorePassword)
b. Start the node: java -jar corda.jar
c. Restart the gpg agent to clear the cached passwords, otherwise you can get any password from the store without passing the passphrase: gpgconf --reload gpg-agent
Pros:
Using the bash file start_node.sh allows to set many passwords as environment variables at once (e.g. keyStore, trustStore, db passwords, RPC user password)
Since we are running the bash file with bash start_node.sh and not source start_node.sh, the environment variable is not exposed to the parent process (i.e. you cannot read that environment variable value inside the terminal where you ran bash start_node.sh
History commands are not enabled by default inside bash scripts.
Cons:
You no longer can have a service that automatically starts on VM startup, because the start_node.sh script will ask for the passphrase for your gpg key that was used to encrypt the passwords inside the password store (i.e. it's an interactive script).
Am I over-complicating this? Do you have an easier approach? Is it even necessary to hide the plain passwords?
I'm using Corda open source so I can't use the Configuration Obfuscator (which is for Enterprise only): https://docs.corda.r3.com/tools-config-obfuscator.html#configuration-obfuscator (edited)
I wrote a detailed article here: https://blog.b9lab.com/enabling-corda-security-with-nodes-configuration-file-412ce6a4371c, which covers the following topics:
Enable SSL for database connection.
Enable SSL for RPC connection.
Enable SSL for Corda webserver.
Enable SSL for Corda standalone shell.
Hide plain text passwords.
Set permissions for RPC users.
How can I change the user's password over ssh connection (not via browser interface) on the UBNT (Ubiquity Network) device, more specifically airOS8 WA v8.x board?
I want to avoid the ridiculous restriction imposed by their web interface on the password complexity (the only thing they don't require in the password is the unicorn's blood). I don't feel comfortable with someone else telling me what my passwords should look like (for my own well being, of course), so I'd like to change it via ssh connection, where this restriction is not being imposed.
I followed the discussion on their forums, which is just a useless bike-shedding over the opinions if the developers should impose such restrictions (without the switch to turn that off) or not.
I found the way to do this and wanted to share with others, who need to do the same thing.
First, log in to your device over an ssh connection. Then, issue a passwd command to change your password. If you now just reboot your device, the new password won't be saved, so read on.
Next, you need to copy the new password hash to a file named /var/tmp/system.cfg. So, first, type cat /etc/passwd, to see the new password hash, which should look something like this:
ubnt:$1$ssssssss$hhhhhhhhhhhhhhhhhhhhhh:0:0:Administrator:/etc/persistent:/bin/sh
where ssssssss is the Salt and hhhhhhhhhhhhhhhhhhhhhh is the Hash of the new password. We need to copy all that to the /var/tmp/system.cfg file, so type:
vi /var/tmp/system.cfg and in there, find the line that starts with users.1.password= and change it to be like this (press 'I' for Insert operation):
users.1.password=$1$ssssssss$hhhhhhhhhhhhhhhhhhhhhh
where Salt and Hash will be something randomly generated. When you finish changing that line, press Escape key and then save/quit the file (pressing colon, 'w', 'q' and Enter key, like ':wq')
Once you're back in the shell, type save to save this configuration permanently and then type reboot to check if your password survived the reboot process.
That should be it.
Thanks, but much better is to use a hash of default password ubnt, to get it, just run grep users.1.password /var/etc/default.cfg
I am in this situation (Please note that I am still new to the idea of this ssh thing):
Basically, I have already set up SSH for my Github, so every time I do git push origin master, it will not prompt me to enter username and password, which is good. Now I want to set up another SSH for logging onto my school server. I wanted to follow the same instruction which I did for Github in this link. But after I typed in ssh-keygen -t rsa -C "me#school.com" . It says that /.ssh/id_rsa already exists. Overwrite (y/n)? .
Obviously, I do not want to overwrite it, since I still want instant access to my Github account. I know that I can create another id_rsa under a different name, but is this a good approach ? Does it have any side-effects ? It seems to look nicer if I can just append the new RSA key to the existing id_rsa but I have no idea how to do so. (Need to know the right command to do this I guess)
You don't need to create a new key. you can us the same public key and put it on your school account. The parameter -C just put's a comment to your key and it is only there, so that you can easily recognize it as your key. It has nothing to do with the ability log in on a specific server.
I installed cloud-in-a-box/fastrack of Eucalyptus and am able to create instance and log into it. But when trying sudo, sudo su - or login in as root I'm asked for a password. I'm not sure what the password might be. Does anyone know what the default password for the Image is?
I think this is how the image is designed. It uses the cloud-user account only and has no root access, nor does it allow sudo.
There are other starter images available that can be "installed" that have sudo as root enabled. In those cases you simply issue
sudo su -
and you become root.
To see what is easily available use:
eustore-describe-images
As a note, some of the other starter images have different accounts (not cloud-user), such as ec2-user. If you don't know which account to use simply try to ssh into the instance as root and it will usually get a message back telling you:
Please login as the user "ec2-user" rather than the user "root".
I am not sure if there is a password on the root account in that image. Regardless, the recommended way to log into instances is by creating an SSH key (euca-create-keypair KEYNAME >KEYNAME.pem), specifying it when running an instance (euca-run-instance -k KEYNAME), and then logging in using the key generated (ssh -i KEYNAME.pem root#INSTANCE-IP). You'll probably have to change the permissions on that .pem file before SSH will allows you to use it (chmod 0600 KEYNAME.pem). The instance obtains the public portion of the key from the cloud at boot time and adds it to the authorized_keys file.
I'm trying to add a new user to my Ubuntu system and give them SSH access, using public/private key to log in. But I can't seem to get it to work.
Used putty gen to generate a public / private key pair. Then copied the public key into their homedir/.ssh/authorized_keys. But when I load the private key into Pageant in my windows session and try to use putty to get in, I am getting "Disconnected: No supported authentication methods available".
The funny thing is, If i put the same public key in the existing user's ./.ssh/authorized_keys file, I can log on using that user. This was set up by someone before me who I can't contact now though, so I don't know what the difference is.
If I check the etc/ssh/sshd_config file, the AuthorizedKeysFile line is commented out.
#AuthorizedKeysFile %h/.ssh/authorized_keys
BUt even if I put it back in and restart ssh service it still doesn't work (though I didn't think would solve it because why would the current user work)
Is there anything I can do?
Read the sshd daemon's error messages in your system log (auth.log or security.log or some such).
My guess would be that the directory and/or file permissions on .ssh or .ssh/authorized_keys are too permissive (insecure) in the new user's home. This should fix it if this is the problem:
chmod 700 .ssh
chmod 644 .ssh/authorized_keys