Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
invalid login shell (root user)
- Thread starter dbase77
- Start date
First, check if you have trusted user access from another system or if anyone else is currently logged in as root.
You may need to boot from cdrom using the install disk then mount /etc, edit the passwd file to set root password to blank and reboot.
Ged Jones
Top man
- Thread starter
- #4
- Thread starter
- #6
KenCunningham
Technical User
Read faq60-1568 , albeit this is probably for a Sparc system.
Does this help?
Does this help?
- Thread starter
- #8
Hi,
not really coz I stucked with login prompt and couldn't login as root. Even though I tried to boot at single mode it gave me error "NO SHELL".
Im on solaris 8 intel. when i boot my computer and type b -s cdrom i couldn't boot. I realy need to get back. I hope somebody out there has some solution regarding this issue.
Thank you.
regards,
feroz
not really coz I stucked with login prompt and couldn't login as root. Even though I tried to boot at single mode it gave me error "NO SHELL".
Im on solaris 8 intel. when i boot my computer and type b -s cdrom i couldn't boot. I realy need to get back. I hope somebody out there has some solution regarding this issue.
Thank you.
regards,
feroz
KenCunningham
Technical User
Hey, happens to all of us Ged ;-)
dbase, if you're at the login prompt, you need to get back to an OK prompt so that you can boot from the CD. On Sparc machines, this is STOP-A, but Intel may be different.
Have a good weekend, folks.
dbase, if you're at the login prompt, you need to get back to an OK prompt so that you can boot from the CD. On Sparc machines, this is STOP-A, but Intel may be different.
Have a good weekend, folks.
- Thread starter
- #12
If there is another user that can log onto the system, log on as them and ftp the /etc/passwd file out to another system. Then edit the shell part of roots line, then have the other user ftp it back into his/her home directory. You can then use rexec to copy it back over /etc/passwd from a different system as rexec bypasses the shell,etc, I think.
Let me know if it works.
Will
Let me know if it works.
Will
KenCunningham
Technical User
On a similar thread to Will's, the article below (particularly the final paragraph) might help in future situations of this kind:
The FTP-Only Account
By Sandra Henry-Stocker
Until recently, I didn't think that, short of writing a new shell,providing a Unix account that permitted a user to ftp files back-and-forth while preventing any other actions was possible. The closest thing was anonymous ftp, where a user could transfer files using a username and password (though the username was "anonymous" and the
password almost anything at all), but anonymous ftp doesn't provide a user with his own file space and this might easily be a requirement.
I was wrong. It is possible to create an FTP-only account and, further, the method by which this can be done is well within the realm of what I should have realized all along was possible. It combines two small pieces of Unix know-how or "tricks".
The first "trick" to setting up an account of this sort is to assign the user a shell that doesn't exist. That's right. There's no need to create a program or even touch a file. Simply insert the string of your choice into the shell field of the /etc/passwd file. This keeps the
user from being able to log in to the system. If he tries to telnet in to the system, for example, he gets a "no shell" error like what is shown below. In fact, almost anything he might try to do, even running a remote shell command, will balk at the invalid shell. In this
example, we've named our ftp-only user "ftponly" and set his shell to /bin/noop. Notice how he is denied access because the shell associated with his account doesn't exist.
------------------------------ cut here --------------------------------
# telnet dragonfly
Trying 10.10.10.10...
Connected to dragonfly.dragonflyditch.com.
Escape character is '^]'.
SunOS 5.8
login: ftponly
Password:
Last login: Sat Jun 29 23:38:08 from dragonfly.dragon
No shell
Connection closed by foreign host.
------------------------------ cut here --------------------------------
When the ftp-only user tries the ftp command, on the other hand, the system checks that his shell is in the /etc/shells file and checks nothing else. That's right. Since the ftp command does not require anything from the user's environment in order to transfer files in
either direction, no further checking is done. Ftp sessions are, in fact, one of the few user connections that do not establish the user's working environment.
Let's watch the ftp-only user connect to the system with ftp.
------------------------------ cut here --------------------------------
$ ftp dragonfly
Connected to dragonfly.dragonflyditch.com.
220 dragonfly FTP server (SunOS 5.8) ready.
Name (dragonfly:root): ftponly
331 Password required for ftponly.
Password:
230 User ftponly logged in.
ftp> ls
200 PORT command successful.
150 ASCII data connection for /bin/ls (10.10.10.10,32817) (0 bytes).
sandrich.pdf
226 ASCII Transfer complete.
14 bytes received in 0.039 seconds (0.35 Kbytes/s)
ftp>
------------------------------ cut here --------------------------------
Clearly the ftp session was successful. The user logged in and prepared to transfer a file. Nothing about the ftp session, in fact, appears out of the ordinary.
The /etc/passwd entry for our ftp-only user looks like this:
ftponly:x:106:10:FTP Only:/export/home/ftponly:/bin/noop
The only unusual thing about this /etc/passwd line is the shell and just about anything could be used, though it probably needs to look like a Unix pathname to prevent any other command from concluding that the /etc/passwd file has an invalid format.
Knowing this trick, I might have worked my way out of those couple of instances where I or someone else introduced a typo into root's shell and could not login as root or use root privilege through any means until I had booted the system from a CD and corrected the problem - but
only if I had typed a line which just happened to exist in the /etc/shells file or somehow left that file open to writes by some other user -- ehh, not likely, I guess.
Cheers.
The FTP-Only Account
By Sandra Henry-Stocker
Until recently, I didn't think that, short of writing a new shell,providing a Unix account that permitted a user to ftp files back-and-forth while preventing any other actions was possible. The closest thing was anonymous ftp, where a user could transfer files using a username and password (though the username was "anonymous" and the
password almost anything at all), but anonymous ftp doesn't provide a user with his own file space and this might easily be a requirement.
I was wrong. It is possible to create an FTP-only account and, further, the method by which this can be done is well within the realm of what I should have realized all along was possible. It combines two small pieces of Unix know-how or "tricks".
The first "trick" to setting up an account of this sort is to assign the user a shell that doesn't exist. That's right. There's no need to create a program or even touch a file. Simply insert the string of your choice into the shell field of the /etc/passwd file. This keeps the
user from being able to log in to the system. If he tries to telnet in to the system, for example, he gets a "no shell" error like what is shown below. In fact, almost anything he might try to do, even running a remote shell command, will balk at the invalid shell. In this
example, we've named our ftp-only user "ftponly" and set his shell to /bin/noop. Notice how he is denied access because the shell associated with his account doesn't exist.
------------------------------ cut here --------------------------------
# telnet dragonfly
Trying 10.10.10.10...
Connected to dragonfly.dragonflyditch.com.
Escape character is '^]'.
SunOS 5.8
login: ftponly
Password:
Last login: Sat Jun 29 23:38:08 from dragonfly.dragon
No shell
Connection closed by foreign host.
------------------------------ cut here --------------------------------
When the ftp-only user tries the ftp command, on the other hand, the system checks that his shell is in the /etc/shells file and checks nothing else. That's right. Since the ftp command does not require anything from the user's environment in order to transfer files in
either direction, no further checking is done. Ftp sessions are, in fact, one of the few user connections that do not establish the user's working environment.
Let's watch the ftp-only user connect to the system with ftp.
------------------------------ cut here --------------------------------
$ ftp dragonfly
Connected to dragonfly.dragonflyditch.com.
220 dragonfly FTP server (SunOS 5.8) ready.
Name (dragonfly:root): ftponly
331 Password required for ftponly.
Password:
230 User ftponly logged in.
ftp> ls
200 PORT command successful.
150 ASCII data connection for /bin/ls (10.10.10.10,32817) (0 bytes).
sandrich.pdf
226 ASCII Transfer complete.
14 bytes received in 0.039 seconds (0.35 Kbytes/s)
ftp>
------------------------------ cut here --------------------------------
Clearly the ftp session was successful. The user logged in and prepared to transfer a file. Nothing about the ftp session, in fact, appears out of the ordinary.
The /etc/passwd entry for our ftp-only user looks like this:
ftponly:x:106:10:FTP Only:/export/home/ftponly:/bin/noop
The only unusual thing about this /etc/passwd line is the shell and just about anything could be used, though it probably needs to look like a Unix pathname to prevent any other command from concluding that the /etc/passwd file has an invalid format.
Knowing this trick, I might have worked my way out of those couple of instances where I or someone else introduced a typo into root's shell and could not login as root or use root privilege through any means until I had booted the system from a CD and corrected the problem - but
only if I had typed a line which just happened to exist in the /etc/shells file or somehow left that file open to writes by some other user -- ehh, not likely, I guess.
Cheers.
KenCunningham
Technical User
And finally (I hope) STOP-A can be replicated on a 'normal' keyboard using the CTRL BREAK combination.
- Thread starter
- #17
- Thread starter
- #19
HI
Thank you for your suggestion. It tried to use rcp but I got permission denied error. hmmm I suppose I have to re-install everything now. Is there any other method that I could try before I refresh everything?
Thank you in advance.
regards,
feroz
Thank you for your suggestion. It tried to use rcp but I got permission denied error. hmmm I suppose I have to re-install everything now. Is there any other method that I could try before I refresh everything?
Thank you in advance.
regards,
feroz
KenCunningham
Technical User
You probably got a permission denied error because you don't have an .rhosts file in the home directory of root. Are you sure you can't boot from the CD?
- Status
Similar threads