Xanza @ Xanza @lemm.ee Posts 2Comments 1,059Joined 3 mo. ago
Again, they're not denying you entry permanently, but they absolutely can slow fuck you for weeks until your device is unlocked and checked. You people live in some little utopia that doesn't exist.
We just deported a US citizen to Argentina without due process and its taking a federal court order for the US government to do anything about it. You really think they care about your "right" to reenter the country?
This is marvelous, but goddamn do I hate cross compiling rust projects from source.
Reasoning skills and experience. There are entire botnets dedicated to finding servers with open SSH ports on 22. If the bots can connect, the IP of the server will be added to a list to be brute forced.
I'm a per diem linux systems administrator. Right now I have a VPS that I setup myself. It uses a non-standard ssh port, fail2ban, and rejects incoming connections to port 22. According to connection logs, I get about 200 attempts per 24 hours from bots randomly pinging ports to see if they can catch an open SSH port--and they're banned via fail2ban.
I checked out some other servers that I manage, which I did not setup and have no control over how they operate. Sifting through just 3 random servers and checking connection logs, they have a combined 435,000 connection attempts in the past 6 hours between the 3 of them. These are relatively small servers with an extremely small presence. Simple fact of the matter is, is that they all have port 22 open and reachable. So botnets attempt to brute force them.
So just anecdotally that's a difference of 0.0459770115% or 99.96%. Anyone telling you that changing the default SSH port doesn't do anything for security has absolutely no practical experience at all. It significantly reduces your attack surface as bots have to guess at ports until they find your SSHd's operational port to even begin to start sending attempts.
This is TLS authentication via SSH, which is a completely different ballgame than using SSH keys for data encryption, decryption, and verification.
Mathematically, they're not even close to the same. How you could ever assert such an indefensibly and empirically incorrect statement is beyond my reasoning skills to understand.
PKC Key signing uses hashing algorithms like RSA, ElGamal, DSA, and ECDSA to create one way cryptographic hashes for given input data. The singular purpose of these signatures is to verify the integrity of data. Not to protect the data in any way whatsoever or to be reversed into clear text; again, the hash is one way.
PKC encryption uses encryption algorithms like AES, Blowfish, Twofish, PGP, and Diffie-Hellman to create reversible cipher text. The difference being, the cipher text of an encryption process can be reversed and represents the data itself.
All of this is clearly outlined in the RFC: https://www.ietf.org/rfc/rfc4880.txt
Encryption can only be done with the PGP public key. Even if you specifically use the private key, it contains the public key, and GPG already knows to use the public key for encryption. You cannot create encrypted cipher text using a GPG private key.
Likewise, you cannot decrypt data using the public key, nor can you sign statements with a public key. For those processes you must use a private key.
I had no idea people found GPG this confusing...
You seem to be fundamentally misunderstanding how the shared keys work, here. You don't get to choose which key you sign with, either private or public.
If you sign a statement, it uses your private key. Period. The methodology is only the original owner of the keys has access to the private key, so any signed statement also using that private key, is directly from the key owner. Alternatively, anyone has access to your private key, and can encrypt data using it, that only the owner, with access to the private key, can decrypt.
Anyone in the world can encrypt a message that only you can decrypt. That's the way it works. Alternatively, when you sign a statement, you're establishing that the owner of the key pair signed it, as only the owner has access to the private key. Then, anyone in the world can verify your signed statement using your public key.
You don't get to choose which one you use. In the example from my original post, the ssh-agent only needs reference to the location of one of the two keys, and will use the filename regardless, to distinguish between public and private. If I point the configuration option to this_is_my_key indicating a private key, it will automatically use this_is_my_key.pub as a public key. If I indicate this_is_my_key.pub then it does the reverse and will assume that this_is_my_key is the private key. It doesn't matter which one you specify, the ssh-agent just needs a filename to work with.
Signing isn't encryption. It's a non-cipher hash.
cli
$ ❯ echo "This is a signed message." | ssh-keygen -Y sign -n file -f ~/.ssh/id_ed25519 > content.txt.sig Signing data on standard input
Which outputs the hash of the signed statement, which was signed with my private key;
ssh
-----BEGIN SSH SIGNATURE----- U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgCwxAYX85ptsTc+Dtz3a0IRondh qFF3wKMsTqt+c4oGMAAAAEZmlsZQAAAAAAAAAGc2hhNTEyAAAAUwAAAAtzc2gtZWQyNTUx OQAAAECvqKLkm+kWUgFh0bI8jYIR5BPUaq76MZ94exp2yUn+KnK5YA79ggFY/C4VsnDqJp SAedWp4eOUwPNG8RR59KsP -----END SSH SIGNATURE-----
And can then be verified using my public key;
cli
❯ echo "This is a signed message." | ssh-keygen -Y check-novalidate -n file -f ~/.ssh/id_ed25519.pub -s content.txt.sig Good "file" signature with ED25519 key SHA256:ltAIkPgF9rLt1KlRRh6tQUtWNT8/wErhtAibmSHfbVs
Wouldn’t that mean you’d have to share your public key anyway?
Public keys aren't meant to be private. The function is literally in the name... But no, you don't necessarily have to share your public key, but for someone to verify that a specific public key was used to sign a commit, the public key is required. So there's absolutely no reason to sign your commits if you intend on keeping your public key, private... It completely defeats the entire purpose....
Pursuant to CBP’s border search authority explained above, when presenting their effects for inspection, all travelers are obligated to present their electronic devices and the information resident on the device in a condition that allows for the examination of the device and its contents. If the electronic device cannot be inspected because it is protected by a passcode or encryption or other security mechanism, that device may be subject to exclusion, detention, or other appropriate action or disposition. Additionally, the traveler may face longer processing times to allow for CBP to access the contents of the device.
Taken directly from CBP's website; regardless of any citizenship, or nationality, they can refuse to let you reenter the country until your device is searched. Period. I don't know where this idea that "I'm an American, they can't refuse to let me back into my own country!" narrative came from, but it is entirely fictitious. There are dozens of reasons for you to be refused reentry.
People can take my public key.
And they can also encrypt things with it. That's the whole point. Only the owner of the private key can decrypt what's been encrypted with the public key, and that establishes ownership.
Why the person you responded to is being down-voted, and why people in this thread don't seem to understand how shared keys work is pretty insane to me. This technology has exited, and remained relatively unchanged, for like... 40 years.
The can encrypt my commit, making it indistinguishable from my commit.
That's not how commits are verified. The commit is signed with your private key (not encrypted), not your public key. Referencing the public key simply tells the ssh agent which key-pair to use, and the ssh daemon decides which key to use (public or private) based on the action that you're doing.
Signing a commit requires your private key, so no. People can't just grab your public key and sign commits to impersonate you. They can simply encrypt text with it. That's it. This is all self evident by the git property user.signingkey "sign". You're signing the commit message, not encrypting anything.
You can always count on the House of Representatives to have a laser focus on what's important. /s
The only real advantage to using SSH vs PGP keys is you don't need an external dependency (GPG). PGP is always going to be better, because you get the advantage of WOT, and PGP public key servers to verify identities over just "this is who I am, here's my key." You should always sign your commits, no matter what you use. Identity verification is very important in open source.
cli
$ git config --global gpg.format ssh $ git config --global user.signingkey ~/.ssh/examplekey.pub
Locking down your phone does nothing for you... If they see that you have a phone and they can't access it they simply won't let you in the country regardless of who you are.
The only solution to this is to simply not have an electronic device when going through customs.
Overnight your cell phone to yourself if you're that worried about it. Any other solution is superfluous and outright stupid.
If you're entering the US through Mexico and they demand you unlock your phone and you refuse or it's "locked down" you don't win that conflict. You're just a permanent resident of Mexico now because you're not getting into the United States regardless of your citizenship status.
And I'm a CEHv7. A literal security professional--and I say that an overwhelming vast majority of attacks against servers using SSH are going to come over the default port. Quite literally 99%. This means that you can lower your attack surface by exactly 99% by simply changing the default SSH port...
Those posts provide no meaningful insight and what they say is by the very technical of all interpretations is correct, I absolutely disagree with these statements. What they mean to say is that simply changing the default SSH port isn't alone I means of strictly protecting yourself. Meaning you shouldn't change the default SSH port and think that your server is secured because it's not.
Quite the different interpretation than me saying it should be mandatorily a part of your security strategy.
In protecting yourself against port scanning is trivial.
Anyone underestimating the power of changing The default SSH port is someone who's opinion I can safely disregard.
Why would you even waste your time to reply if you're not going to read what you're replying to?
Using a nonstandard port doesn’t get you much
Uhh... It gets you a lot. Specifically, unless you know the port you can't connect... So hey, there's that..
This community really says shit sometimes that makes me go cross-eyed....
Even illegal aliens are protected by the US constitution--where was his due process?
Why are you sending an email with multiple questions? If you have more than one question, it merits a phone call. Nobody has the time to answer all of your questions via email all day every day.
I personally receive over 200 business emails a day. Can you imagine what it would be like to answer multiple questions from each one?
If you have more than 1 question, call. Don't wanna call? Then it's not that important.
I’m not going to do anything enterprise.
You are, though. You're creating a GPU cluster for generative AI which is an enterprise endeavor...