Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
hi,
just to understand.
ssl pki certificate are on server side and private pki certificate are on client side?
why we need to create a private key and a signed certificate on server side?then we will use them with services or application.
this certificate will be downloaded to the client before the traffic between server and client?
When I first read this question I'm sure SSH was mentioned, and you questioned why certificates weren't needed for that. I'll start with that.
A certificate is a public key, with identity information attached and signed by someone else's private key.
For SSH this isn't required because either you own the machine you are connecting to, or you have some sort of relationship with the person/organisation that does, and you can share public keys/fingerprints using a medium other than the SSH protocol, and authenticity is established during that exchange.
Something like HTTPS doesn't rely on or assume a preexisting relationship, and thus must establishing authenticity is just as important as encryption. This is where certificates come in. You have a small set of 'Root Certificate Authority' certificates that came with your browser or operating system. You trust these.
Most of the time, for HTTPS, determining authenticity of the server is sufficient. You configure the server with a private key and a cert. Whoever has signed the cert has (should have) gone out of their way to validate your identity and make sure you are who you say you are. When, for example, I connect to your server I'll receive your certificate and I'll check that the certificate has been signed by one of the Root Certificate Authorities* I know about and trust, if it has, I can be happy that you are who you say you are. This is the chain of trust.
* Generally your server cert won't be signed by a Root CA, there will be a bunch of intermediary certificate authorities in between, hence chain.
Some times, servers need to verify the client is who they say they are, so the client needs a cert signed by a CA the server trusts. This isn't common for general web traffic (this site, google, bookface, etc). It is more common in organizations with internal websites and company laptops and VPNs.
PKI is asymmetric encryption, every private key needs a corresponding public key. Generally asymmetric encryption is only used to establish authenticity and to exchange a symmetric key (or data that allows a key to be computed) for further communication. Symmetric encryption/decryption is far faster than asymmetric encryption.
Disclaimer: I'm not an expert, just a layman as far as encryption goes.
certificates are used over ssl or tsl.application or service use certificate to authenticate client machine or user?
ex. puppet server sign a certificate requested by client machine.apache server send over a certificate to web browser at client machine or the certificate is per user or session level?
certificate issued by kerberos not use a CA root certificate as certificate over ssl or tls use.right?
ssh can use an kerberos certificate.
certificate over ssl or tls does not use pam as ssh use.right?
application or service use certificate to authenticate client machine or user?
I'm not 100% sure what you are asking.
Quote:
Originally Posted by lelunicu
ex. puppet server sign a certificate requested by client machine.apache server send over a certificate to web browser at client machine or the certificate is per user or session level?
I'm not sure what you are asking here. If you are doing client authentication, and your client has a certificate that has been signed, a web server wouldn't be sending it to the client, it would be the other way about.
Quote:
Originally Posted by lelunicu
certificate issued by kerberos not use a CA root certificate as certificate over ssl or tls use.right?
I don't know. I last read about Kerberos over a decade ago. I can't remember.
Quote:
Originally Posted by lelunicu
ssh can use an kerberos certificate.
Kerberos ticket for authentication. Yes.
Quote:
Originally Posted by lelunicu
certificate over ssl or tls does not use pam as ssh use.right?
Correct.
All this is easily obtained information using your favourite search engine. I encourage you to use it.
client has user with public key and private key generated.the same server has public and private key for a user.
if the public key of user is copied in authorized_keys in server then how the traffic is encrypted?
clent encript data with private key and send it to the server.this decript the data with public key?
or the client and server will generate a session key and this key is used by client and server to encript or decript the data?
It's actually a 2-stage process. In the first stage, your computer generates a private one-time key out of random noise. It contacts the server and the server sends back an unencrypted packet containing its public key, a list of the encryption algorithms that it supports and a certificate confirming that the public key is genuine. Your computer then uses this public key to encrypt a packet containing the private key it has made and the name of the encryption algorithm it wants to use. The server uses its private key to decrypt the package; no one else can decrypt it. Even if someone intercepts the package, it will be gobbledygook to them.
Now the server knows the one-time key you have created and what encryption algorithm you want to use. In the second stage, both parties switch to symmetric encryption, using that algorithm and using the same key to encrypt and decrypt, which is a lot faster. Nobody else can eavesdrop because nobody else knows either the algorithm or the key to use.
Yes, the encryption stuff has to be done first so that the password will already be encrypted when it is transferred across. Otherwise someone could sniff your password. That's how you log into Linux Questions too.
if there are no public and private key on client or server,then what component will encrypt the password at logon time using ssh?after the user is logged in,the traffic will be encrypted?what component will be used to encrypt the traffic?
is correct to say that https traffic goes over tls?or https traffic use tls?
Here's what Linux From Scratch says about using openssh:
Quote:
If you want to be able to log in without typing in your password, first create ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub with ssh-keygen and then copy ~/.ssh/id_rsa.pub to ~/.ssh/authorized_keys on the remote computer that you want to log into. You'll need to change REMOTE_USERNAME and REMOTE_HOSTNAME for the username and hostname of the remote computer and you'll also need to enter your password for the ssh-copy-id command to succeed:
Once you've got passwordless logins working it's actually more secure than logging in with a password (as the private key is much longer than most people's passwords). If you would like to now disable password logins, as the root user:
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.