double-quote,single-quote,back-tik,back-slash in shell

double-quote("):
Removes special meaning of    '  ,  <  ,  >  ,  #  ,  *  ,  ?  ,  &  , |  , ; , ( , ) , [ , ]  , ^  ,  blank spaces  ,  newlines      and tabs
and $ , `  ,  and \ are interpreted.


single-quote('):

Removes the special meaning same as " but also the special meaning of  $ , `  ,  and \

back-slash(\):

removes the special meaning of charater following ;
inside double quotes - it removes the special meaning of
$ . " , ` , and \


back-tik(`):

causes output command to be executed and output to be inserted at that point.

Protocol 1 and Protocol 2 in SSH

Protocol 1:

In this case ,when the daemon starts,it starts  generating RSA keys also known as Server keys every hour.This key is not stored anywhere.The no of bits in the server keys is determined by the  ServerKeyBits configuration in the sshd_config.


when client tries connecting to the daemon,the server responds with the 
1)Host Key
2)Server Key


Then the client verifies the server key with its own database whether it has changed.If this is the first time the client is trying to connect to the host,it adds to the /etc/ssh/known_hosts after confirmation from the user.




For setting up a secured session between the client and server, the client generates a 256 random number which it encrypt using both the host key and server key and sent to the daemon(server).


This 256 random number is decrypted by the server and used as a session key for communication between the two.

For this protocol ,cipher config is used in /etc/ssh/ssh_config
In this cipher required for the session to setup can be given.


Protocol 2 in SSH:


In this case the main difference is Server Key is not generated.


In this session key for forward security is generated through a Diffie-Hellman key agreement.This agreement results in a shared session key.


For the rest of the session,the symmetric cipher is aes128-cbc,blowfish,3des etc.. anything the client chooses as the encryption algorithm from the list of encryption algorithms supported by the client.


The list of encryption algorithm supported by the daemon can be known from 
Ciphers configuration  in /etc/ssh/sshd_config.


The client can select the needed cipher from the list of supported ciphers of the server by changing the configuration against the ciphers in /etc/ssh/ssh_config.The ciphers are selected by the client in the order of preference as in /etc/ssh/ssh_config.

SSH Authentication in Linux

SSH is considered to be a secure way of login into a remote machine.

In this case there are three ways of authenticating through ssh before logging into a remote machine.

1)Host key authentication

2)Public Key Authentication

3)Public Key Authentication without authentication

1)Host Key Authentication:

In this case,username and password is used to authenticate to login to a remote shell.

Here SSH keys(Host keys)  are used to encrypt the session.
In this type of authentication, host keys are alone used ,which is used to assure the system you are logging is what it claims to be.

These host keys are directly added to your known_hosts in your local home(~/.ssh/known_hosts)

the first time you login to a remote system,though it will ask for confirmation whether the remote shell host key can be added to the known_hosts and it will display RSA finger print of the remote shell.

In case of security concerns,this host key can also added manually by using ssshkeygen to generate the keys.These keys generated can also be added  to the ~/.ssh/known_hosts of each of the remote system which you think need to login to your local system.

2)Public Key authentication:

In this case,SSH identity keys are used to authenticate the users instead of system Login.

Here the identity keys authenticate the users  instead of host key used in previous case.

But in this case,you need to do a little more work ,

you have to create public/private pair using the ssh key-gen using the following step: 

ssh-keygen -t rsa

this will generate the rsa key pair
private key will be stored in your  ~/.ssh/id_rsa
public key will be stored in the ~/.ssh/id_rsa.pub
Please provide the paraphrase to secure your private key

Keep your private key securely and the public key can be sent to other remote systems which you think has to login to your local system.

The public key should  be sent into ~/.ssh/authorized_keys2 files in the remote login
.This copying can also be done using ssh-copy-id utility like

This authorized_keys2 file is the default if you want to change the name you need to change it in the /etc/ssh/sshd.conf

ssh-copy-id  -i   id_rsa.pub karthik@10.10.10.10
(this command also creates the file authorized_keys2 in the remote system)

or just copy.


So in this case the data is encrypted by the public key in the  remote system and it is decrypted by the private key saved in your local system..Though the data can be encrypted by anyone having the public-key it can be decrypted only by a person possessing the private key.
Chances of data spoofing is completely reduced as long as private key is secure.As we have also used paraphrase along with the private key ,the spoofer cannot acheive his target only with the private key.


3)Public Key Authentication without using paraphrase:

In this case it is same as Public Key Authentication.But in this case we don't provide paraphrase to protect the private key.

SFTP over FTP

SFTP when compared with FTP is more a secure way of sending your valuable data in a encrypted form.

In case of ftp, there are chances of others spoofing your data But in case of sftp it is totally avoided.

Sftp supports password authenication and publickey authentication.

HOW TO USE FTP

Just put ftp [ IP-addressess or host-name ]

for example:
ftp 10.10.10.10

Once it is a valid IP-address ,it will ask for username and password for that particular IP-address.

Once it is authenticated ,it will return  User logged in and a  ftp> prompt

If the IP address is not valid ,it will return  User not logged in

Once you are logged in
you either
1)get
2)put

get:
you can either get a file from any location in logged IP by using cd command to move into the particular directory.But in this case file can be copied into current directory where you tried for ftp.

ftp>cd /karthik
ftp> ls
df  fg   gg  dd  ff
ftp>get df


put:
but to put  a file you can transfer it only from the current directory of your local IP where you tried for ftp.
Nevertheless the file can be copied to any location in the remote IP

ftp>cd /karthik
ftp> put sample.txt
ftp>ls
sample.txt  df  fg  gg  dd  ff

To use it for a entire directory you can use mget and mput in the place of  get and put.

in case of mget it will ask for confirmation for each file

To avoid that you can use:

ftp -i  ip-address

this switches off the interactive mode

usage of bless function in perl

There are many chances that you may get confused with Perl Object Programming

To make the point clear let us first look at references at Perl

@friends = ("Rachael","Phoebs");
%animals = ('donald' => 'duck','mickey' => 'mouse' );


To intiaize  references to a variable use:
In case of array:
$ref  = \@friends
In case of hashes
ref = \%animals;
In case of sub-routine:
$ref=\&whoami;

Print ref ;   ---> to see refernce value

To access elements through references

print $$ref[0]  - it prints Rachael
print  $$ref{ 'mickey'}   - > it prints mouse


Having a basic idea of reference  will help you to use object oriented programming.

In perl ,object is a reference that belongs to a specific package.


method - used to associate a reference with a specific package is referred as "blessing"

constructor is merely a sub-routine that returns a reference to something blessed into a class.


To invoke the constructor in perl you can use:

$bob = Easterbunny::new();
$bob = new Easterbunny;
$bob=Easterbunny - > new();

bless function is used to change the datatype of the anonymous hash to $class.

An anonymous hash is used to hold the properties of the classs.

some key items to remember:
1)All objects are anonymous hashes which not strictly true,perhaps it should be.
2)bless function changes the data type of the anonymous hashes.
3)objects can belong to only one class at a time.
5)the -> operator is  used to call a method.


to demonstrate the bless function changes the datatype of the class:

#!/usr/bin/perl
$foo = {};
$fooref = \$ref;
print (" datatype of \$foo is " .ref($foo) . "\n");   ---> Hash here
bless ($foo,"Bar"); 
print ("datatype of \$foo is " ref($foo) ."\n");  ---->Bar here after blessing with the Bar class

output :

datatype of $foo is Hash
datatype of $foo is  Bar

setting IPsec in Linux

IPsec  - is a network level protocol for strong pervasive Security.It can provide privacy and block variety of threats.

First decide the remote host and local host between which IPsec has to be enabled.

There are two types of authentication headers in IPsec

1)Authentication Header
2)Encryption Header

For both types key has to be generated to enable IPsec

For AH you can use 64 bit key
For EH  you can use 96 bit key

You have to declare both SA(security association) and SP(Security Policy) to effectively establish a IPsec.

SA - to define the security needed to be associated between the IPs.

SP  - to define when the SA is to be used
TO define SA:

1)add localIP  remoteIP ah 15700 -A hmac-md5 "123456701234"

ah                            -to indicate it is defined for authentication header
15700                     - Security Index
-A                           - authentication
hmac-md5               - authentication algorithm
"123456701234"    -AH key

2)add localIP  remoteIP esp  12222 -E  desc-cbc   "23123234324324324234234"

esp            -to indicate it is defined for authentication header

12222       -Security Index

-E             -encryption

3dec-cbc  - encryption algoritm

"23123234324324324234234"   -  esp Key

you can also define both together

  

1& 2 together ) add localIP  remoteIP esp  12222  -E  desc-cbc   "23123234324324324234234" -A hmac-md5 "123456701234"

This combined format worked better for me compared to defining separately for both
ah and esp.

This also has to be done for the reverse direction like
add remoteIP localIP  ah 15700 -A hmac-md5 "123456701234" likewise for all the three formats.

To setup the SA you have to copy the add commands into a file like

>cat ff
add 10.1.1.1 12.1.1.1 esp  12222  -E  desc-cbc   "23123234324324324234234" -A hmac-md5 "123456701234"
add 12.1.1.1 10.1.1.1 esp  12222  -E  desc-cbc   "23123234324324324234234" -A hmac-md5 "123456701234"
and then run
>setkey -f ff
AND it has to return no errors.
If so ,you can confirm a IPsec security association has been setup.

To display the setup SA(Security  Association) setup  you can use the command

setkey -D
IF a SA is setup it will show the details
else it will display  "NO SAD entries"

To  setup SP(security policy):

you have to use somewhat the same strategy:

you have to add these commands into a file and call setkey -f filename command

you have to add:
spdadd localip remoteip any -P out ipsec
esp/transport/require
ah/transport/require

these information say for any packet moving out of the localip esp encrypted and ah authenticated header has to be used.

likewise you can define :

spdadd remoteip localip any -P in ipsec

esp/ transport/require

ah/transport/require

these information say for any packet moving into the remoteip  esp encrypted and ah authenticated header has to be used.

Simply put these spdadd commands into a file substuting your localip and remoteip information.
And run setkey -f  filename command

Your SPD will be established.

You can view your registered SPD by typing the command


setkey -DP

if it does't  show any of the the information
you might have committed some error.Double check with spdadd and add commands.

By this have you can easily setup a IPsec Connection between two IP's.

ssh keys

Keys  are of two types in ssh:

Host key- 

1)this key is used to authenticate whether the connection is coming from the intented remote host.

Identification key -
1)this key is used to authenticate the username's login when they ssh to a remote host

Key can be generated as both DSA and RSA pair
DSA is limited to 1,024 bits
RSA  can be up to 2,048 bits and can be more future proof.

/etc/sudoers

This file is mainly for adding commands for which there is no need to change to root login
In this file the commands are updated and the userlogin is also added so that user can 
directly run the command using sudo keyword(for all the commands added in this file).

 Example for how the user entry can be added:

format:
userlogin (terminal from which command can be run) = (which user he can be) commands he can run from the list in this file

example:

dhivya (ALL) = (ALL) ALL

This means the user with login Dhivya can execute from all terminals  and act as any user as said as ALL
and execute any command in the list given in the file /etc/sudoers  as said by ALL