TimeLinux1

Sunday, September 26, 2010

Linux HowTo: Secured Shell (ssh) Configuration

Earlier we had spoken about the Basics of ssh in this previous post. Today we will go a little more in depth. Ssh is quite vast and can fill a book.
Ssh is based on the public-private key cryptography that was developed to fill in the gaps left by earlier protocols like Telnet and rsh (Remote Login Shell). ssh is safe even if someone is using packet sniffer (like tcpdump). It prevents impersonation because it keeps a track of ssh clients on the ssh server.

-cryptographic basics:
    .everyone has a public key which is world accessible
    .no one has access to others private key. only the owner knows it.
    .a msg locked with joe's private key is unlocked only by joe's public  key.
    .a msg locked with joe's public  key is unlocked only by joe's private key.

-cryptography can ensure:
    . only desired recipient receives the msg
    . recipient can authenticate the id of sender.

-system wide ssh config files:
    . /etc/ssh/ssh_config        - ssh client  config file
    . /etc/ssh/sshd_config        - ssh server config file
-client config can be overriden by:
    1. command line options
    2. user config file in $HOME/.ssh/config

-by default, all users and all groups are allowed ssh access to a host.
-by default, root ssh login is allowed.
-rsa and dsa are just two algorithms for ssh cryptography.
-the foll just creates a pair of private and public key as per rsa algorithm:
    # ssh-keygen -t rsa            [ useful when wanting to ssh w/o pw ]

-To verify ssh pkgs:
    # rpm    -qa  | grep -i ssh
-To verify ssh version:
    # ssh    -V
-To start sshd:
    # service    sshd    start        or
    # /etc/rc.d/init.d/sshd  start
-Note:   
-To control services at various levels the foll are similar:
    # chkconfig --level nnn <service>   
    # ntsysv --level nnn
    # system-config-services

-Note:
-The default sshd port is 22 & it can be changed in /etc/ssh/sshd_config followed by "service sshd restart"
-To permit root to ssh, edit /etc/ssh/sshd_config as follows:
    PermitRootLogin    =    yes            [ This could be a security risk ]

-To generate ssh host key:
    # ssh-keygen    -t <type>    -f <file>        [ Type can be rsa or dsa ]
-This creates a private, public host key pair.

-The ssh host key is like a master key that is used to encrypt and decrypt ALL data to & from a host.
-This prevents 'man-in-the-middle' attacks.
-The ssh-keygen cmd creates a private-public host key pairs in the files specified by -f option.
-Lets say the cmd given was:
    # ssh-keygen    -t rsa    -f    /etc/ssh/ssh_host_key
    -/etc/ssh/ssh_host_key        -contains both private and public keys
    -/etc/ssh/ssh_host_key.pub    -contains only public key.
-The public key is used to encrypt the data &
-The private key is used to decrypt the data.
    [Mnemonic = pub-en ]
-The passphrase is used to access the private key.

-The first time a new host is ssh-ed to, its fingerprint is added into the source machines "known_hosts" file.
-The new host fingerprint can be verified by as follows:
    node1#    cat     /home/.ssh/known_host    | grep -i node2
& on     node2#    ssh-keygen -y -f /etc/ssh/ssh_host_key
The output of the two cmds above should be the same.

-sometimes the fingerprint of a remote host may get changed eg after an ip address change & in that case
an attempt to connect to the remote host is errored out. In that case, the fingerprint for the remote host needs
to be deleted in the "known_hosts" file and the ssh retried; this regenerates the fingerprint of the remote host.

-Useful cmds:
    node1# ssh-keygen    -l -f /etc/ssh/ssh_host_key        [ shows fingerprint of node 1]
    node1# ssh-keygen    -y -f /etc/ssh/ssh_host_key        [ shows host key of node 1 ]
   
    node1# ssh -p 52 user@node2        [ ssh to node2 as user at non-default port 52 ]
    node1# ssh -X user@node2             [ ssh to node2 as user and run X client on node2 ]
    nose1# ssh -vvv user@node2          [ ssh to node2 as user and run debug ]
Then review /var/log/secure & /var/log/messages.

No comments:

Post a Comment