Any way to remotely transfer files to/from Retropie?

[sub_atomic]

I'm building a Retropie for my nephew who is too young to be able to edit gamelists, update configs, add roms, etc. Plus they live in another state. Is there any way to set up a remote connection so that I can SSH in from my house? Everything I search for comes up with instructions for connecting on the same network.

Thanks.

[piratefish]

I'd say the easiest way to connect to your nepews pie via ssh would be to connect to a PC in his network with a remote maintenance tool like VNC (TightVNC for example) and then connect via ssh (with putty for example) to his pie.

Depending on how tech-savy you are setting up a VNC connection is not terribly difficult.

Hope that helps.

[piratefish]

A more secure way would be to forward the SSH TCP port in your nephews router to his pie. And thinking about it that might even be easier than setting up a VNC connection.

Depending on the router in use forwarding ports is very easy. Then you only need his current IP-Adress (or you set up a DynDNS if you want to be able to connect at any time) and establish a ssh-connection to it. It should be forwarded to the pie and voilà you are in.

[piratefish]

Some more thoughts now that I had some time to think (the first two replies where just the first things that came to my mind just before I left work):

If you are looking for a short term and/or "on demand" solution (only used when your nephew askes for help) use the method without DynDNS (your nephew needs to tell you the current public IP adress of his router every time) and be sure to turn on the ssh port forwarding only when needed so ist does not get
abused.

If you are looking for a more permanent and/or long term solution (to ssh into the pie whenever) use the method with DynDNS (a lot of routers support DynDNS) and be sure to set a VERY strong password on the pie (for user pi which is used for ssh connections).

Tools to use for ssh from a Windows PC:

putty - a Windows ssh client
WinSCP - a Windows program to transfer files over ssh

Cheers!

[sub_atomic]

Great! Thanks for the help, @piratefish. I'm going to have to work with his dad to get that set up, but sounds like it shouldn't be too hard. I appreciate it!

[piratefish]

@sub_atomic You're welcome! If the router supports port forwarding (which most routers do) it should be a piece of cake (or a piece of pie ;-). Let me know if it works.

Cheers!

[markyh444]

I'd advise against port forwarding, especially for a common protocol like SSH out to the internet as it begs to be exploited.

The initial idea of setting up a remote session to a pc then SSH to the Pi is much better. You could use something like logmein which can be initiated from their end easily when they want some help copying new files to the Pi.

[Raistlin84]

Hi, the safest way is a VPN, many router support it. Connect to the VPN, and then with sshfs (need to install the server package in retropie) you can mount the remote filesystem. No security issue, a bit more complicated, but much better.

[Roken]

scp allows you to copy files over ssh without any fancy shenanigans. https://en.wikipedia.org/wiki/Secure_copy

[Clyde]

Hi @markyh444, could you please elaborate why you'd prefer a remote session to "a pc" (I presume that you mean Windows by that) to an direct ssh connection? I'm having reservations against that approach, because

1. most remote access solutions would also require port forwarding, those who don't usually rely on external third-party servers which are a security liability by themself,
2. every additional layer of complexity (here: the pc's OS and its remote access software) increases the attack surface,
3. in contrast, Retropie's minimal system without a desktop environment is much less complex than any extensive desktop OS,
4. SSH is made for secure remote access, and
5. its port can be changed to a less common one, although there are reasons to think that this is a bad idea.

For these reasons, I'd rather recommend a direct SSH connection with a strong passphrase or, even better, public key authentication to a Retropie system that should be updated regularly.

Please don't take this offensively, I'm just curious and I'd welcome a fruitful discussion about our different views in this matter, if you like. 😌 Of course, this applies to anyone reading this.

edit: typo 😒

[mitu]

@clyde Having an always-on SSH server exposed to the internet is always a risk to have your password brute-forced - see https://www.theregister.co.uk/2017/06/13/linuxmuldrop14_malware_for_raspberry_pi/. If you don't change your PI password from the default - as I assume most users don't - you'll get your system cracked easily. See this topic for an actual case of a RetroPie user.

If you use something like TeamViewer/LogmeIn, you don't need to open any additional ports and since the connection is always performed on-demand, there's an additional confirmation from the connecting parties so there's no risk of somebody else connecting to your system.

I second @markyh444 suggestion - if you don't need to permanently be connected to the system, then use something like TeamViewer, it's much safer and more user friendly (especially for non-technical users).

[Clyde]

@mitu Thanks for your reply. I highly doubt that a closed-source software that circumvents router's firewalls by connecting to a third-party server is safer than an up to date SSH with a strong passphrase or public key authentication. The former may seem more convenient to the average (Windows) user, but I rate it as potentially less than more secure. See TeamViewer: Fraudulent Uses and LogMeIn Hamachi: Security for some examples as well as general security and privacy concerns.

That said, you can also use bad passwords in remote viewers, and you can also start ssh only on demand, edit: or open its ports only if needed, so I don't see those arguments in favour of the viewers. Your example doesn't say anything about SSH vs. remote viewers, but everything about weak vs. strong authentication.

[mitu]

@clyde said in Any way to remotely transfer files to/from Retropie?:

See TeamViewer: Fraudulent Uses and LogMeIn Hamachi: Security for some examples as well as general security and privacy concerns.

Just as an always-on connection for SSH poses an brute-force security risk, if you configure TeamViewer/LogmeIn as a windows service and exposed to the internet you'll get the same exposure and risk, and the same can be said for any public facing log in service (RDP). However, starting them on-demand, just when you need to connect, will not pose the same risk since there's no listening port and the connection is always approved by the destination user. For me, that's always safer than letting SSH open to the internet.

[markyh444]

@clyde any remote connection exposed to the internet is a security risk. I'm a Cisco network engineer with 13 years experience and know the risks fairly well. As @mitu said, a common protocol left open is a risk to brute force attacks and exploits and I would only recommend using them if you know what you're doing and can isolate and/or protect the risk on your network. As this situation seems to involve non-technical users, a remote session to the machine via logmein or TeamViewer then SSH to the Pi makes much more sense to me. I agree that these are not without risk as well, but if only ran when required, then it should be ok. Also, it required less technical know-how that enabling and disabling port forwarding or SSH on demand imho.

[DorkVonWaterfall]

teamviewer and putty?

[jasonw]

What I would do if one of you have a decent (not cable company provided) router, set up a VPN server on the router (OpenVPN is pretty easy and has tutorials). Then the other would use their OpenVPN client to connect. Then it will be just like you are on the same network.

[piratefish]

@markyh444 I agree with you that any remote connection is a security risk, sure. Not to have an opening is ofcourse more secure than to have one, as well guarded as it might be.

But I think it's not that big of a risk to leave an ssh connection exposed to the internet. As long as you set a decently strong password (I'm talking 20-30 random characters) you will be fine. The connection has to be targeted specifically (while the Pi is running or otherwise there would not be anything to target) to be brute forced or otherwise exploited which is pretty unlikely. Plus, as I suggested, the port forwarding can be disabled when not needed to further lower the risk of abuse, which should of course always be preffered to leaving the connection exposed.

Yeah, using programs like logmein or teamviewer might be slightly easier but imo port forwarding is pretty much a nobrainer with most modern (consumer) routers and besides not everybody is comfortable with using connections which are established through third party servers (those connections and connection attempts can also be tempered with).

Cheers!

[Sano]

@piratefish
I would add, if you want to leave an SSH server exposed :

• Set a strong (obviously no-default) password
• Choose a random/non-default port (aka not 22). Most bots try default ports.
• Use an utility like fail2ban to avoid brute force.

With those rules, I had a computer with ssh exposed for many years without issue, but I kind of knew what I was doing and checked the logs on a regular basis., as well as potential rootkits
I second the VPN solution, as well as the on-demand remote application.

[piratefish]

@sano Agreed! Further security measures never hurt! If you know how to set them up, do so! :)

Just to be clear, remote applications are imo fine to use as well.

VPN would also be my personal preffered method to be honest. I just thought it might be to hard to set up properly (which is integral for security; a sloppily set up VPN might work, but might also easily be less secure than a forwarded ssh connection).
Plus, just for the record, a VPN suffers from the same "problem" of being a constantly exposed connection. ;-)

Cheers!

[markyh444]

@piratefish I understand that you can take measures to secure your SSH connection, which was why I said I wouldn't recommend it to people who didn't know what they were doing. If you have the technical knowledge, and can limit/isolate the risk posed, then that's fine.

The original post suggests an OK amount of technical knowledge, but not enough to recommend it as the best option in this instance.