Linux Fu: Simple SSH File Sharing

If you have more than one Linux computer, you probably use ssh all the time. It is a great tool, but I’ve always found one thing about it strange. Despite having file transfer capabilities in the form of scp and sftp, there is no way to move a file back or forth between the local and remote hosts without starting a new program on the local machine or logging in from the remote machine back to the local machine.

That last bit is a real problem since you often access a server from behind a firewall or a NAT router with an ephemeral IP address, so it can’t reconnect to you anyway. It would be nice to hit the escape character, select a local or remote file, and teleport it across the  interface, all from inside a single ssh session.

I didn’t quite get to that goal, but I did get pretty close. I’ll show you a script that can automatically mount a remote directory on the local machine. You’ll need sshfs on the local machine, but no changes on the remote machine where you may not be able to install software. With a little more work, and if your client has an ssh server running, you can mount a local directory on the remote machine, too. You won’t need to worry about your IP address or port blocking. If you can log into the remote machine, you are good.

Combined, this got me me very close to my goal. I can be working in a shell on either side and have access to read or write files on the other side. I just have to set it up carefully. Continue reading “Linux Fu: Simple SSH File Sharing”

GitHub’s Move Away From Passwords: A Sign Of Things To Come?

Later this month, people who use GitHub may find themselves suddenly getting an error message while trying to authenticate against the GitHub API or perform actions on a GitHub repository with a username and password. The reason for this is the removal of this authentication option by GitHub, with a few ‘brown-out’ periods involving the rejection of passwords to give people warning of this fact.

This change was originally announced by GitHub in November of 2019, had a deprecation timeline assigned in February of 2020 and another blog update in July repeating the information. As noted there, only GitHub Enterprise Server remains unaffected for now. For everyone else, as of November 13th, 2020, in order to use GitHub services, the use of an OAuth token, personal token or SSH key is required.

While this is likely to affect a fair number of people who are using GitHub’s REST API and repositories, perhaps the more interesting question here is whether this is merely the beginning of a larger transformation away from username and password logins in services.

Continue reading “GitHub’s Move Away From Passwords: A Sign Of Things To Come?”

Linux Fu: Remote Execution Made Easy

If you have SSH and a few other tools set up, it is pretty easy to log into another machine and run a few programs. This could be handy when you are using a machine that might not have a lot of memory or processing power and you have access to a bigger machine somewhere on the network. For example, suppose you want to reencode some video on a box you use as a media server but it would go much faster on your giant server with a dozen cores and 32 GB of RAM.

Remote Execution

However, there are a few problems with that scenario. First, you might not have the software on the remote machine. Even if you do, it might not be the version you expect or have all the same configuration as your local copy. Then there’s the file problem. the input file should come from your local file system and you’d like the output to wind up there, too. These aren’t insurmountable, of course. You could install the program on the remote box and copy your files back and forth manually. Or you can use Outrun.

There are a few limitations, though. You do need Outrun on both machines and both machines have to have the same CPU architecture. Sadly, that means you can’t use this to easily run jobs on your x86-64 PC from a Raspberry Pi. You’ll need root access to the remote machine, too. The system also depends on having the FUSE file system libraries set up.

Continue reading “Linux Fu: Remote Execution Made Easy”

Linux Fu: Stupid SSH Tricks

If you connect to remote computers over the Internet, it is a pretty good chance you use some form of SSH or secure shell. On Linux or Unix you’ll use the ssh command. Same goes for Linux-like environments on Windows like Cygwin or WSL. For native Windows, you might be using Putty. In its simplest form, ssh is just a terminal program that talks to a server using an encrypted connection. We think it is very hard to eavesdrop on anyone communicating with a remote computer via ssh.

There are several tricks for using ssh — some are pretty straightforward and some are things you might not think of as being in the domain of a terminal program. You probably know that ssh can copy files securely, and there are easy and hard ways to set up logging in with no password.

However, you can also mount a remote filesystem via ssh (actually, there are several ways to do that). You can use ssh to securely browse the web in your favorite browser, or even use it to tunnel specific traffic by port or even use it as a makeshift VPN. In fact, there’s so much ground to cover that this won’t be the last Linux Fu to talk about ssh. But enough setup, let’s get to the tricks.

Continue reading “Linux Fu: Stupid SSH Tricks”

Linux Fu: Interactive SSH Applications

[Drew DeVault] recently wrote up some interesting instructions on how to package up interactive text-based Linux commands for users to access via ssh. At first, this seems simple, but there are quite a few nuances to it and [Drew] does a good job of covering them.

One easy way — but not very versatile — is to create a user and make the program you want to run the default shell. The example used is to make /usr/bin/nethack the shell and now people can log in as that user and play nethack. Simple, right? However, there are better ways to get there.

Continue reading “Linux Fu: Interactive SSH Applications”

This Week In Security: Backdoors In Cisco Switches, PGP Spoofing In Emails, Git Ransomware

Some switches in Cisco’s 9000 series are susceptible to a remote vulnerability, numbered CVE-2019-1804 . It’s a bit odd to call it a vulnerability, actually, because the software is operating as intended. Cisco shipped out these switches with the same private key hardcoded in software for all root SSH logins. Anyone with the key can log in as root on any of these switches.

Cisco makes a strange claim in their advisory, that this is only exploitable over IPv6. This seems very odd, as there is nothing about SSH or the key authentication process that is IPv6 specific. This suggests that there is possibly another blunder, that they accidentally left the SSH port open to the world on IPv6. Another possibility is that they are assuming that all these switches are safely behind NAT routers, and therefore inaccessible through IPv4. One of the advantages/disadvantages of IPv6 is that there is no NAT, and all the network devices are accessible from the outside network. (Accessible in the sense that a route exists. Firewalling is still possible, of course.)

It’s staggering how many devices, even high end commercial devices, are shipped with unintentional yet effective backdoors, just like this one. Continue reading “This Week In Security: Backdoors In Cisco Switches, PGP Spoofing In Emails, Git Ransomware”

The Linux Throwie: A Non-Spacefaring Satellite

Throwies occupy a special place in hardware culture — a coin cell battery, LED, and a magnet that can be thrown into an inaccessible place and stick there as a little beacon of colored light. Many of us will fondly remember this as a first project. Alas, time marches inevitably on, and launching cheerful lights no longer teaches me new skills. With a nod to those simpler times, I’ve been working on the unusual idea of building a fully functional server that can be left in remote places and remain functional, like a throwie (please don’t actually throw it). It’s a little kooky, yet should still deliver a few years of occasional remote access if you leave it somewhere with sunlight.

A short while ago, I described the power stages for this solar-powered, cloud accessible Linux server. It only activates on demand, so a small solar cell and modest battery are sufficient to keep the whole show running.

Where we left off, I had a solar cell that could charge a battery, and provide regulated 12 V and 5 V output. For it to be a functional device, there are three high level problems to solve:

  1. It must be possible to set up the device without direct physical access
  2. You must be able to remotely turn it on and off as needed.
  3. It needs to be accessible from the Internet.

The funny thing is, this hardware reminds me of a satellite. Of course it’s not meant to go into space, but I do plan to put it somewhere not easy to get to again, it runs off of solar power, and there’s a special subsystem (ESP8266) to tend the power, check for remote activation, and turn the main computer (Raspberry Pi 3) on and off as necessary. This sounds a lot like space race tech, right?

As I have a bit more code than usual to share with you today, I’ll discuss the most interesting parts, and provide links to the full firmware files at the end of the article.

Continue reading “The Linux Throwie: A Non-Spacefaring Satellite”