Note to the author: Please don't have a command line flag that either means ( a valid local posix path ) or ( a username/handle from a specific online service that will be fetched over the network ). *nix cli tools are supposed to be unambiguous. I'd fork/issue/patch it, but I don't have a need to let people ssh into my any of my boxes. Just posting this here because its a valid learning opportunity that making something "easy" is not always the right choice in a cli tool, and that namespaces are important. What if I have a file named the same as a github user? Which thing will work? Will that behavior change unexpectedly? Best to make them different flags.
Show HN: Invite friends to SSH into your laptop using their GitHub handle
91–100 of 105 posts
Re: Show HN: Invite friends to SSH into your laptop using their GitHub handle
#92> ssh-import-I'd gh:my-gh-name That little command will pull down your GitHub public keys and add them to authorized key file for the user who runs it. Great for setting up new computers. I run it on boot-time for imbedded devices so that I can always access them.
That's cool, but it seems like a lot of code to do something that: - You can do in one line of bash: curl https://github.com/user.keys >> ~/.ssh/authorized_keys - The bash one-liner is transparent and educational: it tells you clearly and intuitively where the keys are coming from and where they're going, educating users about the existence of the Github/Gitlab-published keys and about how the authorized_keys file wo…
Agreed! But the program manages your keys. For example, it will remove them if you remove them from GitHub.
Re: Show HN: Invite friends to SSH into your laptop using their GitHub handle
#93Earlier quoted context omitted.
Just making a critique of the concept. Didn't think that was against any guidelines.
If you're going to start your sentence by the heavily condescending "Yeah, what a great idea", then don't pretend you don't understand how that could be against the rules. You can't have your lunch and eat it. Especially if you're not going to provide some facts / hard evidence to back up your assertion that this is, in fact, not a good idea.
I think the rest of my statement backed that up pretty well.
I'm not clear though - I'm to expect hackernews has rules which demand I weasel-word my criticisms? That seems ridiculous.
Re: Show HN: Invite friends to SSH into your laptop using their GitHub handle
#94Earlier quoted context omitted.
If you're going to start your sentence by the heavily condescending "Yeah, what a great idea", then don't pretend you don't understand how that could be against the rules. You can't have your lunch and eat it. Especially if you're not going to provide some facts / hard evidence to back up your assertion that this is, in fact, not a good idea.
I think the rest of my statement backed that up pretty well. I'm not clear though - I'm to expect hackernews has rules which demand I weasel-word my criticisms? That seems ridiculous.
The Hacker News community expects civil and substantive comments, as others have already pointed out. Reading this as demanding weasel words is disingenuous.
Re: Show HN: Invite friends to SSH into your laptop using their GitHub handle
#95Note to the author: Please don't have a command line flag that either means ( a valid local posix path ) or ( a username/handle from a specific online service that will be fetched over the network ). *nix cli tools are supposed to be unambiguous. I'd fork/issue/patch it, but I don't have a need to let people ssh into my any of my boxes. Just posting this here because its a valid learning opportunity that making somet…
I now regret that my github username isn't: ".authorized_keys".
Re: Show HN: Invite friends to SSH into your laptop using their GitHub handle
#96Publishing the public key that you use to push to github/gitlab is not a big issue... But Re-using your github key-pair, to connect to other unknown and uncontrolled places, _is_ a security issue. Even re-using your daily system user, for this, is a security issue. But if you never did read the sshd_config man page, or never did play with its options, maybe you're unaware of this. Also the sshd could be modified at s…
Can you explain how this could be exploited (assuming that the user does not ignore warnings)?
I'm not sure if it is a big issue without passing in -A to allow forwarding of authentication to a second server beyond the one you're logging in to. In theory you should still be in control of your secret key and the session even if the first server attempts to proxy or steal your private key. Note that your console/tty or shell might be vulnerable to a malicious server in any case.
Stuff like:
https://m.theregister.co.uk/2016/01/14/openssh_is_wide_open_...
seem to indicate that a patched ssh client should (no longer) leak private keys without the -A parameter...
Re: Show HN: Invite friends to SSH into your laptop using their GitHub handle
#97Hey HN - This is basically a hosted version of Teleport[0], which may scare some people. We don't store the sessions and you can always self-host if you prefer. [0] http://gravitational.com/teleport/
From a quick Re-reading of the teleport readme, and the teleconsole one - I'm a little unclear if there's an easy way to "self-host" a complete teleconsole-setup including the nat-proxy?
I suppose if you have an Internet-facing server to run teleport on, there are fewer reasons to use teleconsole - but I could see it still being useful? (for eg help troubleshooting workstations or servers/clusters behind firewall/Nat for people outside the organisation - volunteering, "helping a friend" or consulting)?
Re: Show HN: Invite friends to SSH into your laptop using their GitHub handle
#98Earlier quoted context omitted.
That's cool, but it seems like a lot of code to do something that: - You can do in one line of bash: curl https://github.com/user.keys >> ~/.ssh/authorized_keys - The bash one-liner is transparent and educational: it tells you clearly and intuitively where the keys are coming from and where they're going, educating users about the existence of the Github/Gitlab-published keys and about how the authorized_keys file wo…
Executing the curl command with no error checking and blindly appending it to your ~/.ssh/authorized_keys could easily bork the latter. Wrapping it in a fancy command allows for error checking and response validation. Otherwise you could end up the source of https://github.com/503.html in there!
Perhaps, but the simplicity of the curl command provides enough insight into exactly what it does to understand what precisely it does and what could go wrong. I can see what file it's writing to, I can check that file, I can be pretty sure it's not doing anything else weird behind the scenes.
Re: Show HN: Invite friends to SSH into your laptop using their GitHub handle
#99Earlier quoted context omitted.
Executing the curl command with no error checking and blindly appending it to your ~/.ssh/authorized_keys could easily bork the latter. Wrapping it in a fancy command allows for error checking and response validation. Otherwise you could end up the source of https://github.com/503.html in there!
Perhaps, but the simplicity of the curl command provides enough insight into exactly what it does to understand what precisely it does and what could go wrong. I can see what file it's writing to, I can check that file, I can be pretty sure it's not doing anything else weird behind the scenes.
That's the whole point. You have to manually do those things. It's not that you can't do them, it's that if you tell someone "Just run curl ... >> ..." without the validation part they can get hosed. Even in a script you need to be careful about it because a non-200 HTTP response still gives a zero (i.e. success) exit status.
Re: Show HN: Invite friends to SSH into your laptop using their GitHub handle
#100Earlier quoted context omitted.
You argument is biased and non-factual. Default ssh measures keep un-trusted entities from gaining access, normally. Conversely, once access is granted by the admin to trusted entities, the normal UNIX permissions continue to provide means by which access to the file system is limited by user permissions. Thus, simply by an admin granting access to a system, your (hypothetical) arguments become false and pointless to…
You must be kidding me. My "argument " is a question . My "hypotetical arguments" consist of me asking if there is some thing stopping people from scp'ing things to my computer then running them . You talk like phishing and privilege escalation weren't things that exist. Have you ever managed any public-facing service of any importance?
Actually, those types of questions are called leading questions. Making a point based on a hypothetical can not be logically used to make a factual point without it being a bias, even if you phrase it as an "unknown", or question. Your last comment here shows your tendency to blame and use biases for making arguments, which is unfortunate given you appear to be asserting authority on matters of "public facing" servers. You know what they say about making assumptions.
I would note that using biased arguments is an inefficient process in most cases. It's akin to recursion of a process which, in my experience, has brought many a more server to its knees than a hypothetical threat from double authorized access (hash + key).