Grant Anyone Temporary Permissions To Your Computer With SSH

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.

There’s really nothing going on here that you couldn’t do by hand. The script simply automates creating and removing the public key, and uses GitHub as an arbiter of your friend’s identity. If you know their GitHub user name for sure, and they have attached their public key to the account, this is a very streamlined and simple procedure. (We tried it out ourselves, only to find that we hadn’t associated a public SSH key with our account.) That said, it can be extended to any trusted location that serves up public keys.

Looking through our musty archives for an article on SSH tips and tricks, we couldn’t find one. Is that possible, commenteers? That’s something we’ll have to get right on top of so send us your favorite SSH magic. In the mean time, we’ll placate your lust for more Hackaday by tossing up [Al Williams]’s nice writeup of MOSH, a mobile SSH client.

33 thoughts on “Grant Anyone Temporary Permissions To Your Computer With SSH

  1. SSH is an amazing tool, I use both Linux (normally servers) and Windows (desktop/Laptop) so when I want to use a windows SSH client I use WinSCP it’s a great little tool which turns your SFTP session into a graphical drag and drop wonderland it also has PuTTY integrated so you can click your way to the directory of choice then open a Terminal there, no more “CD . I still use the likes of PuTTY If I am logging in to run a few commands.
    I bet a lot of you already know about this but I thought I would just bring it up it may help someone out there, Especially the people who are not very familiar with Linux.

  2. Although I’m guilty of sometimes using authorized_keys to ssh and scp to machines w/o a password, it is terribly bad practice esp if one of the machines is out in the public

    Another I thing I do w/my public servers – They are constantly being pen-tested on ssh port 22. So I use the Port option in sshd_config to listen on another port. PIck a memorable number between 1024 and 65535 that is not in /etc/services. You can then easily specify this port as ‘ssh -p xxxx’ or scp ‘-P xxxx’ or in your putty config..

    There also needs to be an article about the glories of putty

      1. it does work pretty well. my home server has its sshd running on some obscure port, and i hardly get any login attempts. (this port doesn’t even show up on shodan and the likes, while the ip is definitely tracked by all of them)

        i then had to log in from where said port was blocked, and switched to port 22 for just a few hours, and was flooded with attempts to log in with root and admin accounts.

    1. Hmm – Per-user authorised_keys is the preferred method of login. There’s nothing to be guilty about there, unless your private keys are not secured (to a suitable level)

      Moving ssh from port 22 won’t stop you being scanned or login attempts as the ‘better scripts’ port scans you first and determines the service running.

      Port knocking (mentioned) is just more obfuscation, you probably want to use something like fail2ban – but let’s hope you don’t get yourself locked out eh?

      1. Moving from port 22 will protect you, as everyone who’s done it can attest. Sure, someone could spend half an hour portscanning you, but they’re better off trying 65,000 other IPs, looking for the ones which haven’t, as, in any case, if you’ve moved the port, you’re clearly somewhat aware about security, and the chances of pi/raspberry logging them in are rapidly approaching zero.

    2. Use fail2ban, Luke. It checks logs, if there are more than,say 10 attempts at login – it bans the IP for 10 minutes. Also works with other services too, just give it a rule to match the log files.

      1. That only somehow works for brute force single ip fast scans used by script kiddies.

        Nowadays botnets of tens of thousands of zombies slowly scans single ips over days, weeks or even months.

    3. There is absolutely no reason to feel guilty about using a key to login via SSH. Keys are far more secure than a password as long as you don’t have your private key where people can get to it. You can also secure your private key with a password (generally when you create a private/public key pair the program will ask you to secure the private key with a password by default) for an added layer of security… just in case one of your PCs is compromised, the attacker can’t just gain access to all your other PCs/servers.

      I have two VPSs, and I have set SSH up on both so that you cannot use a password to log in. You MUST have a valid SSH key to log in, and fail2ban will drop all traffic from any IP that has tried to log in unsuccessfully multiple times in a few minutes. Also, I set it up so that you cannot log in as root at all (you have to log in as a user and use sudo). If, for any reason, I lose all my private keys (one unique key for my user on each computer… i.e. one key each on my desktop, laptop, and phone), then I will have to log in to my VPS account use their web-based remote access console and log in with a username and password as if I was sitting right by the server (KVM over IP).

      1. That’s the way you should do it! Unfortunately it gets quite tedious to add a new laptop when you have more than 5 servers to connect to (Raspberry 2, zero, banana pro, VPS, github…)

        Hackaday, pleeeease add security remarks to your articles. Not everbody will – and especially beginners won’t – understand what it means to give somebody access via SSH. Have you noticed that this access can be used to tunnel into your LAN and possibly tamper with your devices there?

    4. You have it backwards, using a password instead of keys with ssh is bad practice. No password logins is really want you want if you aren’t able to go to a 2FA method. Make sure your private keys are encrypted with a password, but you can use a session manager to temporarily remember them so you don’t have to input your relatively strong password so frequently.

  3. “””(((…))), he or she will be able to log in as your user account.”””
    SCARY!

    Why should this be needed?
    Why not readonly via `screen` or `tmux`?
    And if at all, why not the other way round? Make an account for that friend and meet there instead of opening your normal account.

    1. I don’t think this is a good idea either.

      It’s fairly pointless, the reason this doesn’t exist is from a security POV once they are in you should not expect that they can’t renter I.e. Have a backdoor

  4. Personally I feel password is more secure. But ultimately it comes down to rotating authentication. If you force change a password every n days, at least the auth token has timed validity if it does get hacked. The same should apply to authorized keys to be ‘as or more secure’. Both I and I have known people that copy id.pub around to dozens of systems and are never challenged for decades at a time.

    But I do go one step further with password authentication. I have a custom-nightly log scanner that email alerts when a new IP address pops up on a user’s from. Of course prevent all remote root logins. And set very aggressive f2b policies. 3 attempts will kill an IP for days for my public servers.

  5. Depending on the usecase, I would suggest tmate ( http://tmate.io ) which has the benefit of not needing the host to be publicly accessible from the internet. It does not, however, ensure only one specific person is using the session. It does, however, provide a read-only session, which can be nice.

  6. Most VPS or leased rack users have little to no insight into the level of access the cloud administrators have to their system images.

    Password-less systems are convenient, but keys are easily captured automatically in 0-day leaks and or Host malware.
    These are very common on Android phones, Apple iOS, and Windows (built into the operating system now).

    People use password protected SSL certs for the same reason, as when (not if) your server is eventually compromised/modified — the users are notified with an invalid cert warning (assuming you added your specific key cert to your client key rings, and the signing authority has not reissued another valid signed cert for the domain).

    Private Dropbox style access to your servers:
    sshfs did have limited support for other platforms at one time, but your days are numbered if you are still using Apple/Microsoft products in an administrative roll in these modern times.

  7. Thanks for the ideas guys. I’ll add some of them to do script. You are all invited to contribute.

    The script is better used as a shortcut to let a friend (probably sitting next to you) to login into your box in the same local network for some fast task. Like, when you need to pass a file or have a friend to setup your environment, etc…

    You can also change the user using `sudo su -H -u `user` ssh-allow-friends ….`, read the README.md for more details.
    Be aware that the ssh-allow-friend is not meant for servers, nor it deals with security issues.

Leave a Reply to SCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.