CouchDB not reachable (beginner's question)

[Stefan Reich]

Hi there!

I'd like to start using CouchDB for my projects.

This is on a Linux host. CouchDB installed from standard Debian package, no
settings altered. But it doesn't start properly:

root@pussy-riot-germany:~/luastuff# uname -a
Linux pussy-riot-germany 2.6.32-042stab068.8 #1 SMP Fri Dec 7 17:06:14 MSK
2012 i686 GNU/Linux
root@pussy-riot-germany:~/luastuff# /etc/init.d/couchdb start
Starting database server: couchdb.
root@pussy-riot-germany:~/luastuff# /etc/init.d/couchdb status
Apache CouchDB is running as process 7651, time to relax.
root@pussy-riot-germany:~/luastuff# telnet localhost 5984
Trying ::1...
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused

Connection refused?

Here's the process info:

root@pussy-riot-germany:~/luastuff# uname -a
Linux pussy-riot-germany 2.6.32-042stab068.8 #1 SMP Fri Dec 7 17:06:14 MSK
2012 i686 GNU/Linux
root@pussy-riot-germany:~/luastuff# /etc/init.d/couchdb start
Starting database server: couchdb.
root@pussy-riot-germany:~/luastuff# /etc/init.d/couchdb status
Apache CouchDB is running as process 7651, time to relax.
root@pussy-riot-germany:~/luastuff# telnet localhost 5984
Trying ::1...
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused

Please help, dear experts... :)

Cheers,
Stefan

[Stefan Reich]

Oops, bad copy&paste - here's the actual process info:

root@pussy-riot-germany:~/luastuff# ps -aef|grep 7651
couchdb 7651 7650 0 19:44 pts/0 00:00:00
/usr/lib/erlang/erts-5.8/bin/beam.smp -Bd -K true -- -root /usr/lib/erlang
-progname erl -- -home /var/lib/couchdb -- -noshell -noinput -sasl
errlog_type error -couch_ini /etc/couchdb/default.ini
/etc/couchdb/local.ini /etc/couchdb/default.ini /etc/couchdb/local.ini -s
couch -pidfile /var/run/couchdb/couchdb.pid -heart
couchdb 7682 7651 0 19:44 ? 00:00:00 heart -pid 7651 -ht 11

Cheers,
Stefan

[Tim Tisdall]

Do you have any firewall (iptables) rules running?


On Wed, Apr 10, 2013 at 1:47 PM, Stefan Reich <

[Stanley Iriele]

Why are you telneting to it?...try curling it and see whatviy responds with
On Apr 10, 2013 10:47 AM, "Stefan Reich" <

[Robert Newson]

Are you sure localhost == 127.0.0.1 on your machine? debian/ubuntu are
notorious for changing that convention.

[Stanley Iriele]

A simple cat of etc/hosts... Should let you know!... And maybe nsswitch
just to be sure

[Andrey Kuprianov]

See if your local.ini bind_address is set to 0.0.0.0 so that you can access
it locally and remotely.

[Stefan Reich]

OK, thanks for all the answers, folks. It was indeed iptables that blocked
the port. This stuff should be designed (much) better in operating systems.

Actually it's a project of mine to make that better (LuaOS and its
follow-ups).

I got iptables to allow access locally now. Weirdly, it still doesn't work
over the Internet. And no, the server is not behind a firewall... :)

Thanks,
Stefan

[Stefan Reich]

Hmm... maybe you guys can help me solve the rest of the problem? (Access to
couchdb from outside)

These are the last iptables rules in chain INPUT:;

MY_REJECT all -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere tcp dpt:5984

Is that not what it should be...? Says "anywhere"... everywhere. Heh.

Cheers,
Stefan


On Mon, Apr 15, 2013 at 1:08 PM, Stefan Reich <

[Robert Newson]

Stefan,

CouchDB defaults to binding to 127.0.0.1 only (so that you can set an
admin password).

Do curl -XPUT localhost:5984/_config/httpd/bind_address -d '"0.0.0.0"'
to bind it to all interfaces (but do set an admin user/password
first).

For iptables, remember to add to -v (e.g, iptables -L -n -v) so that
you can see which interfaces you've granted access to.

B.




On 15 April 2013 12:14, Stefan Reich

[Stefan Reich]

Hi Robert,

thanks for the answer.

Now it's actually done... I looked up /etc/init.d/firewall and added a line
there according to other lines that already existed:

iptables -A INPUT -i $device -m state --state NEW -p tcp --dport 5984
-j ACCEPT

This crap (sorry) REALLY should be more intuitive. I'm thinking: graphical
representation of ports and straight-forward editing. We'll do that in Lua
OS. :)

Thanks again for the help,
Stefan

[Dan Santner]

Stefan, is ufw available to you on your OS? I find that a million times easier than editing iptables.

[Tim Tisdall]

Instead of opening CouchDB to the world, I simply access it by
port-forwarding through ssh when I connect to the machine. Like this:

ssh -L 5984:127.0.0.1:5984 ro...@mymachine.com

Then on my local machine I can simply access http://localhost:5984/_utils/ and
up comes futon. It depends on your use-case, but this works well for me.



On Mon, Apr 15, 2013 at 7:14 AM, Stefan Reich <

[Keith Gable]

But you're SSHing as root, which is probably worse than opening CouchDB to
the world with no password.

---
Keith Gable
A+, Network+, and Storage+ Certified Professional
Apple Certified Technical Coordinator
Mobile Application Developer / Web Developer

[Keith Gable]

ufw and shorewall are great wrappers for iptables that abstract iptables's
terminology into something better.

If you want a GUI to build the firewall config, check out FWBuilder. There
are a few others that exist as well, but I cannot remember what they're
called.

If you're having trouble setting up CouchDB to listen on all interfaces
(0.0.0.0), I would not suggest trying to create an operating system.

---
Keith Gable
A+, Network+, and Storage+ Certified Professional
Apple Certified Technical Coordinator
Mobile Application Developer / Web Developer

[Tim Tisdall]

What's wrong with ssh'ing as root?

[Robert Newson]

wow.

[Antoine Pitrou]

Le Mon, 15 Apr 2013 14:36:04 +0200,
Stefan Reich
<stefan.reich...@googlemail.com> a
écrit :

> Hi Robert,
>
> thanks for the answer.
>
> Now it's actually done... I looked up /etc/init.d/firewall and added
> a line there according to other lines that already existed:
>
> iptables -A INPUT -i $device -m state --state NEW -p tcp --dport
> 5984 -j ACCEPT
>
> This crap (sorry) REALLY should be more intuitive. I'm thinking:
> graphical representation of ports and straight-forward editing.

There *are* higher-level firewall management tools than iptables. They
are certainly available in your favourite Linux distro.
(on the command-line side, shorewall comes to mind)

> We'll
> do that in Lua OS. :)

Well, good luck...

Regards

Antoine.

[Keith Gable]

http://serverfault.com/questions/57962/whats-wrong-with-always-being-root

---
Keith Gable
A+, Network+, and Storage+ Certified Professional
Apple Certified Technical Coordinator
Mobile Application Developer / Web Developer

[Keith Gable]

wow indeed.

---
Keith Gable
A+, Network+, and Storage+ Certified Professional
Apple Certified Technical Coordinator
Mobile Application Developer / Web Developer

[Tim Tisdall]

Still don't see how ssh'ing in as root is anywhere as bad as having your
CouchDB open to the world with no password...

If you had two machines, one with no password and public access to CouchDB
and another one with someone logged in via SSH as root and someone asked
you to delete the DB on one of those machines, which one would you go after?

[Robert Newson]

That's a false equivalence. You should not open couchdb to the world
before you set an administration password in the first place. :)

B.

[Keith Gable]

Trick question: none of my servers allow root logins (PermitRootLogin No in
sshd.conf)

If CouchDB is wide open, the worst that can happen is your CouchDB data is
deleted. If root is available, the worst that can happen is a total
destruction of all data on the machine, potential compromise of other
servers (because the password or key is known), and a really bad day. If
you were using key-based authentication, it would be slightly better, but
why not log in as you@server and use sudo if needed? Certainly you don't
need root to do SSH tunneling.

---
Keith Gable
A+, Network+, and Storage+ Certified Professional
Apple Certified Technical Coordinator
Mobile Application Developer / Web Developer

[Tim Tisdall]

"... SSHing as root, which is probably worse than opening CouchDB to the
world with no password."

I don't see how they're equivalent or even similar... hence my question.
And I don't see anything inherently wrong with ssh'ing as root, too. As
far as the external world is concerned, ssh'ing in as root is just as
secure as any other log in with the exception that people would already
know the login name (but not the password or certificate used).

[Tim Tisdall]

I didn't say they were your servers... Just servers in general. And the
fact that I said one had someone logged in as root kind of implies that you
can log in as root, right? Also, logging in as root is not the same as
having root "available" to everyone.

[matt j. sorenson]

On Mon, Apr 15, 2013 at 9:18 AM, Robert Newson <rne...@apache.org> wrote:

> wow.
>

retweet

[Michael Zedeler.]

Hi Keith and others.

First off, I'd prefer to read discussions on this list based on facts
and not just "wow". You may have a point, but it's not a very nice
welcome to Tim who is writing in with a beginners question (his own
wording - not mine).

Second, I'd like to pick up your comment on remote root login via ssh.

A server where root login using a pass phrase can be hacked using brute
force over time. Yes - fail2ban should mitigate this somewhat, but it is
still something that is just waiting to happen.

But if you force the use of key login, getting in using brute force is
essentially impossible.

Then you could argue that using a second user account could serve as a
second line of defense, but that is very thin line. Any attacker who has
gained access to such an account can easilly log in and modify the
environment to pick up any passwords that the user must enter in order
to get root access.

Monitoring, hardening and two factor authentication is what comes to
mind when I think of what can be done to actually avoid the problem.

I know that having remote ssh root access isn't ideal, but I think it is
becoming very common on servers in small organisations because any extra
security layers are complicated to set up, manage and monitor.

Regards,

Michael

[Robert Newson]

Michael,

You are quite right to call me on my non-contribution to this thread,
I apologise.

I always set AllowRootLogin to false on ssh in the spirit of
defence-in-depth, coupled with the "UsePrivilegeSeparation yes"
setting.

SSH'ing to a non-privileged user account, allowed to sudo with a
password, is an extra hurdle.

The biggest improvement is to disable insecure SSH methods like
passwords, of course. That and keeping sshd patched.

B.

[Tim Tisdall]

lulz! ^_^

Okay, first of all... I didn't start this thread. I was suggesting a
possible solution to accessing CouchDB without having to open the server to
the general public with no password.

For some reason I got a comment that logging in as root was "worse" than
making CouchDB publicly accessible. I don't see why it's a big deal with
respect to the conversation at hand. The original poster just wanted to
access his CouchDB instance. Whether or not allowing root causes brute
force attacks to be more successful really has nothing to do with the topic
at hand.

>>> zi...@ignition-project.com>**wrote:

>>>
>>>> But you're SSHing as root, which is probably worse than opening CouchDB
>>>>>
>>>> to
>>>
>>>> the world with no password.
>>>>>
>>>>> ---
>>>>> Keith Gable
>>>>> A+, Network+, and Storage+ Certified Professional
>>>>> Apple Certified Technical Coordinator
>>>>> Mobile Application Developer / Web Developer
>>>>>
>>>>>
>>>>> On Mon, Apr 15, 2013 at 8:45 AM, Tim Tisdall <tis...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Instead of opening CouchDB to the world, I simply access it by
>>>>>> port-forwarding through ssh when I connect to the machine. Like this:
>>>>>>
>>>>>> ssh -L 5984:127.0.0.1:5984 ro...@mymachine.com
>>>>>>
>>>>>> Then on my local machine I can simply access
>>>>>>

>>>>> http://localhost:5984/_utils/**and <http://localhost:5984/_utils/and>

>>>>>
>>>>>> up comes futon. It depends on your use-case, but this works well for
>>>>>>
>>>>> me.
>>>
>>>>
>>>>>>
>>>>>> On Mon, Apr 15, 2013 at 7:14 AM, Stefan Reich <

>>>>>> stefan.reich.maker.of.eye@**googlemail.com<stefan.reich...@googlemail.com>>

>>>>>> wrote:
>>>>>>
>>>>>> Hmm... maybe you guys can help me solve the rest of the problem?
>>>>>>>
>>>>>> (Access
>>>>>
>>>>>> to
>>>>>>
>>>>>>> couchdb from outside)
>>>>>>>
>>>>>>> These are the last iptables rules in chain INPUT:;
>>>>>>>
>>>>>>> MY_REJECT all -- anywhere anywhere
>>>>>>> ACCEPT tcp -- anywhere anywhere tcp
>>>>>>>
>>>>>> dpt:5984
>>>>>
>>>>>> Is that not what it should be...? Says "anywhere"... everywhere.
>>>>>>>
>>>>>> Heh.
>>>
>>>> Cheers,
>>>>>>> Stefan
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Apr 15, 2013 at 1:08 PM, Stefan Reich <

>>>>>>> stefan.reich.maker.of.eye@**googlemail.com<stefan.reich...@googlemail.com>>

>>>>>>>>>>>> stefan.reich.maker.of.eye@**googlemail.com<stefan.reich...@googlemail.com>>

>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Oops, bad copy&paste - here's the actual process info:
>>>>>>>>>>>>>

>>>>>>>>>>>>> root@pussy-riot-germany:~/**luastuff# ps -aef|grep 7651

>>>>>>>>>>>>> couchdb 7651 7650 0 19:44 pts/0 00:00:00

>>>>>>>>>>>>> /usr/lib/erlang/erts-5.8/bin/**beam.smp -Bd -K true -- -root

>>>>>>>>>>>>>
>>>>>>>>>>>> /usr/lib/erlang
>>>>>>>>>>>
>>>>>>>>>>>> -progname erl -- -home /var/lib/couchdb -- -noshell
>>>>>>>>>>>>>
>>>>>>>>>>>> -noinput
>>>
>>>> -sasl
>>>>>>>
>>>>>>>> errlog_type error -couch_ini /etc/couchdb/default.ini
>>>>>>>>>>>>> /etc/couchdb/local.ini /etc/couchdb/default.ini
>>>>>>>>>>>>>
>>>>>>>>>>>> /etc/couchdb/local.ini
>>>>>>>>>
>>>>>>>>>> -s
>>>>>>>>>>>
>>>>>>>>>>>> couch -pidfile /var/run/couchdb/couchdb.pid -heart
>>>>>>>>>>>>> couchdb 7682 7651 0 19:44 ? 00:00:00 heart -pid
>>>>>>>>>>>>>
>>>>>>>>>>>> 7651
>>>>>
>>>>>> -ht 11
>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Stefan
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Apr 10, 2013 at 7:46 PM, Stefan Reich <

>>>>>>>>>>>>> stefan.reich.maker.of.eye@**googlemail.com<stefan.reich...@googlemail.com>>

>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi there!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'd like to start using CouchDB for my projects.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is on a Linux host. CouchDB installed from standard
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Debian
>>>>>>
>>>>>>> package,
>>>>>>>>>>>
>>>>>>>>>>>> no settings altered. But it doesn't start properly:
>>>>>>>>>>>>>>

>>>>>>>>>>>>>> root@pussy-riot-germany:~/**luastuff# uname -a

>>>>>>>>>>>>>> Linux pussy-riot-germany 2.6.32-042stab068.8 #1 SMP Fri
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Dec 7
>>>>>
>>>>>> 17:06:14
>>>>>>>>>>
>>>>>>>>>>> MSK
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2012 i686 GNU/Linux

>>>>>>>>>>>>>> root@pussy-riot-germany:~/**luastuff# /etc/init.d/couchdb

>>>>>>>>>>>>>>
>>>>>>>>>>>>> start
>>>>>>
>>>>>>> Starting database server: couchdb.

>>>>>>>>>>>>>> root@pussy-riot-germany:~/**luastuff# /etc/init.d/couchdb

>>>>>>>>>>>>>>
>>>>>>>>>>>>> status
>>>>>>
>>>>>>> Apache CouchDB is running as process 7651, time to
>>>>>>>>>>>>>>
>>>>>>>>>>>>> relax.
>>>

>>>> root@pussy-riot-germany:~/**luastuff# telnet localhost

>>>>>>>>>>>>>>
>>>>>>>>>>>>> 5984
>>>
>>>> Trying ::1...
>>>>>>>>>>>>>> Trying 127.0.0.1...
>>>>>>>>>>>>>> telnet: Unable to connect to remote host: Connection
>>>>>>>>>>>>>>
>>>>>>>>>>>>> refused
>>>>>
>>>>>> Connection refused?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Here's the process info:
>>>>>>>>>>>>>>

>>>>>>>>>>>>>> root@pussy-riot-germany:~/**luastuff# uname -a

>>>>>>>>>>>>>> Linux pussy-riot-germany 2.6.32-042stab068.8 #1 SMP Fri
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Dec 7
>>>>>
>>>>>> 17:06:14
>>>>>>>>>>
>>>>>>>>>>> MSK
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2012 i686 GNU/Linux

>>>>>>>>>>>>>> root@pussy-riot-germany:~/**luastuff# /etc/init.d/couchdb

>>>>>>>>>>>>>>
>>>>>>>>>>>>> start
>>>>>>
>>>>>>> Starting database server: couchdb.

>>>>>>>>>>>>>> root@pussy-riot-germany:~/**luastuff# /etc/init.d/couchdb

>>>>>>>>>>>>>>
>>>>>>>>>>>>> status
>>>>>>
>>>>>>> Apache CouchDB is running as process 7651, time to
>>>>>>>>>>>>>>
>>>>>>>>>>>>> relax.
>>>

>>>> root@pussy-riot-germany:~/**luastuff# telnet localhost