I have created an EC2 instance and I now want to connect to it from a Chromebook. For the time being, I only have access to this Chromebook and I am after a way of generating my public key from the .pem file that Amazon issues.
I am familiar with how to do this via the Linux command line, but I need a web based solution for this.
You need an SSH client for Chrome, try this:
https://chrome.google.com/webstore/detail/secure-shell/pnhechapfaindjhompbnflcldabbghjo
Related
I am building an application and I also have the keystore for it. But, now I have to change my laptop and run the application on the new laptop so can I use the same keystore?
Yes. You can use the same keystore.
If your application code is the same and the location it reads the keystore from is the same, you can basically replicate your application on your new workstation exactly like your old workstation.
Why do we need to convert .pem file to .ppk file in aws to get access of server from putty?
PuTTY doesn't natively support the private key format (.pem) generated
by Amazon EC2. You must convert your private key into a .ppk file
before you can connect to your instance using PuTTY. You can use the
PuTTYgen tool for this conversion. This tool, available for both
Windows and Unix operating system, can convert keys.
See https://aws.amazon.com/premiumsupport/knowledge-center/convert-pem-file-into-ppk/
So, I have a client who needs a website. Although he would like to edit the webpage when I put it into the web. So I am wondering how would it be possible for just my client to edit the website, and not any other users. In HTML, CSS, JS of course!
Thanks, Albert
How competent is you client? Here's a few way I can see someone who is decently competent at computers editing a website (I've used them all):
SSH: If the site is running on a server with SSH, your client can directly SSH into the server and edit files. Not highly recommended but this is the "easiest" way (May be able to use their text editor via an SFTP plugin too to edit files on the server).
Git: Attach the web root to a git repository. This way the client can edit whatever they want on a local copy on their machine, test it and then deploy it to production or test by SSHing into the server and updating the repo.
No SSH? Use FTP is download the files, edit them on local machine and then upload new version to server.
All these options assumes the client can use the tools needed (SSH, Git or FTP) and knows webdev.
consider using some CMS, like WordPress or Drupal, so your client can edit almost anything on website without digging into git-flow or other technologies. I guess if he knew how to do it, he wouldn't ask. Another option is to create web site on a platform like Wix (or similar), but in this case customisation will be limited by platform
I want to deploy my app (Nodejs + Mongodb) in EC2. After installed Nodejs and MongoDb in EC2 instances, I do not know how to upload my source code to instances and where to upload it?
Thanks!
When you created your instances you should have also created an ssh key that you use to access the EC2 instance via SSH which you clearly have if you were able to install additional packages.
You can use this same key and method to connect to the instance with SFTP and upload the files you want like that.
You could also use scp to copy the files directly from the commandline or from a custom script.
With regard to where to upload the files - that all depends on you. What web servers are you using (if at all). Depending on your application you need to select a location that is accessible via your web server. The default location for an apache server would be /var/www
You can use WinScp (https://winscp.net/eng/download.php) to have an "explorer like" access to your EC2 linux:
Note: The ppk private key was created using the "node.pem" key from AWS. But you must make it accessible by running:
chown :Users node.pem
chmod 400 node.pem
Please excuse the frustrating undertones as I have attempted to get this set up correctly multiple times to no avail (possibly and most likely due to my ignorance, but also likely due to the lack of thorough and concise documentation).
I am trying to set up a git server so that I can share code amongst a small team of developers. Each developer may connect from multiple client PC's. I come from MS in the past so I am a bit spoiled in regards to development toolset, but it would be awesome if I could get something similar to TFS.
When trying to set up either gitosis (I understand this is deprecated for the git community per https://serverfault.com/questions/225495/ubuntu-server-gitosis-user-naming-convention) or gitolite, it seems as though as soon as I set it up I have to be extremely careful because it seems everything is balancing on toothpicks.
My latest attempt to set up a git server included moving my public key (benny.pub) from my laptop to the server, setting everything using that public key and pulling down the config to set up a repo and permissions. I then realized I want to develop on another PC so I created a new key (benny#desktop.pub) and renamed benny.pub to benny#laptop.pub which screwed things up obviously. This is where I know I was dumb by changing the name.
My question after a long-winded description is this: how can I set up a sturdy self-hosted git server with the ability to have multiple developers log in from multiple machines while maintaining security, etc? There has to be a proven technique (gitolite describes maybe 4-5 different ways...also frustrating) to do this as I'm sure I'm not the only one trying to do this exact same thing. Maybe git isn't right for my team?
Any help is greatly appreciated!
From my experience, all you need is a SSH server with a single git account/login that you are able to connect to using one of your public keys. Install gitolite using SSH (copies gitloite from your client to the server & does the basic setup) and have your developers send you their public keys. Add these keys to the gitolite-admin repository in your ~ and push.
Why does a developer need more than one keypair in the first place, even if multiple machines are used? Such cases will neither influence how SSH handles authentication nor how gitolite handles authorization: they're still SSH keys.
If a developer has to use several keypairs (one for git, another for some other server), let them handle the complexity and advise them to create an entry in ~/.ssh/config for each keypair/server combination they use.
If a developer has a different keypair on every machine used, gitolite groups can combine several public keys:
#agross = agross-1 agross-2
A couple of pointers:
The section about git on the server on Scott Chacon's pro git book
Gitorious is FOSS
I maintain a gitosis config at work, and when a developer has multiple ssh keys, all I have to do is put all these keys in the same keydir/user.pub file.
So concatenate all your keys into keydir/benny.pub and you shoud be all set.
There are a few open source git hosting solutions with a web-based UI for creating repositories and adding users (like GitHub:FI)... though I don't know about restricting access:
Gitorious (Ruby)
InDefero (PHP)
Girocco (Perl, shell scripts)
HTH
i am using debian with every developer having an account on the server. i use ssh with private key login. Finally a developer has to use a url like ssh://username#example.com/git-repo/repo.git to checkout or in any case interact with git on repo
I think the problem is that you ssh client (windows or linux version) is not finding the key file. I had the same problem and solved this way:
In my notebook, generated the key file (rafael.nicoletti#mycorporation) in ~/.ssh folder (where ~ is home folder. windows version is %HOME% env)
I added a file name config in ~/.ssh with following content:
IdentityFile ~/.ssh/rafael.nicoletti#corporation
In every location i want to access my git servers, i just copy those files in my %HOME% folder
You can also put the some things like this in config file:
IdentityFile /d/identity.key
IdentityFile /e/identity.key
IdentityFile /f/identity.key
IdentityFile /.../identity.key
So the config will look for keys in removable medias.