New answers tagged

0

The client always sends the whole publickey. This is defined in RFC-4252. Most clients send a SSH_MSG_USERAUTH_REQUEST without a signature to the server in the first step. This step is used to know which private key can be used to login, because a private key can be protected by a password. This avoids entering a password for an unused key. Even if the first ...


0

All keys affected are considered weak. Key points in the CVE-2021-41117 NVD bulletin: The impact is that each byte in the RNG seed has a 97% chance of being 0 due to incorrect conversion. When it is not, the bytes are 0 through 9. So cryptographically speaking, at even 512-bits (64 characters), you'll only have an extremely tiny fraction of unique keys. ...


1

CVE-2021-41117 explains that the affected versions GitCraken used a weak random number generator to generate key pairs. Therefore, it is possible that identical keypairs may have been created by two different users using the software. So, it is possible that someone else may have the same key pair as one of your users. If that person notices that their ...


3

There seems to be alot of confusion in the answers provided so far. Beware! In SSH public key authentication, there are two keys involved: The private key - which exists on the SSH client - a typical filename is ~/.ssh/id_rsa The public key - which exists on the SSH server - a typical filename is ~/.ssh/authorized_keys Effectively, the SSH private key ...


0

A little more research made me conclude, for now, that setting up a GitHub repository deploy key and add the passphrase to the ssh-agent is a good option. Deploy key is convenient because it isolates a single repository, and ssh-agent is convenient because it stores the SSH key passphrase in memory until ssh-agent is killed. It is possible to configure the ...


1

All of the following assumes you've already verified the server's fingerprint via some out-of-band method. The server doesn't send a separate fingerprint. The fingerprint you see is calculated by your ssh client from the public key that the server presented when you connected. That same public key is used by your client to encrypt data before sending it ...


1

You need to verify out-of-band. As you correctly stated, SSH is Trust-On-First-Use (TOFU), so if you are being intercepted on first use, then you would trust the attacker's key. Depending on your setup, you could connect to the machine via a local network, where interception is unlikely (e.g. your home server) or have the fingerprint displayed somewhere on a ...


20

Is it the server or the local SSH process running that warns us? It's the local SSH process. The remote server does not have access to your local files, it does not read your keys and have no idea what is on your side. Your local SSH process reads your key and uses it to authenticate itself to the remote server, and warns you about the insecure key ...


28

It is not about the SSH server knowing about the file permissions of the client. The scenario is instead having multiple users on the same computer or on the same shared network file system. Since the private key should identify a specific user it is necessary that other users on the same shared resource cannot read or manipulate the private key, i.e. the ...


2

No. Public keys are, surprise, public. As such, they can't be used for authentication because everybody can (and is expected to potentially) have it. Trying to use a public key for authentication is like broadcasting "the person who shows up at the White House with the number 3671 gets $1,000,000,000" on national TV, radio, and newspapers. You'd ...


1

That's highly unlikely. If you're not on a shared computer, it's even less likely. You can add HashKnownHosts no to your ~/.ssh/config to disable hashing the host names, then purge your ~/.ssh/known_hosts file, and then re-populate it over time as you log in to your various remote hosts. As Jasen answered, you'll have to repeat the process of accepting them ...


1

What you need is probably Agent Forwarding, which let's a remote computer perform cryptographic operations using GPG on your local computer, via a SSH Channel. That should allow you to use a GPG key stored on your computer or a key card. A somewhat more detailed writeup is also available.


2

Known hosts usually has hashed records and some services that it is used for (eg: github) have multiple servers resulting in multiple records in the file. You can delete the file and re-generate a new one, that will mean you'll get alerts from ssh for each server.


0

Once someone is on your machine, you can expect that they will find a way to execute commands. They already have bash and network access - that means they can simply download any executable they need and run it. Anything past blocking all traffic from unneeded ports and setting up SSH so you can only connect via public key authentication and 2FA is ...


3

As I have already responded to your question on WinSCP forum: That's how URLs work. Even the Wikipedia article that you yourself point to (well, I've pointed you to that article), explains that. It does not matter, if it is http:// URL, sftp:// URL or ftp:// URL. It's still URL. For example, how else would you tell, if in the following URL, the username is ...


Top 50 recent answers are included