How would I go about doing this on the terminal?
sftp then asks me for a password. how do I include my DSA key so that I do not have to use the password?
As sftp uses SSH protocol for communication, you may generate private/public key pair using ssh-keygen (read everything their!). Then read this HOWTO about how to transfer your key to remote server. If you need more, read more detailed description of OpenSSH Public Key Authentication.
If you setup your key correctly, and remove SSH server is configured to use key authentication, you will be granted the access without additional password.
If you have ssh-agent running, holding the key to the site, it will handle authentication for you.
Related
I have a running Windows server image on EC2.
I created an additional administrator login and have been using it login using RDP. Unfortunately I've lost the PEM file for the "Administrator" account and I've also disabled it for "safety"
Since I have access to the instance through an alternative administrative account I'm trying to figure out a few things:
Do need the "Administator" account PEM file in future?
If I get Amazon to generate a new PEM file using the same name that I currently have, how do I replace the "Administrator" key pair for the instance?
I've searched all over and can't find an answer on how to replace the key pair or add an additional key pair to a running "Windows" instance
Everything talks about shutting down and creating an new instance. I cannot shut down this server, so that must be a way to replace the key pair for the "Administrator" account.
I can't even find where Windows stores the key pair in a Windows server.
When an instance is first launched from one of the Amazon-supplied Windows AMIs, some code on the instance generates a random Administrator password. This password is then encrypted with the selected Keypair and passed back to AWS (you can actually see it in the System Log).
When you wish to first login to the instance, you will need to use the PEM to decrypt the Administrator password. You can then login to the Windows instance using that password.
It is recommended that you immediately change the Administrator password or connect the instance to Active Directory -- basically, follow your standard company security practices.
If you remember the password, you will not require the PEM file again. In fact, if you change the password, then even having the PEM will not facilitate access because it will only decrypt the original password, not the current password.
Bottom line: Ignore the PEM file. You still have administrative access to the instance, so you don't even need the Administrator account anymore. If you wish to use the Administrator account, simply use your existing administrative login to reactive it and set the password. There is no reason to panic and, actually, no reason to do anything.
While signing up for Amazon EC2 and enabling ssh, I have to create and download a private key (.pem) and a secret access key.
How are they different? What different functions do they have?
You need to read a good tutorial on SSH, but here is a summary:
The Access Key ID and Secret Access Key are like a username and password. They allow you to "do stuff" on the AWS API using the commandline tools or code you write.
The private key (.pem) is like a password for talking (SSH) to an individual box that you have launched. (i.e. not "AWS itself", but "your box within AWS".) You can have different passwords to different boxes if you want, but most of the time you only need one.
If you know how SSH works, they are just putting down ~/.ssh/known_hosts with the public part of your key, allowing you to log in for the first time. You can change that file later to add more users or rotate your SSH keys.
I am trying to connect to a SFTP server for a client of ours and send files in an automated process using MS windows. The details I have received from the client do not include the password. I instead have the public-private key pair using PuTTY.
The typical connection string used is as follows:
open sftp://username:password.SFTPURL:port -hostkey="ssh-dss 1024 XXXXXXX"
I do not however understand how to specify the private key in this connection instead of the password. how do I tell the script where the private key lies and is there a particular key word to use when connecting using public key?
I am new at this so please bear with me.
Thanks!
I can't get the system of managing ssh keys.
I want to push application to Heroku, so I tried to push but get error.Here is my log
$ git push heroku master
! Your key with fingerprint bf:f6:ed:14:9d:cd:52:a2:a3:16:b2:e9:b4:f2:bf:ba is not authorized to access warm-samurai-6574.
fatal: The remote end hung up unexpectedly
User#PK /e/examples (master)
$ heroku keys:add
Found existing public key: C:/Users/User/.ssh/id_rsa.pub
Uploading SSH public key C:/Users/User/.ssh/id_rsa.pub
!This key is already in use by another account. Each account must have a unique key.
User#PK /e/examples (master)
$ heroku keys
=== 1 key for denys.medynskyi#gmail.com
ssh-rsa AAAAB3NzaC...etyxYh4Q== User#PK
Every account has own ssh key. So I can push from any computer, because ssh key is pushing to heroku ?
Every application on heroku should have own ssh key or not ?
Basically, your computer has an SSH key. However, the SSH key on it is associated with another Heroku account (different from the one you are using now). Your best bet would be to generate a brand new SSH key and add it to Heroku.
Just make a new SSH key on your machine and upload it to Heroku:
$ ssh-keygen
Make sure to save it as '/Users/User/.ssh/new_id_rsa.pub' when the prompt asks you.
$ heroku keys:add /Users/User/.ssh/new_id_rsa.pub
This should allow you to use Heroku.
As for your other questions: you can push to Heroku from any computer as long as you add the computer's SSH keys through heroku keys:add. And no, every application does not need to have it's own SSH key.
Your computer has an SSH key, but that SSH key is associated with another Heroku account. If you need to use both accounts for different applications on the same computer you should make a new SSH key on your machine and upload it to Heroku:
$ ssh-keygen
Make sure to save it as '/Users/User/.ssh/new_id_rsa.pub' when the prompt asks you.
$ heroku keys:add /Users/User/.ssh/new_id_rsa.pub
You then need to add another host to your ~/.ssh/config:
Host heroku-alt
HostName heroku.com
IdentityFile ~/.ssh/new_id_rsa
And then update the .git/config in your project to use the host alias:
[remote "heroku"]
url = git#heroku-alt:myapp.git
fetch = +refs/heads/*:refs/remotes/heroku/*
By choosing between heroku and heroku-alt in the remote of the .git/config files of specific projects you can manage which projects use which credentials.
Heroku requires an SSH key to be unique to an account. Two accounts cannot have the same ssh key.
You can do ONE of these to solve your issue:
Unlink the ssh key from the other heroku account. Chances are you are not using that account. This is path of least resistance.
Delete the existing keys. Generate a new ssh public/private key pair. Advantage is you will retain the default name for keys and thus it will be automatically found by any application you use.
Generate a new ssh public/private key pair and save it alongside your existing keys. The disadvantage is, these two keys will have a custom name. If you end up using these keys often, you will need to locally set configure ssh to use these instead of the default id_rsa. This does require some work and might get involved.
Which you choose really depends on you.
If you choose the third option, refer this answer https://superuser.com/a/272613/25665 for how to configure ssh locally to always use the new keys for heroku. In case you are wondering why bother with this, well, you will be interacting with heroku by pushing to a git repository. That requires you to be authenticated using ssh. By default it will use the older keys and you wont be able to push. Its just easier to instead tell ssh to use the alternate key when interacting with warm-samurai-6574.heroku.com
The following link has instructions on creating a new key. You will need to either accept the default names or give custom ones depending on which option you chose.
https://devcenter.heroku.com/articles/keys
Can you push from any computer?
Again, it depends. If the computer has your ssh keys and its configured to use your keys for the heroku domain, then yes. You can instead choose to not copy your keys there and simply add the ssh keys present there to your heroku account.
Does each app require a unique key?
No. You can have multiple apps under one heroku account. They all will share the keys you upload to your heroku account.
Let me see if I understand this correctly.
Most of the replies are agree on that the ssh keys we are using for git identifies the computer, because the suggestion they made is to regenerate the key on the other computer and upload it to Heroku.
From my point of view the SSH key should identify me as a developer of the app, and this is what creates the confusion. This means I have to bring my private and public keys with me and use it on any computer I use which can be accomplished with a pendrive or something similar.
So my suggestion is: copy your public and private keys with you, put them in the computer you want to use for pushing to Heroku and protect your private key with a password.
I have another question to security in the web world.
So I read (and ask :P) about certificates and think I got what it is and how it works. My next question is putty specific. When I open a connection with putty to a new server with ssh (port: 22) I get a PuTTY Security Alert:
The server's host key is not chacked in the registry. You have to guarantee that the server is the computer you think it is.
The server's xxxx key fingerprint is:
yyyyyyyyyyyyyyyyyyyyyyyyyyy
If you trust this host, hit Yes... etc.
Now I am wondering what a key fingerprint means.
Is that just a certificate which putty hasn't in is cache yet?
thanks.
SCBoy
Those are the first bytes of the server certificate public key. The idea is that the key is a random number, so the first bytes are random too and therefore knowing that those first bytes are the same for two keys would likely mean that the keys are actually the same.
You can use this to validate the server. You could for example call the administrator of that server and ask him for the fingerprint of the key to validate that it's indeed the key of that server, not some man-in-the-middle server belonging to a malicious party.