<p>Instead of completely opening up RPC ports to the whole internet, I would do something quite different. Here, you're relying on the strength of your RPC auth credentials and the implementation being bugs free. Bitcoind itself strongly discourages to do what was suggested in the other answer:</p>
<pre><code>  -rpcbind=&lt;addr&gt;[:port]
   Bind to given address to listen for JSON-RPC connections. Do not expose
   the RPC server to untrusted networks such as the public internet!
   This option is ignored unless -rpcallowip is also passed. Port is
   optional and overrides -rpcport. Use [host]:port notation for
   IPv6. This option can be specified multiple times (default:
   127.0.0.1 and ::1 i.e., localhost)
</code></pre>
<p>I solved it on a network level: Since I have SSH port open anyway (though on a non-common port just for that extra little bit of obscurity on top of the obviously non-obscurity-reliant security), I opted for SSH tunneling.</p>
<p><strong>LN Node</strong></p>
<p>Basically I have a systemd service on the LN node that starts after boot and creates an SSH connection to my Bitcoin node. Through that tunnel, it can access the node's RPC port 18332 (testnet). The port is not exposed directly to the internet this way, instead only reachable via SSH.</p>
<p>The service is mostly stolen from <a href="https://avizard.blogspot.com/2021/01/aggressive-yet-sane-persistent-ssh-with.html" rel="nofollow noreferrer">https://avizard.blogspot.com/2021/01/aggressive-yet-sane-persistent-ssh-with.html</a>.</p>
<pre><code>$ cat /etc/systemd/system/autossh_systemd_unit.service
[Unit]
Description=AutoSSH service to remotely access RPC of Bitcoin node
#After=network-online.target
# Use this instead if autossh will interact with the local SSH server
After=network-online.target sshd.service

[Service]
User=[NONPRIV_USER]
Environment=&quot;AUTOSSH_GATETIME=30&quot;
Environment=&quot;AUTOSSH_POLL=30&quot;
Environment=&quot;AUTOSSH_FIRST_POLL=30&quot;

ExecStart=/usr/bin/autossh -M 0 -N -q \
-o &quot;ServerAliveInterval 10&quot; \
-o &quot;ServerAliveCountMax 3&quot; \
-o &quot;ExitOnForwardFailure yes&quot; \
-p [SSH_PORT] -l [USER] [HOST] \
-i [SSH_KEY] \
-L 18332:127.0.0.1:18332 #sleep 10
# We set 'sleep 10' to make ssh exit in case no TCP connections are forwarded in 10 seconds.
# Useful to get remote shell exit codes.

ExecStop=/usr/bin/kill $MAINPID
ExecReload=/usr/bin/kill -HUP $MAINPID

Restart=always
# On Linux TCP_TIMEWAIT_LEN is not tunable and set to (60*HZ), about 60 seconds. TCP_FIN_TIMEOUT also defauls to 60 seconds.
RestartSec=60

# See systemd.kill(5)
KillMode=process

[Install]
WantedBy=default.target
</code></pre>
<p><strong>Bitcoin Node</strong></p>
<p>Additionally, the ufw firewall on my Bitcoin node only allows SSH access from 2 specific IPs which are the one which my Lightning node runs on and another one from which I manage my stuff.</p>
<pre><code>$ sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
8333                       ALLOW       Anywhere                   # Bitcoin Mainnet
18333                      ALLOW       Anywhere                   # Bitcoin Testnet
[SSH_PORT]/tcp             ALLOW       [LN_NODE_IP]               # SSH 
[SSH_PORT]/tcp             ALLOW       [MGMT_IP]                  # SSH 
8333 (v6)                  ALLOW       Anywhere (v6)              # Bitcoin Mainnet
18333 (v6)                 ALLOW       Anywhere (v6)              # Bitcoin Testnet
</code></pre>
<p>Lastly, all users can only be logged into with autorized SSH keys and the LN node doesn't hold a key to a superuser account, instead the only user that machine (server) can always access is a non-privileged user. This means in case the LN node gets taken control of, my Bitcoin node is still fine.</p>
<pre><code>$ cat /etc/ssh/sshd_config
[...]
Port [SSH_PORT]
[...]
PubkeyAuthentication yes
[...]
PasswordAuthentication no
[...]
</code></pre>
<p>Additionally, an IDS would be advisable on both machines, but the setup for that exceeds the scopes of this question.</p>
<p>I would be interested to hear what other options people use!</p>

CC BY-SA 4.0
2021-04-29T15:56:00.843Z
2021-04-29T15:56:00.843Z
unixb0y
<p>With <a href="https://github.com/ElementsProject/lightning#getting-started" rel="nofollow noreferrer">C-lightning</a> you can connect your lightning node to a remote full node:</p>

<p><strong>~/.lightning/config</strong></p>

<pre><code>bitcoin-rpcconnect=&lt;remote-ip&gt;
bitcoin-rpcport=&lt;rpc-port&gt;
bitcoin-rpcuser=&lt;rpc-user&gt;
bitcoin-rpcpassword=&lt;rpc-password&gt;
alias=&lt;alias&gt;
network=bitcoin
</code></pre>

<p>Then start the lightning application:</p>

<p><code>$ lightningd --daemon</code></p>

<p>Note this will require enabling the RPC server (<code>server=1</code> in <code>bitcoin.conf</code>) on the full node and configuring the authentication. See </p>

<pre><code>$ bitcoind --help
...
-rpcauth=&lt;userpw&gt;
Username and hashed password for JSON-RPC connections. The field
&lt;userpw&gt; comes in the format: &lt;USERNAME&gt;:&lt;SALT&gt;$&lt;HASH&gt;. A
canonical python script is included in share/rpcuser. The client
then connects normally using the
rpcuser=&lt;USERNAME&gt;/rpcpassword=&lt;PASSWORD&gt; pair of arguments. This
option can be specified multiple times
...
</code></pre>

CC BY-SA 4.0
2019-01-05T10:14:00.727Z
For this you don't need to set an alias in the lightning config. Otherwise great answer
Rene Pickhardt
CC BY-SA 4.0
2018-09-18T03:06:42.803Z
2018-09-18T04:09:48.980Z
2018-09-18T04:09:48.980Z
JBaczuk
<p>I am running a full node on a static IP and I can open up whatever ports needed to communicate with that node.</p>

<p>I need to figure out how to communicate with that full node remotely.  I want to run an implementation of lightning but don't know what is best to use, LND, C-lightning, Eclair, etc. </p>

<p>I will be traveling and will have my lightning on a USB stick and then want to communicate with my remote full node.</p>

<p>Is this even possible ?</p>

<full-node>
Need to access remote bitcoin node for Lightning
Mateo M.
# Need to access remote bitcoin node for Lightning

(Asked by: username_0 on 2018-09-17)

I am running a full node on a static IP and I can open up whatever ports needed to communicate with that node.

I need to figure out how to communicate with that full node remotely. I want to run an implementation of lightning but don't know what is best to use, LND, C-lightning, Eclair, etc.

I will be traveling and will have my lightning on a USB stick and then want to communicate with my remote full node.

Is this even possible ?

**Tags:** full-node


---

## 2 answers

### Answer by username_1 on 2021-04-29. Score: 2

Instead of completely opening up RPC ports to the whole internet, I would do something quite different. Here, you're relying on the strength of your RPC auth credentials and the implementation being bugs free. Bitcoind itself strongly discourages to do what was suggested in the other answer:

```
  -rpcbind=<addr>[:port]
   Bind to given address to listen for JSON-RPC connections. Do not expose
   the RPC server to untrusted networks such as the public internet!
   This option is ignored unless -rpcallowip is also passed. Port is
   optional and overrides -rpcport. Use [host]:port notation for
   IPv6. This option can be specified multiple times (default:
   127.0.0.1 and ::1 i.e., localhost)

```

I solved it on a network level: Since I have SSH port open anyway (though on a non-common port just for that extra little bit of obscurity on top of the obviously non-obscurity-reliant security), I opted for SSH tunneling.

**LN Node**

Basically I have a systemd service on the LN node that starts after boot and creates an SSH connection to my Bitcoin node. Through that tunnel, it can access the node's RPC port 18332 (testnet). The port is not exposed directly to the internet this way, instead only reachable via SSH.

The service is mostly stolen from <https://avizard.blogspot.com/2021/01/aggressive-yet-sane-persistent-ssh-with.html>.

```
$ cat /etc/systemd/system/autossh_systemd_unit.service
[Unit]
Description=AutoSSH service to remotely access RPC of Bitcoin node
#After=network-online.target
# Use this instead if autossh will interact with the local SSH server
After=network-online.target sshd.service

[Service]
User=[NONPRIV_USER]
Environment="AUTOSSH_GATETIME=30"
Environment="AUTOSSH_POLL=30"
Environment="AUTOSSH_FIRST_POLL=30"

ExecStart=/usr/bin/autossh -M 0 -N -q \
-o "ServerAliveInterval 10" \
-o "ServerAliveCountMax 3" \
-o "ExitOnForwardFailure yes" \
-p [SSH_PORT] -l [USER] [HOST] \
-i [SSH_KEY] \
-L 18332:127.0.0.1:18332 #sleep 10
# We set 'sleep 10' to make ssh exit in case no TCP connections are forwarded in 10 seconds.
# Useful to get remote shell exit codes.

ExecStop=/usr/bin/kill $MAINPID
ExecReload=/usr/bin/kill -HUP $MAINPID

Restart=always
# On Linux TCP_TIMEWAIT_LEN is not tunable and set to (60*HZ), about 60 seconds. TCP_FIN_TIMEOUT also defauls to 60 seconds.
RestartSec=60

# See systemd.kill(5)
KillMode=process

[Install]
WantedBy=default.target

```

**Bitcoin Node**

Additionally, the ufw firewall on my Bitcoin node only allows SSH access from 2 specific IPs which are the one which my Lightning node runs on and another one from which I manage my stuff.

```
$ sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
8333                       ALLOW       Anywhere                   # Bitcoin Mainnet
18333                      ALLOW       Anywhere                   # Bitcoin Testnet
[SSH_PORT]/tcp             ALLOW       [LN_NODE_IP]               # SSH 
[SSH_PORT]/tcp             ALLOW       [MGMT_IP]                  # SSH 
8333 (v6)                  ALLOW       Anywhere (v6)              # Bitcoin Mainnet
18333 (v6)                 ALLOW       Anywhere (v6)              # Bitcoin Testnet

```

Lastly, all users can only be logged into with autorized SSH keys and the LN node doesn't hold a key to a superuser account, instead the only user that machine (server) can always access is a non-privileged user. This means in case the LN node gets taken control of, my Bitcoin node is still fine.

```
$ cat /etc/ssh/sshd_config
[...]
Port [SSH_PORT]
[...]
PubkeyAuthentication yes
[...]
PasswordAuthentication no
[...]

```

Additionally, an IDS would be advisable on both machines, but the setup for that exceeds the scopes of this question.

I would be interested to hear what other options people use!


---

### Answer by username_2 on 2018-09-18. Score: 1

With [C-lightning](https://github.com/ElementsProject/lightning#getting-started) you can connect your lightning node to a remote full node:

**~/.lightning/config**

```
bitcoin-rpcconnect=<remote-ip>
bitcoin-rpcport=<rpc-port>
bitcoin-rpcuser=<rpc-user>
bitcoin-rpcpassword=<rpc-password>
alias=<alias>
network=bitcoin

```

Then start the lightning application:

`$ lightningd --daemon`

Note this will require enabling the RPC server (`server=1` in `bitcoin.conf`) on the full node and configuring the authentication. See

```
$ bitcoind --help
...
-rpcauth=<userpw>
Username and hashed password for JSON-RPC connections. The field
<userpw> comes in the format: <USERNAME>:<SALT>$<HASH>. A
canonical python script is included in share/rpcuser. The client
then connects normally using the
rpcuser=<USERNAME>/rpcpassword=<PASSWORD> pair of arguments. This
option can be specified multiple times
...

```

> **Comments:**
> **username_3**: For this you don't need to set an alias in the lightning config. Otherwise great answer  

---

