Remote Administration With SSH
- Create a RedHat VM and Ubuntu VM (free tier enabled)
- Login into the vm using ssh command
- with password:
- with pem file:
ssh -i <path to pem> <username>@<ipaddress>
Enabling Password Based Authentication for EC2 instances or any other linux instance
- By default, AWS ec2 instances donâ€™t have password authentication. You have to use the private key to connect to the instances. However, you might have situations to use password-based authentication for your AWS ec2 instances.
- Login to AWS instances
ssh -i <path to pem> <username>@<ipaddress>
- Setup a password for the user using passwd command along with the username
sudo passwd <username>
sudo vi /etc/ssh/sshd_config
- Find the Line containing ‘PasswordAuthentication’ parameter and change its value from ‘no’ to ‘yes’
- After this changes save file and exit.
service sshd restart
- Now logout and login with password
- Do this for both the machines (RedHat and Ubuntu)
Generating and using key pairs with ssh-keygen
- Passwords are great, but they’re also terrible.
- Here’s where keys come in.
- SSH keys are based on the concept of public key cryptography. They come in two parts: a public half, and a private half, the public part of which you can place onto servers, and the private part of which you keep about your person, either on your laptop, or maybe a secure USB stick (one that is itself encrypted and password protected).
- Despite the obvious suggestion of public and private half, I have frequently seen people misunderstand this concept and share their private half instead of the public one. This generally results in the key being labelled as compromised, and the individual in question being asked to generate a new pair, with a short chat about the definition of private and public in the meantime.
- Once your public half of a key is on your server, you can SSH to your remote host using the local, private half of your key for authentication.
SSH keys can even offer a degree of ease, as most operating systems come with a keychain of some sort that can be automatically unlocked on user-login, and which has the private parts of your key safely stored. SSH’ing to a machine then becomes a trivial affair where you can securely connect without being prompted at all!
To begin, ensure that you have two VMs configured with a private network between each. (In Azure if you create two vms in a same resource group & region they are by default in same network. The default ec2 instances created with in a region are in same network)
- Login into the ubuntu vm and execute
ip a and make a note of ip address from the
eth0 or en0 device
- Use the command
- We’re going to generate a more traditional Rivest-Shamir-Adleman (RSA) key
- Now execute the command
ssh-keygen -b 4096 -C "Example RSA Key" on the ubuntu machine and click enter key till the end of command
- Now navigate to ~/.ssh and check the id_rsa & id_rsa.pub files created.
- id_rsa is the private key
- id_rsa.pub is the public key
- Now since we have keys generated, Let try to understand some of the use cases of these keys
- To login into other nodes by copying the public
- use this key as a authentication into version control systems like git
- Now from the ubuntu vm execute the following command
- Now try to login by executing
- You should be able to login
The authorized_keys file
- When you connect to your remote host, SSH validates the key ID you’re providing against a list of authorized_keys.
- In our example, we used the ssh-copy-id command to place our key on the remote server. What this actually does is put it in a specific file of the home user you’re connecting to i.e. the redhat vm
On our redhat vm host, we can find this file in the user’s home directory, under .ssh
ls -al ~/.ssh
Now view the contents
- SSH is sensitive about the permissions that its files have.
- You don’t want your private key to be readable by any random user who might be on your system, so as a result, plain SSH won’t work if it thinks you have bad permissions set.
- Generally, this won’t be an issue if you’ve just generated your keys, but if you later move them between computers, you might find that you’ve spoiled the permissions slightly.
- A good rule of thumb is to assume locked-down settings:
[email@example.com ~]$ ls -lha .ssh/
drwx------. 2 ec2-user ec2-user 134 Apr 8 14:05 .
drwx------. 3 ec2-user ec2-user 95 Apr 8 10:29 ..
-rw-------. 1 ec2-user ec2-user 389 Apr 7 16:40 authorized_keys
-rw-------. 1 ec2-user ec2-user 3.3K Apr 8 11:15 id_rsa
-rw-r--r--. 1 ec2-user ec2-user 741 Apr 7 16:43 id_rsa.pub
-rw-r--r--. 1 ec2-user ec2-user 535 Apr 8 11:39 known_hosts
- The public halves of the keys (*.pub) have the value 644 (read/write, read, read)
- The private halved of the keys have the value 600 (read/write, none, none)
-rw-------. It is generally recommended for the private keys shared to others systems to have 400 (read, none,none)
To passphrase or not to passphrase
- While you can generate a key without a passphrase, and there are valid use cases for doing so (for example, in the case of automated deployments), it is considered a best practice to generate your own key with a passphrase.
- This does mean that if your key isn’t unlocked in your keychain (which itself might be unlocked when you log into your machine), you will be prompted for the passphrase to unlock the key. You might consider this a hassle, but think of it in terms of the security onion (multiple layers of security… it’s not a great analogy, unless security makes you cry.) If you lost your private key, the malicious person that picks it up won’t be able to use it to access your stuff.