If you're doing agent forwarding in your .ssh/config for * this could be a massive security thread. Mods should probably put a disclaimer at the top of this thread.
Is that setup common?
Show HN: Apply for a job through SSH, $ ssh jobs.hackclub.com
31–40 of 119 posts
Re: Show HN: Apply for a job through SSH, $ ssh jobs.hackclub.com
#32Earlier quoted context omitted.
In case you want to connect to a random ssh server without giving it your public ssh keys.
Yes, but there's a reason those are called "public" keys. The reason is that you don't suffer any harm by giving them out. Except that they may be publicly identified with you. In that case, and only that case, giving them out would involve purporting to be the person who is publicly associated with the keys. (It wouldn't prove it, because, after all, those keys are public; anyone can know and distribute them.) So th…
I would say more specifically: if you have any SSH keys that are associated with non-career nyms (which is a perfectly reasonable thing to do) then keep them separate and only include them for known associated hosts, perhaps by using IdentityFile in Host blocks in .ssh/config.
Re: Show HN: Apply for a job through SSH, $ ssh jobs.hackclub.com
#33Earlier quoted context omitted.
In case you want to connect to a random ssh server without giving it your public ssh keys.
Yes, but there's a reason those are called "public" keys. The reason is that you don't suffer any harm by giving them out. Except that they may be publicly identified with you. In that case, and only that case, giving them out would involve purporting to be the person who is publicly associated with the keys. (It wouldn't prove it, because, after all, those keys are public; anyone can know and distribute them.) So th…
The other reply to this comment misses the fact that an nonce is used in the client authentication process. Thus, one server to which you successfully authenticate using a public key cannot replay that against a different server that accepts the same key. There is a unique value that is sent to the client, hashed, and then signed with the private key.
Anyone can download your public SSH keys from GitHub (github.com/.keys). The Ubuntu Server installed uses this to make setting up a mostly headless server easier.
Re: Show HN: Apply for a job through SSH, $ ssh jobs.hackclub.com
#34If you're doing agent forwarding in your .ssh/config for * this could be a massive security thread. Mods should probably put a disclaimer at the top of this thread.
Is that setup common?
It doesn't have to be for at least some unsuspecting users to unwittingly share their private key with some random server on the internet.
When was the last time you ssh'd to a server you didn't already have some level of trust with? (AWS, GCP, work server farms, etc.)
Re: Show HN: Apply for a job through SSH, $ ssh jobs.hackclub.com
#35Re: Show HN: Apply for a job through SSH, $ ssh jobs.hackclub.com
#36Any reason why this wasn't implemented with telnet since no authentication is required?
SSH, once you (verify and) accept the first key exchange cannot be tampered with in transit, nor have the contents viewed by those sitting in-between.
However, I believe everyone's stdout/stderr is available to everyone, if everyone is the same user, and if that user has read access to /proc, so that confidentiality is only restricted those who access to the server.
Re: Show HN: Apply for a job through SSH, $ ssh jobs.hackclub.com
#37Earlier quoted context omitted.
Yes, but there's a reason those are called "public" keys. The reason is that you don't suffer any harm by giving them out. Except that they may be publicly identified with you. In that case, and only that case, giving them out would involve purporting to be the person who is publicly associated with the keys. (It wouldn't prove it, because, after all, those keys are public; anyone can know and distribute them.) So th…
The other reply to this comment misses the fact that an nonce is used in the client authentication process. Thus, one server to which you successfully authenticate using a public key cannot replay that against a different server that accepts the same key. There is a unique value that is sent to the client, hashed, and then signed with the private key. Anyone can download your public SSH keys from GitHub (github.com/…
If you mean geofft's comment, I don't believe they're talking about a replay attack. thaumasiotes wrote "It wouldn't prove it, because anyone could be presenting the public key", but geofft is saying that if the server claims to recognize the key and requests to continue authentication using it, then your client will potentially provide the proof—invisibly and automatically, if the private key is passwordless/agent-loaded. There is no second server; this is the original server being able to confirm that you are actually in possession of a supposedly-unrelated-to-anything key. (I have not verified whether the order of operations in the protocol actually works this way; I'm just interpreting what geofft is saying.)
Re: Show HN: Apply for a job through SSH, $ ssh jobs.hackclub.com
#38Any reason why this wasn't implemented with telnet since no authentication is required?
SSH, once you (verify and) accept the first key exchange cannot be tampered with in transit, nor have the contents viewed by those sitting in-between. However, I believe everyone's stdout/stderr is available to everyone, if everyone is the same user, and if that user has read access to /proc, so that confidentiality is only restricted those who access to the server.
It's also relatively trivial to set something up like this as SSH server supports auth delegation using PAM, and PAM can be configured with a single line using pam_succeed_if.so to disable auth only for a certain user.
Re: Show HN: Apply for a job through SSH, $ ssh jobs.hackclub.com
#39Any reason why this wasn't implemented with telnet since no authentication is required?
SSH, once you (verify and) accept the first key exchange cannot be tampered with in transit, nor have the contents viewed by those sitting in-between. However, I believe everyone's stdout/stderr is available to everyone, if everyone is the same user, and if that user has read access to /proc, so that confidentiality is only restricted those who access to the server.
In "public access single-app" cases like this, the user is generally connected to a restricted shell or other program which (… supposedly—this is very easy to get wrong if you're running anything that isn't specifically built for it) does not allow arbitrary executable access.
Re: Show HN: Apply for a job through SSH, $ ssh jobs.hackclub.com
#40Earlier quoted context omitted.
Yes, but there's a reason those are called "public" keys. The reason is that you don't suffer any harm by giving them out. Except that they may be publicly identified with you. In that case, and only that case, giving them out would involve purporting to be the person who is publicly associated with the keys. (It wouldn't prove it, because, after all, those keys are public; anyone can know and distribute them.) So th…
> (It wouldn't prove it, because, after all, those keys are public; anyone can know and distribute them.) I don't believe this is true, right? You do a private key operation demonstrating you possess the private key associated with the public key. Or, by contradiction: Since the key is public, any server can put the fingerprint of the key in an authorized_keys file. It can then challenge you to log in in a way that e…
As I understand it, your SSH client gives out all your public keys, but doesn’t authenticate with all of them. That might be the crux.