LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software
User Name
Password
Linux - Software This 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


Reply
  Search this Thread
Old 03-11-2009, 12:21 PM   #1
yang_wayne
Member
 
Registered: Jan 2009
Posts: 40

Rep: Reputation: 15
vi problem


I have SLES 10, I can use vi in the server directly. But when I use putty SSH to server, I use vi,
bash: vi: command not found
What is the problem?

Thanks,

Lisa
 
Old 03-11-2009, 12:46 PM   #2
Linuxchuck
LQ Newbie
 
Registered: Aug 2007
Distribution: Slackware from 94-09, Debian Since March 09
Posts: 28

Rep: Reputation: 19
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:
  1. It could have been set as a default configuration option when ssh was compiled
  2. sshd could be set to use a chroot environment in /etc/ssh/sshd_config, thus limiting your access to typical system binaries
  3. /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.
 
Old 03-11-2009, 12:56 PM   #3
yang_wayne
Member
 
Registered: Jan 2009
Posts: 40

Original Poster
Rep: Reputation: 15
echo $PATH is the same

/home/lydiayang/bin:/usr/local/bin:/usr/bin:/sbin:/usr/X11R6/bin:/usr/sbin:/bin:/usr/games:/opt/gnome/bin:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin
 
Old 03-11-2009, 01:02 PM   #4
Linuxchuck
LQ Newbie
 
Registered: Aug 2007
Distribution: Slackware from 94-09, Debian Since March 09
Posts: 28

Rep: Reputation: 19
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.
 
Old 03-11-2009, 01:04 PM   #5
farslayer
LQ Guru
 
Registered: Oct 2005
Location: Northeast Ohio
Distribution: linuxdebian
Posts: 7,249
Blog Entries: 5

Rep: Reputation: 191Reputation: 191
have you tried using vim rather than vi ? vi is usually just an alias for vim these days..
 
Old 03-11-2009, 01:21 PM   #6
yang_wayne
Member
 
Registered: Jan 2009
Posts: 40

Original Poster
Rep: Reputation: 15
same result by vi and vim

thanks
 
Old 03-11-2009, 01:27 PM   #7
yang_wayne
Member
 
Registered: Jan 2009
Posts: 40

Original Poster
Rep: Reputation: 15
which vi

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
 
Old 03-11-2009, 02:00 PM   #8
Linuxchuck
LQ Newbie
 
Registered: Aug 2007
Distribution: Slackware from 94-09, Debian Since March 09
Posts: 28

Rep: Reputation: 19
Quote:
Originally Posted by yang_wayne View Post
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.
 
Old 03-11-2009, 02:17 PM   #9
yang_wayne
Member
 
Registered: Jan 2009
Posts: 40

Original Poster
Rep: Reputation: 15
ls -/usr/bin/vi

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
 
Old 03-11-2009, 02:51 PM   #10
Linuxchuck
LQ Newbie
 
Registered: Aug 2007
Distribution: Slackware from 94-09, Debian Since March 09
Posts: 28

Rep: Reputation: 19
Quote:
Originally Posted by yang_wayne View Post
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:

Code:
id
 
Old 03-11-2009, 02:59 PM   #11
yang_wayne
Member
 
Registered: Jan 2009
Posts: 40

Original Poster
Rep: Reputation: 15
id

uid=0(root) gid=0(root) groups=0(root)
 
Old 03-11-2009, 04:31 PM   #12
Linuxchuck
LQ Newbie
 
Registered: Aug 2007
Distribution: Slackware from 94-09, Debian Since March 09
Posts: 28

Rep: Reputation: 19
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.

Best of luck on this one...
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
perl problem? apache problem? cgi problem? WorldBuilder Linux - Software 1 09-17-2003 07:45 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Software

All times are GMT -5. The time now is 05:14 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration