Xanza @ Xanza @lemm.ee Posts 2Comments 907Joined 2 mo. ago
Read the message its telling you... go install has no -u flag.
$ go install github.com/nomad-software/meme
The new service includes a WiFi 7 router
I don't recommend it.
I would shoot for a 4 port 2.5Gbe unmanaged switch with 2 SFP+ ports (6 total ports) for 10G networking. 2.5Gbe is going to be more than enough for any WiFi solution you choose with room to upgrade 10G to WiFi if you wanted to spend a bit more on a higher tier WiFi router still leaving a single SFP+ port for 10G networking from your PC.
Biggest hit for your buck. Gonna set you back $40-50.
but if I ever wanted to get the max out of it, what does that take?
Kind of a lot. At least a top to bottom upgrade, from modem (PON), to 10G networking, to new Ethernet cables, to new 10G network drivers. Looking at a few hundred if you do it right. I also had Optimum's 8Gbps internet and was never able to even get anywhere near advertised speeds due to network saturation. IMO, the upgrade right now is too expensive to justify the expense for what you get. If you were confident you would be able to max out the connection, that would be a different story. But ultimately it's gonna be up to you. If you don't mind dropping a few hundred on upgrades, then go nuts.
Martin Luther King Jr’s accomplishments are nearly wiped out
Troglodyte. With 2 replies you've proven to be one of the most ignorant people I've ever experienced in almost 30 years online. You deserve a fuckin' award.
The multi-tennant approach to the linux operating system isn't just for security. It's the way the OS was designed to operate. You're not meant to use root as an ordinary user.
Disabling root removes the safety net, but it also plugs the security hole that leaving root enabled leaves.
The motherfucker helped create the MMR vaccine... I would say he did do something. If you'd like to see somebody that's not do anything at all, look in the mirror you feckless ignoramus...
I mean Jesus Christ man. I don't think I've seen a comment this lacking in intelligence in my entire life. It would be like if somebody went to Martin Luther King Jr and said "well what are you doing about it!?" after he said that he was upset at the status quo.
It's just an unbelievably ignorant and moronic statement to make.... I can't even fully wrap my head around it--how you put absolutely zero forethought into that statement before making it.
I picture you as someone who drowns in the rain because they have their mouth open while they look up. Jesus Christ.
Then, anyone in the world can verify your signed statement using your public key.
Of course. The only barrier is the possession of your public key. I really don't understand what you're getting at here. Anyone with your public key can verify a PSK signed statement you made, which obviously is predicated on them having access to the key.
Anyone only has access to your public key if you give them access to your public key. So no, not really. They should have access to it. It's not something you should keep private, but SSH shared keys aren't PGP shared keys. There's no key servers for SSH shared keys.
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