Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: Slackware from 94-09, Debian Since March 09
Posts: 28
Rep:
It would appear that your ssh logins use a different path than your normal console logins. A quick way to test this is to run the following command in an ssh session, and in a local login:
Code:
echo $PATH
And look for differences.
If the outputs are different, here are a couple of situations where your ssh path could be impacted:
It could have been set as a default configuration option when ssh was compiled
sshd could be set to use a chroot environment in /etc/ssh/sshd_config, thus limiting your access to typical system binaries
/etc/pam.d/ssh could be configured to specify a different path configuration (if you use PAM)
If you are chrooted, then you'll need to reconfigure sshd_config appropriately, and restart the service.
If it was a path set as a default configuration option during compilation, it can be overridden by specifying it in your startup scripts. (such as ~/.profile, ~/.bashrc, or whatever your system uses)
If PAM is reconfiguring your PATH when you ssh in, it can typically be modified in the file specified above, but tread lightly. Messing around inside the PAM subsystem can get you locked out of your system if you don't know what you are doing.
There are many more possibilities, because there are a great number of details that you haven't provided... But I hope this helps a bit, and at least gets you pointed in the right direction.
Distribution: Slackware from 94-09, Debian Since March 09
Posts: 28
Rep:
If the paths are the same on both logins, and vi is found on one, but not on the other, then I suspect a chroot environment.
First, find out where vi is located on your system during a local login. The command:
Code:
which vi
should give you the path to it.
Then, login via ssh, change directory to the location of vi and see if it even exists there. (or for that matter, if the directory even exists.) Another way to test would be to specify the full path of the binary like this:
Code:
/usr/bin/vi
(that is under the presumption that the vi binary is located in /usr/bin.)
If you cannot find it while logged in via ssh, and it does exist when you log in locally, you are most likely in a chroot environment when you ssh in.
Distribution: Slackware from 94-09, Debian Since March 09
Posts: 28
Rep:
Quote:
Originally Posted by yang_wayne
login locally:
which vi
/usr/bin/vi
I can see vi
login ssh
I cannot see vi,
ls -vi
permission denied.
What does it mean "chroot environment"?
Thanks
I'm hoping you actually typed "ls /usr/bin/vi" instead of "ls -vi" like your post indicates.
The "permission denied" error indicates that the file may be there, but you don't have permission to view the directory contents as the current user.
This brings me to two questions that I should have asked in the beginning:
What user are you logging in as locally?
and...
What user are you logging in as when you ssh?
A chroot environment is a technique intended to restrict access to system files by placing the logged in user into a "new root" filesystem with a limited set of files in it.
Here is a quick description of the chroot concept.
Distribution: Slackware from 94-09, Debian Since March 09
Posts: 28
Rep:
Quote:
Originally Posted by yang_wayne
permission denied. I login both local and ssh as my account, then su to root account. How can I change it not in "chroot environment"?
thanks
Something is strange here... If you are indeed switched to the root account, then you should not be getting a "permission denied" error for a file listing.
If the file doesn't exist, it would look like this:
Code:
ls -lah /foo
ls: cannot access /foo: No such file or directory
I have a feeling we aren't getting all of the details about what is going on.
After you have switched user to root, what is the output you get from the following command:
Distribution: Slackware from 94-09, Debian Since March 09
Posts: 28
Rep:
Well, I hate to say this, but I'm at a complete loss here.
Perhaps you should present this issue over at the Novell forums and see if they can provide you with an answer. It's possible that it may be related to some sort of permissions-management system they provide with their distribution.
Sorry I couldn't be of more help than this, but I'm having difficulty following a logical path through this problem. If you have successfully become root after ssh'ing in and still have no permissions to access files on the filesystem, I've run out of tricks to try.
The only suggestion I have left is to look *very carefully* through your system logs for anything that could be related to the issue you are experiencing.
Do me a favor, and post your solution if you ever find one.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.