Remote Debugging

Started by February 26, 2019
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.&nbsp; git is > one way to share a set of source files.&nbsp; 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.&nbsp; 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.&nbsp; 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.&nbsp; (It > doesn't even make much sense - /users/ have access to a repo, not > /computers/.)&nbsp; 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