Remote Debugging

I am working on a test fixture that uses an RS-232 port for control.  I travel a lot and don't want to have to drag the test fixture around with me.  

Some time ago I was working with an eval board via serial port and used an rPi (Raspberry Pi) to put the serial port on the network and work from another room.  That worked pretty well.  I didn't have a means of rebooting the target however.  This time I will add a capability of removing power from the test fixture to provide a reset.  

What I didn't try before was using this rig over the Internet.  I'm not even sure where to being digging into how to do that.  I expect it is not complicated to make the serial port accessible through the router and modem, but I'm not sure where to begin.  Or does the router even get involved and is just transparent and I only need the local IP address?  None of the sources I've found address the issue of getting through the router, etc. 

Essentially I want the serial port on the rPi to become a virtual serial port on a PC located anywhere else on the planet.  :) 

Rick C.

gnuarm.deletethisbit@gmail.com wrote:
> I am working on a test fixture that uses an RS-232 port for control.  I travel a lot and don't want to have to drag the test fixture around with me.  
> 
> Some time ago I was working with an eval board via serial port and used an rPi (Raspberry Pi) to put the serial port on the network and work from another room.  That worked pretty well.  I didn't have a means of rebooting the target however.  This time I will add a capability of removing power from the test fixture to provide a reset.  
> 
> What I didn't try before was using this rig over the Internet.  I'm not even sure where to being digging into how to do that.  I expect it is not complicated to make the serial port accessible through the router and modem, but I'm not sure where to begin.  Or does the router even get involved and is just transparent and I only need the local IP address?  None of the sources I've found address the issue of getting through the router, etc. 
> 
> Essentially I want the serial port on the rPi to become a virtual serial port on a PC located anywhere else on the planet.  :) 

1. Enable SSH on the Pi
2. Disable password authentication and copy an SSH key from whatever machine
you want to connect from
3. Set up your router to port-forward port 22 to the Pi port 22
3a. (Optional) Set up dynamic DNS using someprovider, if your ISP
doesn't offer a static IP
4. SSH from your laptop on the internet (or whatever) to your router
5. Run something like 'picocom /dev/ttyUSB0' at the prompt to start a
terminal
6. Configure the Pi for automatic software updates, so it's kept up to date
with security patches

Theo

On Tuesday, February 26, 2019 at 4:37:44 PM UTC-6, Theo wrote:
> gnuarm.deletethisbit@gmail.com wrote:
> > I am working on a test fixture that uses an RS-232 port for control.  I travel a lot and don't want to have to drag the test fixture around with me.  
> > 
> > Some time ago I was working with an eval board via serial port and used an rPi (Raspberry Pi) to put the serial port on the network and work from another room.  That worked pretty well.  I didn't have a means of rebooting the target however.  This time I will add a capability of removing power from the test fixture to provide a reset.  
> > 
> > What I didn't try before was using this rig over the Internet.  I'm not even sure where to being digging into how to do that.  I expect it is not complicated to make the serial port accessible through the router and modem, but I'm not sure where to begin.  Or does the router even get involved and is just transparent and I only need the local IP address?  None of the sources I've found address the issue of getting through the router, etc. 
> > 
> > Essentially I want the serial port on the rPi to become a virtual serial port on a PC located anywhere else on the planet.  :) 
> 
> 1. Enable SSH on the Pi
> 2. Disable password authentication and copy an SSH key from whatever machine
> you want to connect from
> 3. Set up your router to port-forward port 22 to the Pi port 22
> 3a. (Optional) Set up dynamic DNS using someprovider, if your ISP
> doesn't offer a static IP
> 4. SSH from your laptop on the internet (or whatever) to your router
> 5. Run something like 'picocom /dev/ttyUSB0' at the prompt to start a
> terminal
> 6. Configure the Pi for automatic software updates, so it's kept up to date
> with security patches
> 
> Theo

Thanks.  From what you've written here the modem is agnostic to this process?  It's only the router I need to worry about?  

Rick C.

gnuarm.deletethisbit@gmail.com wrote:
> Thanks.  From what you've written here the modem is agnostic to this process?  It's only the router I need to worry about?  

Yes - it doesn't matter whether you're on DSL, cable, whatever.  Just that
your ISP gives you a public IP address (ie not behind some kind of firewall
that blocks inbound connections).

By forwarding a port, you're exposing an internal device.  You need to
secure it, otherwise you'll expose the rest of your internal network to
someone who manages to compromise your Pi (hence using automatic updates and
SSH keys rather than passwords is good practice).

Theo

On Tuesday, 26 February 2019 23:37:44 UTC+1, Theo  wrote:

> 3. Set up your router to port-forward port 22 to the Pi port 22

not a good idea to open port 22 to the outside world.
It's better to use another port (at least for the WAN).
And maybe install fail2ban.

Bye Jack

On 26/02/2019 23:37, Theo wrote:
> gnuarm.deletethisbit@gmail.com wrote:
>> I am working on a test fixture that uses an RS-232 port for control.  I travel a lot and don't want to have to drag the test fixture around with me.  
>>
>> Some time ago I was working with an eval board via serial port and used an rPi (Raspberry Pi) to put the serial port on the network and work from another room.  That worked pretty well.  I didn't have a means of rebooting the target however.  This time I will add a capability of removing power from the test fixture to provide a reset.  
>>
>> What I didn't try before was using this rig over the Internet.  I'm not even sure where to being digging into how to do that.  I expect it is not complicated to make the serial port accessible through the router and modem, but I'm not sure where to begin.  Or does the router even get involved and is just transparent and I only need the local IP address?  None of the sources I've found address the issue of getting through the router, etc. 
>>
>> Essentially I want the serial port on the rPi to become a virtual serial port on a PC located anywhere else on the planet.  :) 
> 
> 1. Enable SSH on the Pi

ssh is certainly a solid way to handle this - as long as the user has a
ssh client on their machine, and is comfortable with it (I have no idea
of Rick's experiences here).  For Windows, msys2 command-line ssh is my
choice, but putty is good for those that prefer a gui.

> 2. Disable password authentication and copy an SSH key from whatever machine
> you want to connect from

ssh keys make things faster and easier - but not more secure, if there
is a risk of theft of the client laptop.  (Again, I don't know the OP's
security needs.)

Password authentication is fine if the passwords are good, though
usually you don't want to allow direct root login via ssh with a
password.  Password login is an excellent back-stop for when you are in
the middle of nowhere and your laptop dies - it will let you get things
working on a new laptop without having to go back to the office first.

> 3. Set up your router to port-forward port 22 to the Pi port 22

No.  Set it up from a wildly different port.  An open port 22 is an
invite to drive-by script kiddies, and you will get regular probes.
They won't break in (since they don't have your keys and can't guess
your passwords), but they are a nuisance and a waste of bandwidth, and
/if/ there are bugs in sshd or the kernel, this hugely increases the
risk.  Use a high, unrelated port number on the outside connection -
forward port 54321 to port 22 on the Pi.  Then the will be no script
attacks.

> 3a. (Optional) Set up dynamic DNS using someprovider, if your ISP
> doesn't offer a static IP

Yes.

> 4. SSH from your laptop on the internet (or whatever) to your router

Yes.

> 5. Run something like 'picocom /dev/ttyUSB0' at the prompt to start a
> terminal

Or "screen /dev/ttyUSB0 115200", which would be my choice here.  Or run
any other serial port program locally on the Pi.

An alternative would be to use a serial port to network proxy (like
socat, which I have not tried myself), and access it over the ssh link.
 That would require doing a port forward over the ssh tunnel, but that
is quite easy.  The best choice depends on the OP's needs.

> 6. Configure the Pi for automatic software updates, so it's kept up to date
> with security patches
> 

Madness.

Automatic software updates are for ignorant Windows admins who want to
be able to say "it's not /my/ fault there was a problem".  The risk of
security problems that would be a problem for such a system (especially
on a non-standard port) is absolutely tiny.  The risk of the OP being
specifically targeted is tiny (it's for debugging a card, not for
running a bank).  The benefits of getting an update fast, rather than
when it is convenient, are tiny.  These all multiply to utterly
negligible.  On the other hand, the risk of complications, breakage, or
simply interrupt what you are doing by the automatic updates is very real.


Another possibility to consider as a way of accessing your office
devices while you are away, is a VPN.  This is particularly useful if
you need to access multiple systems and not just the one board.  I
strongly recommend OpenVPN here, and I recommend running it over TCP/IP
rather than the standard UDP.  It is not the most efficient VPN
(especially with TCP/IP), but the client can easily traverse almost any
firewall, NAT router, etc., unlike lower-level VPN's.

On 2019-02-27, David Brown <david.brown@hesbynett.no> wrote:

>> 3. Set up your router to port-forward port 22 to the Pi port 22
>
> No.  Set it up from a wildly different port.  An open port 22 is an
> invite to drive-by script kiddies, and you will get regular probes.
> They won't break in (since they don't have your keys and can't guess
> your passwords), but they are a nuisance and a waste of bandwidth, and
> /if/ there are bugs in sshd or the kernel, this hugely increases the
> risk.  Use a high, unrelated port number on the outside connection -
> forward port 54321 to port 22 on the Pi.  Then the will be no script
> attacks.

Maybe not none, but there will be far fewer attacks.  My ssh servers
running on non-standard ports still see SSH login attempts from
attackers.

-- 
Grant Edwards               grant.b.edwards        Yow! FUN is never having to
                                  at               say you're SUSHI!!
                              gmail.com            

Den 2019-02-27 kl. 09:08, skrev David Brown:
> On 26/02/2019 23:37, Theo wrote:
>> gnuarm.deletethisbit@gmail.com wrote:
>>> I am working on a test fixture that uses an RS-232 port for control.  I travel a lot and don't want to have to drag the test fixture around with me.
>>>
>>> Some time ago I was working with an eval board via serial port and used an rPi (Raspberry Pi) to put the serial port on the network and work from another room.  That worked pretty well.  I didn't have a means of rebooting the target however.  This time I will add a capability of removing power from the test fixture to provide a reset.
>>>
>>> What I didn't try before was using this rig over the Internet.  I'm not even sure where to being digging into how to do that.  I expect it is not complicated to make the serial port accessible through the router and modem, but I'm not sure where to begin.  Or does the router even get involved and is just transparent and I only need the local IP address?  None of the sources I've found address the issue of getting through the router, etc.
>>>
>>> Essentially I want the serial port on the rPi to become a virtual serial port on a PC located anywhere else on the planet.  :)
>>
>> 1. Enable SSH on the Pi
> 
> ssh is certainly a solid way to handle this - as long as the user has a
> ssh client on their machine, and is comfortable with it (I have no idea
> of Rick's experiences here).  For Windows, msys2 command-line ssh is my
> choice, but putty is good for those that prefer a gui.
> 
>> 2. Disable password authentication and copy an SSH key from whatever machine
>> you want to connect from
> 
> ssh keys make things faster and easier - but not more secure, if there
> is a risk of theft of the client laptop.  (Again, I don't know the OP's
> security needs.)
> 
> Password authentication is fine if the passwords are good, though
> usually you don't want to allow direct root login via ssh with a
> password.  Password login is an excellent back-stop for when you are in
> the middle of nowhere and your laptop dies - it will let you get things
> working on a new laptop without having to go back to the office first.
> 
>> 3. Set up your router to port-forward port 22 to the Pi port 22
> 
> No.  Set it up from a wildly different port.  An open port 22 is an
> invite to drive-by script kiddies, and you will get regular probes.
> They won't break in (since they don't have your keys and can't guess
> your passwords), but they are a nuisance and a waste of bandwidth, and
> /if/ there are bugs in sshd or the kernel, this hugely increases the
> risk.  Use a high, unrelated port number on the outside connection -
> forward port 54321 to port 22 on the Pi.  Then the will be no script
> attacks.
> 
>> 3a. (Optional) Set up dynamic DNS using someprovider, if your ISP
>> doesn't offer a static IP
> 
> Yes.
> 
>> 4. SSH from your laptop on the internet (or whatever) to your router
> 
> Yes.
> 
>> 5. Run something like 'picocom /dev/ttyUSB0' at the prompt to start a
>> terminal
> 
> Or "screen /dev/ttyUSB0 115200", which would be my choice here.  Or run
> any other serial port program locally on the Pi.
> 
> An alternative would be to use a serial port to network proxy (like
> socat, which I have not tried myself), and access it over the ssh link.
>   That would require doing a port forward over the ssh tunnel, but that
> is quite easy.  The best choice depends on the OP's needs.
> 
>> 6. Configure the Pi for automatic software updates, so it's kept up to date
>> with security patches
>>
> 
> Madness.
> 
> Automatic software updates are for ignorant Windows admins who want to
> be able to say "it's not /my/ fault there was a problem".  The risk of
> security problems that would be a problem for such a system (especially
> on a non-standard port) is absolutely tiny.  The risk of the OP being
> specifically targeted is tiny (it's for debugging a card, not for
> running a bank).  The benefits of getting an update fast, rather than
> when it is convenient, are tiny.  These all multiply to utterly
> negligible.  On the other hand, the risk of complications, breakage, or
> simply interrupt what you are doing by the automatic updates is very real.
> 

If you have a set of stuff on the Pi, dedicated for the test,
that should be refreshed, then just create a git repo somewhere with the 
test code, and let the Pi do a "git pull --rebase" periodically.
The Pi should only have read access to the repo.

AP

> 
> Another possibility to consider as a way of accessing your office
> devices while you are away, is a VPN.  This is particularly useful if
> you need to access multiple systems and not just the one board.  I
> strongly recommend OpenVPN here, and I recommend running it over TCP/IP
> rather than the standard UDP.  It is not the most efficient VPN
> (especially with TCP/IP), but the client can easily traverse almost any
> firewall, NAT router, etc., unlike lower-level VPN's.
> 
> 
> 
> 
> 

On 27/02/2019 18:45, A.P.Richelieu wrote:

> If you have a set of stuff on the Pi, dedicated for the test,
> that should be refreshed, then just create a git repo somewhere with the 
> test code, and let the Pi do a "git pull --rebase" periodically.

If the test program(s) are running on the Pi, then you need some way to 
get them onto the Pi and to keep them updated with any changes.  git is 
one way to share a set of source files.  But there is nothing special 
about it - the OP should use whatever makes sense to him and whatever 
suits his current practices.

One thing for sure is that automatic rebases are probably a very bad 
idea - just like any other automatic updates.  Connect to the Pi with 
ssh, and do an update when you are ready to test the new software - not 
before.


One thing I didn't mention earlier - when running programs via ssh on a 
setup like this, run them within "screen" (or "tmux") on the Pi.  Then 
the terminals and programs stay alive even if you disconnect the ssh and 
connect again later.


 > The Pi should only have read access to the repo.
 >

That is an arbitrary restriction which may not be appropriate.  (It 
doesn't even make much sense - /users/ have access to a repo, not 
/computers/.)  If the OP is happy fiddling with the software using nano 
over ssh, then he should be able to check in changes - there is no 
reason to force a specific direction to the development process.

Den 2019-02-27 kl. 21:25, skrev David Brown:
> On 27/02/2019 18:45, A.P.Richelieu wrote:
> 
>> If you have a set of stuff on the Pi, dedicated for the test,
>> that should be refreshed, then just create a git repo somewhere with 
>> the test code, and let the Pi do a "git pull --rebase" periodically.
> 
> If the test program(s) are running on the Pi, then you need some way to 
> get them onto the Pi and to keep them updated with any changes.  git is 
> one way to share a set of source files.  But there is nothing special 
> about it - the OP should use whatever makes sense to him and whatever 
> suits his current practices.
> 
> One thing for sure is that automatic rebases are probably a very bad 
> idea - just like any other automatic updates.  Connect to the Pi with 
> ssh, and do an update when you are ready to test the new software - not 
> before.
> 
> 
> One thing I didn't mention earlier - when running programs via ssh on a 
> setup like this, run them within "screen" (or "tmux") on the Pi.  Then 
> the terminals and programs stay alive even if you disconnect the ssh and 
> connect again later.
> 
> 
>  > The Pi should only have read access to the repo.
>  >
> 
> That is an arbitrary restriction which may not be appropriate.  (It 
> doesn't even make much sense - /users/ have access to a repo, not 
> /computers/.)  If the OP is happy fiddling with the software using nano 
> over ssh, then he should be able to check in changes - there is no 
> reason to force a specific direction to the development process.

Not really, if you give write access, it will be possible for anyone
that can break into the Pi to get write access to your repo.
Breaking in, consists of removing the SD-Card and mounting it in your 
laptop, after which you can copy the ssh private key.
Not a good idea.

The important part of git is that this is something that the Pi
starts, not something that is pushed into the Pi.

It is certainly a good idea to update the Pi automatically
with the latest test suite.
If you find you have a problem, you can easily revert to an older commit.
Obviously you should be able to disable the automatic update,
if for some reason you do not like to use the latest version.

AP