Linux Server – hci user .profile causing ssh error

[Dock Hutson]

We recently upgraded to v6.1 with a fresh install on a new Linux server.  I didn’t realize it immediately, but when I try to SFTP or SSH to the server I get an error stating “Received message too long 167772160”.

After some research, I found that this is caused by the login process returning feedback lines as if it were an interactive login.  This only happens for the hci user, so I’m guessing it is in the .profile for that user.  I checked by logging in as that user and found two empy lines are returned every time that user logs in.  Has anyone else had this issue or know how to get around running the .profile script when connecting via FileZilla, SFTP, or SSH commands?

Here are the contents of the file:

[root@rhifclt2 hci]# more .profile

#######################################################################

#

# Infor Cloverleaf provided .profile

#

# Copyright (c) 2014, Infor.  All Rights Reserved. http://www.infor.com

#

# .profile is the startup file for use with sh and ksh shells

# This file is read in after /etc/profile and /etc/environment.

# (However, this behavior is platform dependent; check your system ksh

# man page or other documentation for exact details.)

#

# This file is used to set up a per-user login environment.  Since this

# .profile is in the hci user’s home directory, it is used to set up the

# environment for the hci user.

#

# This file is often replaced during Cloverleaf upgrades to make

# necessary changes to the user environment.  THEREFORE, DO NOT MODIFY

# THIS FILE DIRECTLY.

#

# Should you need to change the behavior of this .profile, it is recommended

# that you you create either a .profile.local.start or a

# .profile.local.end file.  These files will be sourced (or included)

# when this .profile runs at login time.  As you might guess, the

# .profile.local.start file is sourced at the beginning of this file.

# The .profile.local.end is sourced at the end.

#

#######################################################################

# set this to the install root

#CL_INSTALL_DIR=/quovadx/qdx5.0

PATH=/usr/bin:/etc:/usr/sbin:/usr/ucb:$HOME/bin:/usr/bin/X11:/sbin:.:/usr/local/bin:/usr/local/scripts:${CL_INSTA

LL_DIR}/integrator/sbin

export PATH

if [ -r .profile.local.start ] ; then . .profile.local.start ; fi

umask 002

if [ -s “$MAIL” ]           # This is at Shell startup.  In normal

then echo “$MAILMSG”        # operation, the Shell checks

fi                          # periodically.

# SHXMON* only needed for 2.1

export SHXMON_INTERVAL=5

if [ -x /bin/uname ]; then

   if [ `/bin/uname` = “Linux” ]; then

       export PATH=$PATH:/bin

       FPATH=${CL_INSTALL_DIR}/integrator/kshlib; export FPATH

       . $FPATH/setroot

       . $FPATH/setsite

   fi

fi

# Use this line to get the machine’s default root.

setroot

# Use this line to get a 2.1 (i.e., HCI-LINK) root (if installed)

# setroot /hci/hciRel_v2.1

#

# Modify this line to get a 3.0 (i.e., Cloverleaf) root

# setroot /hci/root3.0.xP

if [ “`tty`” = “/dev/hft/0” ]; then

   # Initialize X environment at system console

   export DISPLAY=unix:0.0

   open xinit

elif [ “`tty`” = “/dev/lft0” ]; then

   # Initialize X environment at AIX4.x system console

   export DISPLAY=unix:0.0

   xinit

elif [ -n “$XSTATION” ]; then

   # Initialize X environment on XStation

   truncx=`echo ${XSTATION} | sed “s/:0//”`

   DISPLAY=${truncx}:0.0

   export DISPLAY

   startx &

fi

if [ -r .profile.local.end ] ; then . .profile.local.end ; fi

export AWT_TOOLKIT=MToolkit

#######################################################################

Topic

[Keith McLeod]

You might try setting your CL_INSTALL_DIR to the correct path and uncommenting it….  I don’t recall what I did exactly, but I don’t recall that specific error.

[Dock Hutson]

I was able to resolve my issue by commenting out the following three lines in .profile:

if [ -s “$MAIL” ]           # This is at Shell startup.  In normal

then echo “$MAILMSG”        # operation, the Shell checks

fi                          # periodically.

They were causing feedback to the login process which stopped any SSH processes from working.

[Author]

Replies