Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #28568

Re: Remote Debugging

Show all headers | View raw

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.
> 
> 
> 
> 
> 

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Remote Debugging gnuarm.deletethisbit@gmail.com - 2019-02-26 13:42 -0800
  Re: Remote Debugging Theo <theom+news@chiark.greenend.org.uk> - 2019-02-26 22:37 +0000
    Re: Remote Debugging gnuarm.deletethisbit@gmail.com - 2019-02-26 15:39 -0800
      Re: Remote Debugging Theo <theom+news@chiark.greenend.org.uk> - 2019-02-27 01:32 +0000
    Re: Remote Debugging Jack <jack4747@gmail.com> - 2019-02-26 22:49 -0800
    Re: Remote Debugging David Brown <david.brown@hesbynett.no> - 2019-02-27 09:08 +0100
      Re: Remote Debugging Grant Edwards <invalid@invalid.invalid> - 2019-02-27 14:49 +0000
      Re: Remote Debugging "A.P.Richelieu" <aprichelieu@gmail.com> - 2019-02-27 18:45 +0100
        Re: Remote Debugging David Brown <david.brown@hesbynett.no> - 2019-02-27 21:25 +0100
          Re: Remote Debugging "A.P.Richelieu" <aprichelieu@gmail.com> - 2019-02-27 22:12 +0100
            Re: Remote Debugging David Brown <david.brown@hesbynett.no> - 2019-02-27 23:00 +0100
              Re: Remote Debugging "A.P.Richelieu" <aprichelieu@gmail.com> - 2019-02-27 23:28 +0100
                Re: Remote Debugging David Brown <david.brown@hesbynett.no> - 2019-02-27 23:50 +0100
  Re: Remote Debugging gnuarm.deletethisbit@gmail.com - 2019-02-27 15:41 -0800
    Re: Remote Debugging David Brown <david.brown@hesbynett.no> - 2019-02-28 01:23 +0100
      Re: Remote Debugging gnuarm.deletethisbit@gmail.com - 2019-02-27 17:41 -0800
      Re: Remote Debugging gnuarm.deletethisbit@gmail.com - 2019-02-27 17:49 -0800
        Re: Remote Debugging edward.ming.lee@gmail.com - 2019-02-27 18:00 -0800
          Re: Remote Debugging gnuarm.deletethisbit@gmail.com - 2019-02-27 18:08 -0800
            Re: Remote Debugging Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2019-02-28 11:21 +0200
        Re: Remote Debugging David Brown <david.brown@hesbynett.no> - 2019-02-28 09:09 +0100
          Re: Remote Debugging gnuarm.deletethisbit@gmail.com - 2019-02-28 15:27 -0800
            Re: Remote Debugging David Brown <david.brown@hesbynett.no> - 2019-03-01 10:11 +0100
  Re: Remote Debugging Les Cargill <lcargill99@comcast.com> - 2019-02-27 22:07 -0600
  Re: Remote Debugging Paul Rubin <no.email@nospam.invalid> - 2019-02-27 21:35 -0800

csiph-web