HPE GreenLake Administration
- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - Linux
- >
- Re: Question about monitoring
Operating System - Linux
1826396
Members
3731
Online
109692
Solutions
Forums
Categories
Company
Local Language
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-06-2002 12:29 AM
02-06-2002 12:29 AM
Question about monitoring
Hi all,
I have a problem with an application, which runs on unix-server. The front-end is used by a windows client, who connects with rexec. Now there is something wrong with login: A user who is known in the password list, and who is able to login in unix, cannot login with the client via rexec. I thin in the login procedure of the clientsoftware it looks in a file with further login information specific from the server application.
How can I monitor, which files will be asked or searched while logging in with the clientsoftware?
Thanks for all help!!
Best regards
Daniel :-)
I have a problem with an application, which runs on unix-server. The front-end is used by a windows client, who connects with rexec. Now there is something wrong with login: A user who is known in the password list, and who is able to login in unix, cannot login with the client via rexec. I thin in the login procedure of the clientsoftware it looks in a file with further login information specific from the server application.
How can I monitor, which files will be asked or searched while logging in with the clientsoftware?
Thanks for all help!!
Best regards
Daniel :-)
2 REPLIES 2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-07-2002 06:15 AM
02-07-2002 06:15 AM
Re: Question about monitoring
With rexec you need to open the /etc/services file for exec.
As for watching a process to determine what files it has open, use "lsof".
live free or die
harry
As for watching a process to determine what files it has open, use "lsof".
live free or die
harry
Live Free or Die
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-08-2002 02:22 PM
02-08-2002 02:22 PM
Re: Question about monitoring
Hello,
I did the test, and found significant difference between REXEC.EXE and RSH.EXE.
My NT box is named "kikik83", the Linux machine is "babasse".
My login on NT is "agbenu", while on Linux it is "kodjo".
On Linux, the .rhosts file in my home directory (/home/kodjo) contains only the following line :
kikik83 agbenu
Then from the NT box, I did the following tests :
-> With "REXEC.EXE babasse ls", it asks for username (kodjo) and password (Linux one). Then it succeeds if I type the Linux user/pass.
-> With "REXEC.EXE babasse -l kodjo ls", it only asks for the Linux password, then succeeds.
-> With "RSH.EXE babasse ls", it doesn't ask for anything, but fails with "Permission denied.". I guess the username automatically submitted by RSH.EXE is not the right one (agbenu instead of kodjo).
-> With "RSH.EXE babasse -l kodjo ls", it succeeds without asking for username or password.
Therefore, my conclusion is :
* REXEC.EXE should be reserved for interactive tasks, where the username and password can be typed on demand.
* RSH.EXE is better for batch, but anybody on the network could just use your NT hostname/IP and type "-l your_linux_login_name" to get access to your Linux account. It is a security hole !
Good luck.
Kodjo
I did the test, and found significant difference between REXEC.EXE and RSH.EXE.
My NT box is named "kikik83", the Linux machine is "babasse".
My login on NT is "agbenu", while on Linux it is "kodjo".
On Linux, the .rhosts file in my home directory (/home/kodjo) contains only the following line :
kikik83 agbenu
Then from the NT box, I did the following tests :
-> With "REXEC.EXE babasse ls", it asks for username (kodjo) and password (Linux one). Then it succeeds if I type the Linux user/pass.
-> With "REXEC.EXE babasse -l kodjo ls", it only asks for the Linux password, then succeeds.
-> With "RSH.EXE babasse ls", it doesn't ask for anything, but fails with "Permission denied.". I guess the username automatically submitted by RSH.EXE is not the right one (agbenu instead of kodjo).
-> With "RSH.EXE babasse -l kodjo ls", it succeeds without asking for username or password.
Therefore, my conclusion is :
* REXEC.EXE should be reserved for interactive tasks, where the username and password can be typed on demand.
* RSH.EXE is better for batch, but anybody on the network could just use your NT hostname/IP and type "-l your_linux_login_name" to get access to your Linux account. It is a security hole !
Good luck.
Kodjo
Learn and explain...
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
Company
Support
Events and news
Customer resources
© Copyright 2025 Hewlett Packard Enterprise Development LP