2

I have FreeBSd running with OpenSSH. I set up everything and the connection via SSH worked perfectly. Then I decided to get rid of some not used ports and I obviously uninstalled one that was used by zsh.

When I log in I get the following:

~ # ssh [email protected] Password: Last login: Wed Nov 7 21:56:26 2012 from 192.168.1.52 FreeBSD 9.0-RELEASE (GENERIC) #0: Tue Jan 3 07:15:25 UTC 2012 Welcome to FreeBSD! Before seeking technical support, please use the following resources: o Security advisories and updated errata information for all releases are at http://www.FreeBSD.org/releases/ - always consult the ERRATA section for your release first as it's updated frequently. o The Handbook and FAQ documents are at http://www.FreeBSD.org/ and, along with the mailing lists, can be searched by going to http://www.FreeBSD.org/search/. If the doc package has been installed (or fetched via pkg_add -r lang-freebsd-doc, where lang is the 2-letter language code, e.g. en), they are also available formatted in /usr/local/share/doc/freebsd. If you still have a question or problem, please take the output of `uname -a', along with any relevant error messages, and email it as a question to the [email protected] mailing list. If you are unfamiliar with FreeBSD's directory layout, please refer to the hier(7) manual page. If you are not familiar with manual pages, type `man man'. Edit /etc/motd to change this login announcement. Shared object "libiconv.so.3" not found, required by "zsh"Connection to 192.168.1.56 closed.

The thing is that I have no monitor nor do I have a keyboard (right now) to solve the problem very quickly...

I tried this to force loading a different shell > Force SSH to use a specific shell

Does not work as I get:

~ # ssh [email protected] /usr/local/bin/sh << EOF chsh -s /usr/local/bin/bash EOF Password: Shared object "libiconv.so.3" not found, required by "zsh"%

Any ideas how to solve it without keyboard and monitor?

Improve this question

4 Answers 4

Reset to default
3

I did this same exact error once. I doubt you'll be able to get the root access needed to change your shell remotely. Another, less likely option is to hack your own box and get root privileges.

I had to connect locally via keyboard and monitor and change to the default shell. Never make root use a userland shell. Always let root use the default shell that comes with the system. If you need or want to use a different shell, start it manually after login. This is what I do now.

And remember, don't do make delete-old-libs in /usr/src unless you absolutely know you won't be needing those libs anymore :-D

Improve this answer
2
  • 1
    Also remember: always Always ALWAYS have a user account that uses a system default shell (/bin/sh, /bin/csh, /bin/tcsh) so you can get back in if your favorite custom shell goes screwy. Commented Nov 9, 2012 at 17:52
  • I accept this answer as it is true :) There was no way to get in via ssh or any other remote way. Actually I had to boot FreeBSD in safe mode and for some reason any changes on the passwd were not taken into consideration. So I created a symlink in /usr/local/bin/zsh that pointed to /bin/csh. This was the only way to get in Commented Nov 19, 2012 at 20:17
2

If sftp works, I would try to upload a ~/.ssh/rc file with the commands I need to run (perhaps echo password | chsh -s /usr/local/bin/bash?) and hope that ssh, as its manual page states, does execute those commands before launching the user's shell.

Improve this answer
3
  • scp does not work. I get the same error Commented Nov 7, 2012 at 15:38
  • Not really scp, but rather sftp. Since sftp is a subsystem, I think it will not be invoked through the shell. Commented Nov 7, 2012 at 15:56
  • I just get "Connection closed". So it doesn't work. I assume this was kinda my last chance? Commented Nov 7, 2012 at 17:22
1

Method 1

Try following

 ssh username@hostname "/bin/sh -i"

That will let you login with sh instead of bash if successful.

Method 2

ssh into the box with another user and then su/sudo to regain root access.

Improve this answer
1

bash and zsh both have a dependency on libiconv, so neither will work for you, since you removed it. You can do as John suggested, and tell ssh explicitly to run sh or csh, which are both in the base system and should therefore function correctly, as they have no external dependency on anything in ports.

ssh me@there "/bin/sh -i"

You now have a shell session, where you can install libiconv again. For future reference, it's worth using something like ports-mgmt/pkg_cutleaves to remove ports you no longer need - it makes it much harder to shoot yourself in the foot like this!

Improve this answer

You must log in to answer this question.