Someone could be eavesdropping on you right now (man-in-the-middle attack)! – It is SSH thing

 


user1@host1: ssh user1@host2

 

How many of you noticed  below warning message during your attempt to connect remote hosts using SSH

” Someone could be eavesdropping on you right now (man-in-the-middle attack)! “

If you are the one wondering the meaning of this warning, you should go through this post  and understand Solaris Secure Shell.

We all know Secure Shell ( known as SSH) as a remote connectivity program to securely log into a remote machine and execute commands. SSH is a replacement for unsecured remote connectivity utilities like ( telnet, rlogin , rsh ..etc), it basically encrypts the data at source host before initiating the communication between to remote hosts and then decrypt the data back to original form at the destination end.

Solaris Secure Shell is a Oracle Supported version of SSH derived from OpenSSH, and is fully integrated with solaris 9 and later versions ( not available in Solaris 8 and earlier versions).

 

Below are the components of  Solaris Secure Shell, and normally resides in /usr/bin or /usr/lib. And the installation packages ( * SUNWsshcu * SUNWsshr * SUNWsshu * SUNWsshdr ) are available in Solaris Installation media.

  • ssh –  secure replacement for telnet and rlogin
  • sftp –  secure replacement for ftp (client)
  • sftp-server –  secure replacement for ftp (server)
  • scp –  secure replacement for rcp
  • sshd –  secure shell daemon (found in /usr/lib)
  • ssh-keygen –  authentication key generation
  • ssh-agent – authentication agent

Solaris Secure Shell is Compatible with other Secure shells which follows the SSH1 or SSH2 protocols, and Solaris Secure Shell disables SSH1 protocol by default. And below are the some differences that you notice from Solaris Secure shell when compared OpenSSH

Auditing ~ Basic Security Module (BSM) auditing user audit mask and audit id are setup in the kernel for each session. Login/logout records are written for each sessions if the session is a subsystem or command its name and arguments are included in the login record. Also, Oracle donated BSM code to OpenSSH.

  • Proxy Commands – Unlike OpenSSH, which provides hooks, Solaris provides two proxy commands, s5-proxy-connect and ssh-http-proxy-connect. OpenSSH has the facility to use an external command to make the connection. This keeps code like SOCKS out of the main distribution and provides the flexibility for sites to have custom firewall proxies.
  • Login Flexibility – Configurable login attempts in Solaris Secure Shell allows users to set “MaxAuthTries” and ” MaxAuthTriesLog” via the /etc/ssh/sshd_config file. These values are hard-coded in OpenSSH until the relase vertion 5.1
  • TCP Wrappers – OpenSSH includes support for sshd to call libwrap for TCP Wrappers. The Solaris Secure Shell is linked against /usr/sfw/lib/libwrap.so. Meaning,wrappers are pre-compiled and ready to go in Solaris 9 and later.
  • Ssh-keygen –  /usr/bin/ssh-keygen in Solaris Secure Shell, by default, creates an RSA key. The current OpenSSH (as of this FAQ writing) has no default.
  • General – The configuration for sshd disables many features by default (port forwarding, X11 forwarding). Changes to /etc/ssh/sshd_config may be necessary to use these features.

if you want to configure X11 users to use the secure shell by default you can configure the file ” /etc/dt/config/Xservers” to add the ‘-nolisten tcp’ option. Please remember you have to preserve this file with a backup copy  incase if you are going for any patching and upgrade.

Usage of Solaris Secure Shell is fairly simple and Same as regular ssh. And below command is an example to connect from the host “gurkulindia-host1” to “gurkulindia-host2” as a user “ramdev”

Gurkulindia-Host1$ /usr/bin/ssh ramdev@gurkulindia-host2

or

Gurkulindia-Host1$ /usr/bin/ssh -l ramdev gurkulindia-host2


Example warning/error messages

1. Error ‘Local: Bad packet length 1349676916’

It is an error message you notice when you are trying to connect from prior solaris-9 versions/non-solaris os versions, which are using SSH1 protocol , to connect to the Secure Shell Server. And the reason is Solaris Secure Shell by default disable the security vulnerable SSH1 protocol.

To fix this you can create RSA-1 key using /usr/bin/ssh-kygen and add a Hostkey entry to /etc/ssh/sshd_config. And also enable SSH1 protocol from /etc/ssh/sshd_config file

2. Warning “Someone could be eavesdropping on you right now (man-in-the-middle attack)!”

Warning indicates that the authentication key you setup on your local machine no longer matches the key presented by the remote host to which you are trying to connect. And normally it happens when you delete your key and reconfigure your SSH package but if you think that this is suspicious activity you should go raising security alarm and investigate further.

Anyway, the warning wont stop you to connect remote host, if you just accept the remote host’s current key and proceed.


Basic Troubleshooting for Solaris Secure Shell

From Client Host:   Just use -v option from client side while initiating connect to remote host, – v enables verbose mode output for entire secure shell’s client side connection

#/usr/bin/ssh -v

From Target Remote host: Enable sshd debugger by starting sshd service with -d option.

# /usr/lib/ssh/sshd -d

Configuration of SSH for Public Key (or Password less ) authentication

user1@host1 $ ssh user1@host2

To configure SSH Public Key authentication for a specific user between two hosts, you need to perform below operations on each node.

$ cd $HOME
$ mkdir .ssh
$ chmod 700 .ssh
$ cd .ssh
$ ssh-keygen -t rsa

Now accept the default location for the key file
Enter and confirm a passphrase. (you can also press enter twice).

$ ssh-keygen -t dsa

Now accept the default location for the key file
Enter and confirm a passphrase. (you can also press enter twice).

$ cat *.pub >> authorized_keys.<nodename>  (nodename is could be your hostname to differentiate this file from other node’s files, later)

Now do the same steps on the second node.

When all those steps are done on the both the hosts, start to copy the authorized_keys.<nodename> from each host to the otherhost’s  $HOME/.ssh/ directory ( $HOME indicated user’s home directory).

Then on EACH node continue the configuration of SSH by doing the following:

$ cd $HOME/.ssh
$ cat *.node* >> authorized_keys
$ chmod 600 authorized_keys

NOTE: Public keys related to both host must appear in authorized_keys files on both hosts,  INCLUDING the LOCAL public key for each node.

To test that everything is working correct now execute the commands

From Host1 run

$ ssh <Remotehost> date

The first time you will be asked to add the node to a file called ‘known_hosts‘ this is correct and answer the question with ‘yes’. After that when correctly configured you must be able to get the date returned and you will not be prompted for a password.

Note: the above will work if during RSA and DSA configuration no password was provided. If you provide a password then you need to do 2 addition steps.

$ exec /usr/bin/ssh-agent $SHELL
$ /usr/bin/ssh-add

These statements will inform the ssh agent to add the keys to the shell used. So when a new shell is started you need to repeat the last to statements to make sure ssh is working properly.

Note : ssh will not allow passwordless access if permissions on the home directory of the account you are using  allow write access for everyone.

Note: You will also see permission denied error when the permissions on $HOME are 777 or 775.


Troubleshooting Procedure to investigate failed SSH  with Public Authentication:

Client Host ( Host initiating SSH command to Remote Host) side

a.      Check the file content and size for  $HOME/.ssh/id_dsa.pub, for any recent changes or manual modifications

b.      Check the existence of  $HOME/.ssh/id_dsa

c.       Run the command with “ssh –v user@servername”

Server Host ( Host responding to SSH connection from Client Host) Side

a.      Check the file existence of $HOME/.ssh/authorized_keys2

b.      Confirm that the source user’s ( from the client side) public key contents were added to $HOME/.ssh/authorized_keys2

c.       Check the owner ship/permissions of the $HOME ( should be owned by user and readable by others),  $HOME/.ssh directory ( Should be owned by user  and have 755 permissions)   and authorized_keys2 ( Should be 755 permissions).

d.      Search for failed log entries for the related to ssh session from /var/log/authlog,  if syslog.conf enabled with the authlog entries.

# grep <username> /var/log/authlog

PS: If you like the POST, just express it to Ramdev .. he will be happy like a kid received his candy.  :)

Ramdev

Ramdev

I have started unixadminschool.com ( aka gurkulindia.com) in 2009 as my own personal reference blog, and later sometime i have realized that my leanings might be helpful for other unixadmins if I manage my knowledge-base in more user friendly format. And the result is today's' unixadminschool.com. You can connect me at - https://www.linkedin.com/in/unixadminschool/

You may also like...

6 Responses

  1. santhosh says:

    Hi Ramdev,

    Thanks for your post..i can brush up my skills..

  2. Manisekaran says:

    Hi Ram,
    Thanks For your effort and postings , which creates lots of ideas and skills.i am requesting to do post for single user mode troubleshooting steps using CD/DVD .

  3. bonny says:

    Hi Ram,

    Many Thanks.

  4. Michael Michael says:

    Hi Ram an good post ,well said .I have encountered few issues on SSH these ,not limted to few but many one thing adding to this post i would like to present an normal basic thumb rule for effective SSH troubleshooting ,

    1)users should be created in small leters,2)users .ssh directory in users home directory shud be neither group or world writable nd be owned by user  ,3)authorized_keys file shud be owned by user and neither group or world writable again ,and 4) primary most thing is the user account should not be locked ,make sure password is set for the user
    5)check for logs in authlog file
    .

  5. Yogesh Raheja says:

    @Michael, these 5 would be the 5 base rules for User Management also. Good Points to be noticed every time while playing with User Management.

  6. Michael Michael says:

    Yes yogesh you are right they are very helpfull with user management 

What is in your mind, about this post ? Leave a Reply

Close
  Our next learning article is ready, subscribe it in your email

What is your Learning Goal for Next Six Months ? Talk to us