24

The more a private key is shared, the less private it becomes. This is just a generic assessment: in some situations, this can be harmless. What it means in the specific case of SSH servers is that the security of these three servers becomes an all-or-nothing system: Each server knows enough to impersonate any of the others. If one of the server is hacked ...


11

There is a crucial piece of confusion in your question, which the answers here did not point out: ServerKeyBits has nothing to do with the hostkey. In fact, it is mostly irrelevant today, since it applies only to SSH protocol version 1, which has been obsolete for many years and should no longer be used. If you’re familiar with setting up an OpenSSH server, ...


8

The host has a key pair, consisting of a public key and a private key. (It can have multiple key pairs in different formats; at the beginning of a connection, the client and the server negociate to determine a format that they both support.) There's a host public key and a host private key; there are also other key pairs (public and private keys) which are ...


7

This could be bad if one machine was compromised and the attacker was able to steal the key. They would then be able to impersonate any of the other machines without tipping off the users with a host key change warning when they next attempted to log into the malicious host. If there are other security mechanisms in place on the network then this threat ...


5

If you check only the first half of the host key you reduce the checked bits from 128 bits to 64 bits. Since there are not 2 keys but 2^64 keys which share the first 64 bits the security is not reduced by a factor of 2 but by a factor of 2^64, i.e. you don't get 50% security but 5e-18% security. Note that even the reduced check of 64 bit might still be ...


5

When you connect to the wrong server, this should trigger a very noticeable client-side warning, because the server appears to use a key distinct from the key it was using in previous sessions. The client remembers servers' keys. For a classic OpenSSH client, the warning looks like this: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ ...


5

In the comments OP separated his original question into two different questions, the first of which has already been answered, as pointed out in the comments. Question 1: can client public key be used to authenticate server The answer is no. (See, Does git use the ssh user keys or the repository's deploy keys for encryption?). Question 2: is ...


4

You can use ssh-keyscan to get the information you want. It's primarily designed for gathering public keys over an initial trusted network connection and automatically adding them into the known_hosts file.


4

You already quite understand how the public key cryptography works and how the client is authenticated to the server using public key authentication. The same thing is needed on the other direction. Internet and computer networks are evil place and it is quite easy to redirect traffic, spoof DNS or somehow make you connect to evil host, which would like to ...


4

The private key is the distinctive power of each machine. Having distinct keys for the machine makes sense, from a security point of view, only if the machines are not equivalent to each other. As you note, if an attacker obtains full control of one machine, then it can spy on the network and observe the files of all other machines, including their SSH ...


4

Is there any major vulnerability in doing this? Depends on the configuration / threat model / etc. There's a lot of variables to consider. Can someone else see the daemon command running? Yes - anyone with access to either machine can see this, including all parameters. Linux: ps -aux | grep -i 'ssh' macOS: ps -Aj | grep -i 'ssh' Here's an ...


4

A host key is mandatory for any ssh server. The server can have multiple host keys using different algorithms. If no key is present when the server is started a host key is generated for the server. An ssh client can authenticate with a wide range of different methods. The two most common are password and publickey. As the name suggests only publickey ...


4

Is there any way for ssh-keyscan to automatically verify the legitimacy of the host it scans? No. How could it? You are using it to build the known_hosts file that would be used for verification. If not, doesn't it become security theatre and defeats the point of SSH's known_hosts verification? In the example you've shown, it indeed does. Although the ...


3

There are a large number of reasons why this can happen: Hosting location. Gitlab can be downloaded and hosted elsewhere. The host keys posted on gitlab's page don't mean anything if your university is hosting their own version of gitlab. In that case you would never see gitlab's host key - you would see the host key for your university server, and the ...


3

No, you should not check only part of the key. PS: Programs like WinSCP and PuTTY only show the fingerprint through a pop-up window and thus I cannot copy the fingerprint and use a comparison program to compare two values. WinSCP has Copy key fingerprints to clipboard command exactly for this reason. WinSCP also has Paste key command, that allows you to ...


3

Short Answer: The host key is the public key of the server, and this key is used to establish shared secret (symmetric encryption key) and thus it is important that it is strong enough to stand against brute-force attack. In detail: Firstly you need to understand how the asymmetric encryption or public-private key encryption works. Each system have a key ...


3

Let's call your friend Bob. Bob has updated his certificate, but since you've never seen it before, you're rightly concerned Eve may be in the middle. You've done the right thing by contacting him to verify your observation, but there is still no automated way of confirming the new key. I'm presuming you aren't using any signing authority and explicitly ...


3

This isn't really an answer because I have no idea how to make the openssh CLI client do that, short of modifying the c code. Academically, it's an interesting question whether you actually gain anything by mixing protection models like that; both are methods of authenticating that you are in fact talking to the server that you think you are. ssh ...


3

A couple of possibilities: Backup and restore the keys. I use a script to backup both public and private keys in an encrypted archive (tar.bz2) file to a local server over rsync. Use a set of private keys and reuse them across systems - probably not a good idea unless the area is secure and the chances of MITM are slim. Use keys signed by a trusted ...


3

First glaring issue: ssh root@ Don't do that. Don't ssh as root. Ever. SSH as root is bad practice, is worse than sudo su -. If your password or key is compromised somehow, the entire DB server is gone. Privilege separation, tight permissions, full disk encryption... all useless. If someone gets a shell on the application server, he can connect to the ...


3

If you don't have the host key another server can pretend to be the server you are trying to log into. This could be a problem if you send any confidential information over the link before you realise you are logged into the wrong server. You should also be wary of having X11-forwarding enabled or, worse, ssh-agent forwarding. With ssh-agent forwarding ...


3

There is no need for tricks, SSH Certificate Authority is designed for exactly this kind of situation. You install host certificates signed by the Certificate Authority, distribute the Root Certificate to your users, and your users are connecting securely from the first connection.


3

The issue is likely that you are changing the host key in such a way as to make it unparsable. If you try using ssh -v [host] you'll probably see something like this: debug1: /home/[user]/.ssh/known_hosts:1: parse error in hostkeys file If you want to cause a verification error rather than a parse error that gets ignored, you'll have to change the key in a ...


2

Yes this is bad. As was said previously, if one host gets compromised, then any other hosts with the same private key would need to be rotated to prevent MITM attacks. A better strategy would be to create the key after the host was stood up, or generate a new key after imaging. Take a look at what some of the big guys do (AWS, linode, etc) for ideas on how ...


2

Is changing the SSH host key a bad thing or is there a security benefit by changing it? You should change it mainly if is has been compromised. Examples of such compromissions: an employee that could have knowledge of it is fired or leaves the company for any reason, you had to let an extersal support tech administrate the machine. You could change it on a ...


2

CheckHostIP no means that ssh does not check the host IP address in the known_hosts file. So only if CheckHostIP is set to no a DNS server can return a different IP address as written in the known_hosts file without a warning of the ssh client. For example an entry in a (unhashed) known_hosts file could be: www.example.org,1.2.3.4 ssh-rsa AAAA...njvPw== ...


2

Yes the keys you generate are only used to authenticate who you are. The actual encryption is handled after you authenticate. So the initial communication to authenticate is Asymmetric, using your generated keys to confirm who you are, then a set of Symmetric keys are generated to encrypt the actual session. Rather than me make a mess of explaining the ...


2

You can safely remove the keys stored in /etc/ssh, generate new keys and restart sshd. There is nothing more to it than that. But please note that every client that have the old key stored in their known_hosts file will complain. You will need to remove that record from your clients. This can be done using ssh-keygen -R <hostname>


2

How do I proceed to make sure I'm not being tricked? Your friend should not answer you "Yes", but "Yes, the new SHA-256 fingerprint is ...". In that case, you can remove the old key and manually verify the new host key.


2

Generally, using the VPS company's API is a good idea, given its proper reliability and also enough resources to implement and maintain that on your side. After all, the SSH key management functionality may be added to said API sooner or later (maybe even upon your feature request, who knows?). However, DNS cache poisoning alone is, to put it mildly, a rare ...


Only top voted, non community-wiki answers of a minimum length are eligible