Auto configuration Failed: Permission denied:bss_file.c:126:fopen('/usr/lib/ssl/openssl.cnf','rb')

[Blue Hand Talking]

I am able to ssh into my server. From there I am attempting to ssh to
another account on the same server.
Previously, I was able to do this, but now I am getting an error
message:

10004:error:0200100D:system library:fopen:Permission denied:bss_file.c:
126:fopen('/usr/lib/ssl/openssl.cnf','rb')
10004:error:2006D002:BIO routines:BIO_new_file:system lib:bss_file.c:
131:
10004:error:0E078002:configuration file routines:DEF_LOAD:system
lib:conf_def.c:199:

I tried re-installing openssh-server and openssh-client on my Debian
Squeeze server, but this did not affect anything.

I am using:

openssh-server 1:5.5p1-6+squeeze2
ri openssl 0.9.8o-4squeeze13

I am able to ssh in to my server. I can use sudo from there to ssh to
another account, but am not
able to ssh to my remote, and from there do a plain ssh to another
account on that machine.

Reason for doing this is I am deploying my web app from the remote,
with the repository on the same remote but under a different account/
user.

Any ideas really appreciated.

Thanks!

Jet

[Wolfgang Meiners]

Am 05.09.12 17:11, schrieb Blue Hand Talking:

> I am able to ssh into my server. From there I am attempting to ssh to
> another account on the same server.

So there is a remote_server and two different users user1, user2 and you
try from your client:

$client ssh user1@remote_server

and then as user1 on remote_server

$user1@remote_server ssh user_2@localhost

As far as i know, this should work, but is not recommended. Have you
tried to use su:

$user1@remote_server su - user2

If this works, is there a reason to use ssh for the same (or better:
nearly the same)?

> Previously, I was able to do this, but now I am getting an error
> message:
>
> 10004:error:0200100D:system library:fopen:Permission denied:bss_file.c:
> 126:fopen('/usr/lib/ssl/openssl.cnf','rb')
> 10004:error:2006D002:BIO routines:BIO_new_file:system lib:bss_file.c:
> 131:
> 10004:error:0E078002:configuration file routines:DEF_LOAD:system
> lib:conf_def.c:199:
>

I dont know what this errormessages mean, but have you been updating or
upgrading the ssh-server on the remote site? Maybe there was a change in
the ssh config file

/etc/ssh/ssh_config

> I tried re-installing openssh-server and openssh-client on my Debian
> Squeeze server, but this did not affect anything.
>
> I am using:
>
> openssh-server 1:5.5p1-6+squeeze2
> ri openssl 0.9.8o-4squeeze13
>
> I am able to ssh in to my server. I can use sudo from there to ssh to
> another account, but am not

This would mean, root is allowed to use ssh on localhost, but user1 is not.

> able to ssh to my remote, and from there do a plain ssh to another
> account on that machine.

Use su for this.

>
> Reason for doing this is I am deploying my web app from the remote,
> with the repository on the same remote but under a different account/
> user.
>

If this is what you need, there should be no problem with su.

> Any ideas really appreciated.
>
> Thanks!
>
> Jet
>

Wolfgang

[Blue Hand Talking]

On Sep 6, 6:22 am, Wolfgang Meiners <WolfgangMeiner...@web.de> wrote:
> Am 05.09.12 17:11, schrieb Blue Hand Talking:
>
> > I am able to ssh into my server. From there I am attempting to ssh to
> > another account on the same server.

Answer to this problem:

I had re-installled openssl, as I was having a problem with it. This
messed
up the original installation.

Below is a quote from

http://help.lockergnome.com/linux/Bug-584911-bind9-hard-coded-dependency-usr-lib-ssl-openssl-c--ftopict521350.html

which addresses the problem:

"/usr/lib/ssl/openssl.cnf" is a symlink to "/etc/ssl/openssl.cnf",
both provided by the package "openssl". Unfortunately, on the
respective machine, "/etc/ssl/openssl.cnf" is modified and not world-
readable as it is by default after installing the "openssl" package. "

"I think the point is, bind9 should not expect to be able to read
configuration files from other packages that it not depends on. Also,
if a dependency on "openssl" is explicit and intentional, then users
should be warned if some configuration files need to be readable by
the user the named process runs as. I clearly was not expecting that
there is a connection between "bind9" and "openssl" whatsoever."

(above quoted from Mirko Gebauer)

The above was exactly my problem.

By deleting the symlink, "/usr/lib/ssl/openssl.cnf", my openssl
installation works fine.

I had one more problem, ssh-keygen would still not work.

This was caused by my home directory permissions being set to 775
Changing this to 755 fixed the ssh-keygen problem.

And the answer to why I would want to ssh to another user on the same
machine is that
I have a git repository stored under one user name, and I run my web
server under another user.
When I deploy with Capistrano I ssh from the web user to the
repository user to deploy my site.
since git uses ssh, su was not an easily implemented option.

Cheers,

Jet