Howto Linux / UNIX setup SSH with DSA public key authentication (password less login)
#1 machine : your laptop called tom
#2 machine : your remote server called jerry
Command to type on your laptop/desktop (local computer)
First login to local computer called tom and type the following command.
Step #1: Generate DSA Key Pair
Use ssh-keygen command as follows:
$ ssh-keygen -t dsa
Output:
Enter file in which to save the key (/home/vivek/.ssh/id_dsa): Press [Enter] key
Enter passphrase (empty for no passphrase): myPassword
Enter same passphrase again: myPassword
Your identification has been saved in /home/vivek/.ssh/id_dsa.
Your public key has been saved in /home/vivek/.ssh/id_dsa.pub.
The key fingerprint is:
04:be:15:ca:1d:0a:1e:e2:a7:e5:de:98:4f:b1:a6:01 vivek@vivek-desktop
Caution: a) Please enter a passphrase different from your account password and confirm the same.
b) The public key is written to /home/you/.ssh/id_dsa.pub.
c) The private key is written to /home/you/.ssh/id_dsa.
d) It is important you never-ever give out your private key.
Step #2: Set directory permission
Next make sure you have correct permission on .ssh directory:
$ cd
$ chmod 755 .ssh
Step #3: Copy public key
Now copy file ~/.ssh/id_dsa.pub on Machine #1 (tom) to remote server jerry as ~/.ssh/authorized_keys:
$ scp ~/.ssh/id_dsa.pub user@jerry:.ssh/authorized_keys
Command to type on your remote server called jerry
Login to your remote server and make sure permissions are set correct:
$ chmod 600 ~/.ssh/authorized_keys
Task: How do I login from client to server with DSA key?
Use scp or ssh as follows from your local computer:
$ ssh user@jerry
$ ssh user@remote-server.com
$ scp file user@jerry:/tmp
You will still be asked for the passphrase for the DSA key file each time you connect to remote server called jerry, unless you either did not enter a passphrase when generating the DSA key pair.
Task: How do I login from client to server with DSA key but without typing a passhrase i.e. password-less login?
Type the following command at shell prompt:
$ exec /usr/bin/ssh-agent $SHELL
$ ssh-add
Output:
Enter passphrase for /home/vivek/.ssh/id_dsa: myPassword
Identity added: /home/vivek/.ssh/id_dsa (/home/vivek/.ssh/id_dsa)
Type your passhrase once. Now, you should not be prompted for a password whenever you use ssh, scp, or sftp command.
#1 machine : your laptop called tom
#2 machine : your remote server called jerry
Command to type on your laptop/desktop (local computer)
First login to local computer called tom and type the following command.
Step #1: Generate DSA Key Pair
Use ssh-keygen command as follows:
$ ssh-keygen -t dsa
Output:
Enter file in which to save the key (/home/vivek/.ssh/id_dsa): Press [Enter] key
Enter passphrase (empty for no passphrase): myPassword
Enter same passphrase again: myPassword
Your identification has been saved in /home/vivek/.ssh/id_dsa.
Your public key has been saved in /home/vivek/.ssh/id_dsa.pub.
The key fingerprint is:
04:be:15:ca:1d:0a:1e:e2:a7:e5:de:98:4f:b1:a6:01 vivek@vivek-desktop
Caution: a) Please enter a passphrase different from your account password and confirm the same.
b) The public key is written to /home/you/.ssh/id_dsa.pub.
c) The private key is written to /home/you/.ssh/id_dsa.
d) It is important you never-ever give out your private key.
Step #2: Set directory permission
Next make sure you have correct permission on .ssh directory:
$ cd
$ chmod 755 .ssh
Step #3: Copy public key
Now copy file ~/.ssh/id_dsa.pub on Machine #1 (tom) to remote server jerry as ~/.ssh/authorized_keys:
$ scp ~/.ssh/id_dsa.pub user@jerry:.ssh/authorized_keys
Command to type on your remote server called jerry
Login to your remote server and make sure permissions are set correct:
$ chmod 600 ~/.ssh/authorized_keys
Task: How do I login from client to server with DSA key?
Use scp or ssh as follows from your local computer:
$ ssh user@jerry
$ ssh user@remote-server.com
$ scp file user@jerry:/tmp
You will still be asked for the passphrase for the DSA key file each time you connect to remote server called jerry, unless you either did not enter a passphrase when generating the DSA key pair.
Task: How do I login from client to server with DSA key but without typing a passhrase i.e. password-less login?
Type the following command at shell prompt:
$ exec /usr/bin/ssh-agent $SHELL
$ ssh-add
Output:
Enter passphrase for /home/vivek/.ssh/id_dsa: myPassword
Identity added: /home/vivek/.ssh/id_dsa (/home/vivek/.ssh/id_dsa)
Type your passhrase once. Now, you should not be prompted for a password whenever you use ssh, scp, or sftp command.
OpenSSH
is tool used for connecting and managing remote linux machines. And this should
be secured. I am here by telling some security tips to make the SSH server perfect.
1.The following iptable rule will drop incoming connections which make more than 5 connection attempts upon port 22 within 60 seconds
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 5 -j DROP
2.Disable Empty Passwords
Open the file /etc/sshd/sshd_config and
PermitEmptyPasswords no
1.The following iptable rule will drop incoming connections which make more than 5 connection attempts upon port 22 within 60 seconds
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 5 -j DROP
2.Disable Empty Passwords
Open the file /etc/sshd/sshd_config and
PermitEmptyPasswords no
3.TCPWrappers
open --> vi /etc/hosts.deny
sshd:ALL
then
open --> vi /etc/hosts.allo
sshd:192.168.1.32 192.168.1.21 (Change to your desired IP)
4.Change the SSH Port
The Idea behind this , suppose we change the port 22 to something other say Oracle 1521 , the attackers thinks that this is an Oracle server and will try oracle hacking tools :)
open --> vi /etc/hosts.deny
sshd:ALL
then
open --> vi /etc/hosts.allo
sshd:192.168.1.32 192.168.1.21 (Change to your desired IP)
4.Change the SSH Port
The Idea behind this , suppose we change the port 22 to something other say Oracle 1521 , the attackers thinks that this is an Oracle server and will try oracle hacking tools :)
Port 300
5.Force Logout for Idle Sessions
ClientAliveInterval 300
ClientAliveCountMax 0
To quickly secure OpenSSH daemon, open config file located at /etc/ssh/sshd_config and make the following changes:
Protocol 2
PermitRootLogin without-password
StrictModes yes
Banner /etc/sshd_banner
LoginGraceTime 60
MaxAuthTries 3
MaxStartups 10
PermitEmptyPasswords no
PrintLastLog yes
AllowTcpForwarding no
IgnoreRhosts yes
IgnoreUserKnownHosts yes
HostbasedAuthentication no</code>
Create SSH banner, just open in a favourite text editor file /etc/sshd_banner and fit it with following contents:
This is secured SSH service. Your activities are logged and monitored.
Warning: Unauthorized access to this system is strictly prohibited.
Also, to secure access to the OpenSSH daemon it is recommended to disable the password authentication and use a public/private keys.
Below is a description of directives used to secure OpenSSH:
Protocol
This directive allows to specify the version of SSH to use. For security reasons it is strongly recommended to use only protocol 2, because the old version has several security flaws.
PermitRootLogin
Configure behaviour for the root account to eliminate security risks. The without-password argument allows root login only using public keys. The password authentication will not be allowed.
StrictModes
Tells SSH daemon to check user's permissions in their home directory and rhosts files before accepting login. For security reasons it is recommended to enable it because sometimes users may accidentally leave files or directories writable, and script-kiddies may use this to assume user's identity.
Banner
Directive tells to SSH daemon to the file that contents should be displayed before login occurs. Usually this directive is used by organizations where is required some legal verbage to be shown when host is accessed.
LoginGraceTime
This parameter tells to SSH daemon drop connection attempts if a successful connection hasn't occured in a specifed amount of seconds. I limited it to 60 seconds.
MaxAuthTries
This directive allows to avoid some brute-force attacks to the daemon by limiting failing connections attempts. By default, users who cannot remember the password, gets 3 attempts.
MaxStartups
This parameter enhance security by limiting number of unauthenticated sessions keeped alive. This also helps in combating brute-force attacks because other attempts to authenticate will not be blocked, until one of active sessions succeeds authentication or times out.
PermitEmptyPasswords
Allows or disallows empty passwords. It is recommended to disable them because usage of empty passwords is discouraged for security reasons.
PrintLastLog
This directive empowers the user to check for security by displaying the users last login time at the time of login.
AllowTcpForwarding
Controls tunneled connctions of TCP protocols over SSH (like rsync over SSH). Sometimes tunneling is a security risk because it is difficult to detect behaviour of malicious protocols or applications. Also, tunnels are usually used by script-kiddies for crossing firewalls.
IgnoreRhosts
This directive enhances security by ignoring the legacy .rhost file from users. This is a best practice, in case rsh/rlogin are enabled or could accidentally become enabled.
IgnoreUserKnownHosts
Directive is used to protect against users setting up host-based authentication. For security purposes, it is often best to change the directive to yes.
HostbasedAuthentication
Tells SSH daemon to enable or disable host-based authentication. Most security experts are extremely opposed to any form of host-based authentication and recommends to use public keys or password authentication as alternative.
5.Force Logout for Idle Sessions
ClientAliveInterval 300
ClientAliveCountMax 0
To quickly secure OpenSSH daemon, open config file located at /etc/ssh/sshd_config and make the following changes:
Protocol 2
PermitRootLogin without-password
StrictModes yes
Banner /etc/sshd_banner
LoginGraceTime 60
MaxAuthTries 3
MaxStartups 10
PermitEmptyPasswords no
PrintLastLog yes
AllowTcpForwarding no
IgnoreRhosts yes
IgnoreUserKnownHosts yes
HostbasedAuthentication no</code>
Create SSH banner, just open in a favourite text editor file /etc/sshd_banner and fit it with following contents:
This is secured SSH service. Your activities are logged and monitored.
Warning: Unauthorized access to this system is strictly prohibited.
Also, to secure access to the OpenSSH daemon it is recommended to disable the password authentication and use a public/private keys.
Below is a description of directives used to secure OpenSSH:
Protocol
This directive allows to specify the version of SSH to use. For security reasons it is strongly recommended to use only protocol 2, because the old version has several security flaws.
PermitRootLogin
Configure behaviour for the root account to eliminate security risks. The without-password argument allows root login only using public keys. The password authentication will not be allowed.
StrictModes
Tells SSH daemon to check user's permissions in their home directory and rhosts files before accepting login. For security reasons it is recommended to enable it because sometimes users may accidentally leave files or directories writable, and script-kiddies may use this to assume user's identity.
Banner
Directive tells to SSH daemon to the file that contents should be displayed before login occurs. Usually this directive is used by organizations where is required some legal verbage to be shown when host is accessed.
LoginGraceTime
This parameter tells to SSH daemon drop connection attempts if a successful connection hasn't occured in a specifed amount of seconds. I limited it to 60 seconds.
MaxAuthTries
This directive allows to avoid some brute-force attacks to the daemon by limiting failing connections attempts. By default, users who cannot remember the password, gets 3 attempts.
MaxStartups
This parameter enhance security by limiting number of unauthenticated sessions keeped alive. This also helps in combating brute-force attacks because other attempts to authenticate will not be blocked, until one of active sessions succeeds authentication or times out.
PermitEmptyPasswords
Allows or disallows empty passwords. It is recommended to disable them because usage of empty passwords is discouraged for security reasons.
PrintLastLog
This directive empowers the user to check for security by displaying the users last login time at the time of login.
AllowTcpForwarding
Controls tunneled connctions of TCP protocols over SSH (like rsync over SSH). Sometimes tunneling is a security risk because it is difficult to detect behaviour of malicious protocols or applications. Also, tunnels are usually used by script-kiddies for crossing firewalls.
IgnoreRhosts
This directive enhances security by ignoring the legacy .rhost file from users. This is a best practice, in case rsh/rlogin are enabled or could accidentally become enabled.
IgnoreUserKnownHosts
Directive is used to protect against users setting up host-based authentication. For security purposes, it is often best to change the directive to yes.
HostbasedAuthentication
Tells SSH daemon to enable or disable host-based authentication. Most security experts are extremely opposed to any form of host-based authentication and recommends to use public keys or password authentication as alternative.
No comments:
Post a Comment