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.
SSH can try several authentication-methods, and it will (rather stupidly...) "fall down" to simpler and simpler authentication-methods when a more stringent one is unsuccessful. But the configuration-file does provide controls.
Oh, I see your question now. Well you see, ssh has to send its public key so that the client can encrypt traffic using it and send that traffic back.
Public keys are a necessary part of the key-exchange process that is used in the initial handshaking of any conversation. It allows the two sides to agree upon necessary communication parameters without being "overheard."
It is very important to understand that a public-key system uses two keys. A message that is encrypted using one of the keys can only be decrypted using the other. Once supplied with the public key, the client can safely send a message to the server knowing that only the server can decrypt it.
Yes i no but if i have the public key to encrypt i want to stop ssh with sending its public key
I want to open port 22 so only me can acces it with ssh but now when someone connects to my server its sending the public key so its not so save to keep the port 22 open
The first part of any public-key exchange always has one party sending its public key to the other. As far as I know there aren't any systems that pre-suppose that the other party already has a copy of the key.
The public key is supposed to be one that you can safely distribute without compromising security. And the private key will be the one that no one else must ever see.
You will see public-keys and "fingerprints" being exchanged between an SSL client and server, no matter what kind of authentication you may use. In addition tothis use of "public keys," you may also see public keys being exchanged in the form of "digital certificates."
I did a Google search on ssh tutorial OR howto "public key" and found tons of better explanations...
Yes. Make sure that it's linked to an up-to-date sshd and that this daemon will not accept a connection from anyone at all without a security certificate issued by you. Do not rely upon passwords. Do not allow logins to root from anyone anywhere.
Presumably you are opening the ssh port for your own convenience. [Have you considered buying a router that supports Virtual Private Networking (VPN)?] Therefore the daemon should be equipped to recognize you, and to simply give outsiders no chance to present a user/password.
If I were opening a system up, I would start with VPN (using certificates there too, of course...) and if someone manages to get through that layer he's staring at an SSH that wants to see another credential. "First he must get over the moat, only then can he reach the porticullis..." Layers of security.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.