ssh

55 Articles

Grant Anyone Temporary Permissions To Your Computer With SSH

February 5, 2017 by 33 Comments

This is a super cute hack for you Linux users out there. If you have played around with SSH, you know it’s the most amazing thing since sliced bread. For tunneling in, tunneling out, or even just to open up a shell safely, it’s the bees knees. If you work on multiple computers, do you know about ssh-copy-id? We had been using SSH for years before stumbling on that winner.

Anyway, [Felipe Lavratti]’s ssh-allow-friend script is simplicity itself, but the feature it adds is easily worth the cost of admission. All it does is look up your friend’s public key (at the moment only from GitHub) and add it temporarily to your authorized_keys file. When you hit ctrl-C to quit the script, it removes the keys. As long as your friend has the secret key that corresponds to the public key, he or she will be able to log in as your user account.

Continue reading “Grant Anyone Temporary Permissions To Your Computer With SSH” →

SSH Enters The Mosh Pit

November 1, 2016 by 8 Comments

With so many systems depending on Linux, the secure shell SSH has become a staple for many developers. If you are connected to your Raspberry Pi via a cable or a wireless router a few feet away, SSH can provide you with an encrypted connection straight to the box. However, if you have a system out in a swamp somewhere with intermittent slow network access, SSH can be a real pain. When your IP address can change (for example, roaming on a cellular network), SSH has problems, too.

To combat these and other problems, you might consider an open source program called Mosh (mobile shell). There’s two parts to Mosh. One part works as a server while the other is the client application. Neither of these require root access. You can see a video about Mosh below.

Continue reading “SSH Enters The Mosh Pit” →

When Your Screen Breaks In The Himalayas

October 24, 2016 by 26 Comments

If you’ve ever had the screen break on your laptop, you’ll know it can be rather annoying to have to use an external monitor for a while as you either wait for a replacement panel to arrive from the other side of the world, or wait for that new laptop you were just desperate for an excuse to upgrade to.

Spare a thought, then, for [tom bh] whose laptop screen broke while he was in Ladakh, Northern India. Two days bus ride from the nearest city in which he could hope to source a replacement part, he had to make do with the resources in front of him. A laptop with a broken screen, and his Android phone.

He was fortunate in that a few lines at the top of the screen still worked intermittently. So after logging in blind and finding himself in a shell, he could execute commands and then scroll the results up to the point at which they were visible. He first enabled an SSH server, then connected his phone via USB. A bit of work to find the laptop’s IP address, and he could get himself a laptop shell on his phone with an Android SSH client. He goes into detail about how he was able to use the laptop’s keyboard to emulate a Bluetooth device which he connected to the phone. He could then run a VNC server on the laptop and connect to it with a VNC client on the phone, resulting in a phone-sized laptop display using the laptop’s keyboard as input. Not a perfect physical terminal by any means, but enough for him to continue working.

His writeup is an especially interesting read for its side-by-side evaluation of the various different application choices he made, and contains some useful suggestions as to how anyone might prepare themselves for a dead screen related emergency.

We’ve featured a dead-screen laptop connected as a serial terminal with an Arduino in the past, but unlike this one that only gave its owner a prompt.

Via Hacker News.

Lock Up Your Raspberry Pi With Google Authenticator

September 30, 2016 by 14 Comments

Raspberry Pi boards (or any of the many similar boards) are handy to leave at odd places to talk to the network and collect data, control things, or do whatever other tasks you need a tiny fanless computer to do. Of course, any time you have a computer on a network, you are inviting hackers (and not our kind of hackers) to break in.

We recently looked at how to tunnel ssh using a reverse proxy via Pagekite so you can connect to a Pi even through firewalls and at dynamic IP addresses. How do you stop a bad guy from trying to log in repeatedly until they have access? This can work on any Linux machine, but for this tutorial I’ll use Raspberry Pi as the example device. In all cases, knowing how to set up adequate ssh security is paramount for anything you drop onto a network.

Continue reading “Lock Up Your Raspberry Pi With Google Authenticator” →

Apple Aftermath: Senate Entertains A New Encryption Bill

April 11, 2016 by 62 Comments

If you recall, there was a recent standoff between Apple and the U. S. Government regarding unlocking an iPhone. Senators Richard Burr and Dianne Feinstein have a “discussion draft” of a bill that appears to require companies to allow the government to court order decryption.

Here at Hackaday, we aren’t lawyers, so maybe we aren’t the best source of legislative commentary. However, on the face of it, this seems a bit overreaching. The first part of the proposed bill is simple enough: any “covered entity” that receives a court order for information must provide it in intelligible form or provide the technical assistance necessary to get the information in intelligible form. The problem, of course, is what if you can’t? A covered entity, by the way, is anyone from a manufacturer, to a software developer, a communications service, or a provider of remote computing or storage.

There are dozens of services (backup comes to mind) where only you have the decryption keys and there is nothing reasonable the provider can do to get your data if you lose your keys. That’s actually a selling point for their service. You might not be anxious to backup your hard drive if you knew the vendor could browse your data when they wanted to do so.

The proposed bill has some other issues, too. One section states that nothing in the document is meant to require or prohibit a specific design or operating system. However, another clause requires that covered entities provide products and services that are capable of complying with the rule.

A broad reading of this is troubling. If this were law, entire systems that don’t allow the provider or vendor to decrypt your data could be illegal in the U. S. Whole classes of cybersecurity techniques could become illegal, too. For example, many cryptography systems use the property of forward secrecy by generating unrecorded session keys. For example, consider an SSH session. If someone learns your SSH key, they can listen in or interfere with your SSH sessions. However, they can’t take recordings of your previous sessions and decode them. The mechanism is a little different between SSHv1 (which you shouldn’t be using) and SSHv2. If you are interested in the gory details for SSHv2, have a look at section 9.3.7 of RFC 4251.

In all fairness, this isn’t a bill yet. It is a draft and given some of the definitions in section 4, perhaps they plan to expand it so that it makes more sense, or – at least – is more practical. If not, then it seems to be an indication that we need legislators that understand our increasingly technical world and have some understanding of how the new economy works. After all, we’ve seen this before, right? Many countries are all too happy to enact and enforce tight banking privacy laws to encourage deposits from people who want to hide their money. What makes you think that if the U. S. weakens the ability of domestic companies to make data private, that the business of concealing data won’t just move offshore, too?

If you were living under a rock and missed the whole Apple and FBI controversy, [Elliot] can catch you up. Or, you can see what [Brian] thought about Apple’s response to the FBI’s demand.

How The NSA Can Read Your Emails

October 15, 2015 by 86 Comments

Since [Snowden]’s release of thousands of classified documents in 2013, one question has tugged at the minds of security researchers: how, exactly, did the NSA apparently intercept VPN traffic, and decrypt SSH and HTTP, allowing the NSA to read millions of personal, private emails from persons around the globe? Every guess is invariably speculation, but a paper presented at the ACM Conference on Computer and Communications Security might shed some light on how the NSA appears to have broken some of the most widespread encryption used on the Internet (PDF).

The relevant encryption discussed in the paper is Diffie–Hellman key exchange (D-H), the encryption used for HTTPS, SSH, and VPN. D-H relies on a shared very large prime number. By performing many, many computations, an attacker could pre-compute a ‘crack’ on an individual prime number, then apply a relatively small computation to decrypt any individual message that uses that prime number. If all applications used a different prime number, this wouldn’t be a problem. This is the difference between cryptography theory and practice; 92% of the top 1 Million Alexa HTTPS domains use the same two prime numbers for D-H. An attacker could pre-compute a crack on those two prime numbers and consequently be able to read nearly all Internet traffic through those servers.

This sort of attack was discussed last spring by the usual security researchers, and in that time the researchers behind the paper have been hard at work. The earlier discussion focused on 512-bit D-H primes and the LogJam exploit. Since then, the researchers have focused on the possibility of cracking longer 768- and 1024-bit D-H primes. They conclude that someone with the resources of cracking a single 1024-bit prime would allow an attacker to decrypt 66% of IPsec VPNs and 26% of SSH servers.

There is a bright side to this revelation: the ability to pre-compute the ‘crack’ on these longer primes is a capability that can only be attained by nation states as it’s on a scale that has been compared to cracking Enigma during WWII. The hardware alone to accomplish this would cost millions of dollars, and although this computation could be done faster with dedicated ASICs or other specialized hardware, this too would require an enormous outlay of cash. The downside to this observation is, of course, the capability to decrypt the most prevalent encryption protocols may be in the hands of our governments. This includes the NSA, China, and anyone else with hundreds of millions of dollars to throw at a black project.

Raspberry Pi And Kindle Together Again

April 30, 2015 by 11 Comments

We’ve seen a lot of projects recently that take advantage of the Raspberry Pi 2’s augmented abilities. With the increased processor power and double the memory, it puts a lot more utility in the user’s hands. The latest project that takes advantage of this is the Pi-nk, which combines a Pi with a Kindle for some text-based awesomeness. [Edit: Use the Wayback Machine.]

[Guillaume] has put together this detailed how-to which, unlike other builds we’ve seen in the past, uses wireless instead of USB for almost all of the connections, including the keyboard. Granted, this isn’t a new idea, but he’s presenting the way that he did it. To that end, all of the commands you’ll need to use are extremely well documented on the project page if you want to build your own. When everything is said and done, you’ll be SSHing into the Pi from the Kindle and using the popular “screen” program to get the Pi to use the Kindle as its display.

Additionally, [Guillaume] has posted some schematics for custom enclosures for the Pi-Kindle pair if you’re more ambitious. He points out that the e-ink display is great if the Pi is being run in text or command-line mode, and we’d have to agree. This is a very clean pairing of these devices and puts the strengths of both to great use!