Tracking source IP addresses Sftp clients are connecting from

We used sftp with password authentication & I'm suspecting that
our sftp password is being shared with users who are connecting
from IP addresses that we can track down.

Q1:
As I'm newbie to Redhat Linux (5.x, 6.x) , can name me the logfile names
 (Linux syslogs?  Sftp logs?) & the directories of the logs  that will show the
 source IP addresses that the sftp clients are connecting from?

Q2:
I was told by the Linux sysadmin that the sftp logs are encrypted.
Any idea which freeware sftp server auto-encrypts its sftp logs?
The sysadmin chap can't comment.

Q3:
Is there any Linux command, say "last" that will indicate the source
IP addresses that sftp clients connect from & the date/timings they
connect?  Let me know the qualifiers if any (for Redhat 5.x/6.x)
sunhuxAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

arnoldCommented:
if you know the IPs from which your users should be coming from, you could use tcpwrapper rules

hosts.allow
sshd:internalIPSegment
sshd:authorized_remotelocations
hosts.deny
sshd:all

note sftp is part of SSL.  not sure there is a specific SFTP. Once you add the sshd:all in the hosts.deny, only connections matching the hosts.allow entries will be permitted to connect.  Do not try these changes offsite (just in case there is a typo that will lock you completely out). A way to manage might be to setup another instance of sshd that will be bound and listening on a different port accessible only internally.  note however that the tcpwrapper (hosts.allow, hosts.deny) will apply to it unless you compile your own sshd version that would not include tcpwrapper libraries.)

if your sshd_config configured to log events, look there/ you can parse the log to extract the usernames and the connection source.

Those sftp users can then ssh into your system?

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Dave BaldwinFixer of ProblemsCommented:
SFTP is Not part of SSL, it is part of SSH which is a completely different encryption method.
sunhuxAuthor Commented:
Thanks richrumble.

hosts.allow
sshd:internalIPSegment
sshd:authorized_remotelocations
hosts.deny
sshd:all
I can't implement the suggestion of blocking because the users
are given their own ssh id to do sftp but somehow we suspect
a sysadmin has inadvertently shared an sftp admin password
with the users.  Is there any configuration in sftp to permit
based on a combination of ssh userid & IP address they're
connecting from?
Why Diversity in Tech Matters

Kesha Williams, certified professional and software developer, explores the imbalance of diversity in the world of technology -- especially when it comes to hiring women. She showcases ways she's making a difference through the Colors of STEM program.

sunhuxAuthor Commented:
Suppose users' subnet is from 172.16.12.0, can
I put the following commands into the .bash_profile
 or the .profile of that sftp admin id :

who am i | grep -i "172.16.12."
if [ test $? -eq 0 ]
then
        exit
fi

Pls comment/review if the 'exit' statement is sufficient
to logout the unauthorized user's sftp session.
sunhuxAuthor Commented:
or do we need "exit 1" or "kill ..." command?


Correction:
> if [ test $? -eq 0 ]
   should be
if [ $? -eq 0 ]
sunhuxAuthor Commented:
agree, Dave is right, sftp is an ssh protocol ; it's not ssl
Dave HoweSoftware and Hardware EngineerCommented:
sftp logins are ssh logins - they should be in the usual /var/log/messages (or whatever the syslog target is) with login successes and fails logged
arnoldCommented:
Yes, typo'd.


There is an SSHD rule that you can add to sshd_config
The line is
AllowUsers username@ipaddress
The above example will restrict user login attempts to the ipaddress.
AllowUsers username@192.168.0.?
the above line will restrict the username to the 192.168.0/24 segment
http://ubuntuforums.org/showthread.php?t=1416730

You should test whether it will take a CIDR notation 192.168.0.0/24 or 192.168.0. might work as well.

note for these changes to take effect, the sshd daemon needs to be restarted.
sunhuxAuthor Commented:
Would those lines of Shell commands placed into .profile or
.bash_profile work?
arnoldCommented:
A while back there was/were options that you can add into authorized_keys, that would limit the source of the connection using public keys.
I do not believe outside the main service configuration (sshd_config) that there is a way to restrict the user login.

The issue is when someone sftps I do not .profile, .bash_profile is processed.


Another issue is that .login/.bash_profile might be terminated by the user hitting ctrl-c.

The change will only would with ssh logins, you can "replace" the shell with a wrapper script that will test for the ssh client information and then validate the IP against a rule (applicable to all or you need to check which user is running it), and then either pass the connection to the shell or exit.

You seem to be in search of a workaround, there is the direct way.
Advise your fellow admins, change the password on the account.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Linux Security

From novice to tech pro — start learning today.