LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   Controlling remote acces SSH (https://www.linuxquestions.org/questions/linux-security-4/controlling-remote-acces-ssh-346913/)

Wimpie22 07-26-2005 08:47 AM

Controlling remote acces SSH
 
Hello,

I want to remote acces my Server with SSH

But can i secure it so only if the remote site has the public key for the server can acces the server and if not then they can not acces the server

Now everytime im remote and i don't have the public key it wil send to my bij SSH can i change that?


Greetings from Holland

Wimpie

sundialsvcs 07-26-2005 10:16 AM

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.

Wimpie22 07-27-2005 09:47 AM

So can i config SSH so that is won't send its public key when the remote client don't have a key

so that i can open port 22 and only if someone have the public key he can acces the server?

Tnx

sundialsvcs 07-27-2005 11:02 AM

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.

Wimpie22 07-27-2005 12:08 PM

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

C0NIk 07-27-2005 12:14 PM

well , you can use ssh-keygen and make authorized key

Wimpie22 07-27-2005 01:45 PM

How can i do that please help me

i tried it before

sundialsvcs 07-27-2005 03:02 PM

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 to this 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...

Wimpie22 07-27-2005 03:08 PM

But is it save to open port 22 to the internet

sundialsvcs 07-27-2005 04:33 PM

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.


All times are GMT -5. The time now is 01:11 PM.