Join Log in
Score:0
Federico Gentile avatar Ubuntu

Why am I able to SSH a remote machine even with the wrong keys?

fr flag
Federico Gentile

Description: I have created a ssh connection between my Windows Pc and Raspberry Pi. To so I followed the following steps:

Step 1: Somehow get the IP address of the Raspberry Pi. It should be something like this: 192.168.1.52

Step 2: Open a shell and access the Raspberry Pi via ssh:

ssh [email protected]

You will need the password.

Step 3: In the home directory of the remote pc use these commands:

mkdir .ssh

Step 4: Secure the ssh connection via private/public key. In the local pc use this commands:

ssh-keygen -f .ssh/fede_windows -t rsa -b 4096

If your local machine is Linux based run this line:

chmod 600 .ssh/fede_windows # if linux

Finally:

scp .ssh/fede_windows.pub [email protected]:.ssh

Step 5: In the remote pc use these commands:

sudo nano /etc/ssh/sshd_config

and modify the following lines of the config file:

ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no

Finally:

sudo systemctl reload sshd

Step 6: In the remote computer use these commands:

cat ~/.ssh/fede_windows.pub >> ~/.ssh/authorized_keys
chmod 700 ~/.ssh/
chmod 600 ~/.ssh/*

Step 7: In the local computer run this command to log in to the remote one:

ssh -i .ssh/fede_windows [email protected]

Problem: When I perform all these steps again in my Ubuntu Pc by generating this time a key named fede_ubuntu, it looks like that I am able to ssh my Raspberry Pi no matter what I insert in the command:

ssh -i .ssh/fede_xyz [email protected]

It works all the time and this is not supposed to happen since it should be restricted only to the key I just created. If I switch to my Windows machine everything works as expected and only if I specify the right key works.

Question: Would you be able to suggest a possible reason of this issue and how to fix it please?

EDIT: By typing the following command ssh -i .ssh/key_that_does_not_exits -v [email protected] I get:

Warning: Identity file .ssh/key_that_does_not_exits not accessible: No such file or directory.
OpenSSH_8.2p1 Ubuntu-4ubuntu0.3, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to 192.168.1.52 [192.168.1.52] port 22.
debug1: Connection established.
debug1: identity file /home/federico/.ssh/id_rsa type -1
debug1: identity file /home/federico/.ssh/id_rsa-cert type -1
debug1: identity file /home/federico/.ssh/id_dsa type -1
debug1: identity file /home/federico/.ssh/id_dsa-cert type -1
debug1: identity file /home/federico/.ssh/id_ecdsa type -1
debug1: identity file /home/federico/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/federico/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/federico/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/federico/.ssh/id_ed25519 type -1
debug1: identity file /home/federico/.ssh/id_ed25519-cert type -1
debug1: identity file /home/federico/.ssh/id_ed25519_sk type -1
debug1: identity file /home/federico/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/federico/.ssh/id_xmss type -1
debug1: identity file /home/federico/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.3
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9p1 Raspbian-10+deb10u2+rpt1
debug1: match: OpenSSH_7.9p1 Raspbian-10+deb10u2+rpt1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.1.52:22 as 'pi'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:hC5w2kDxgHH5eFRY1vOJaS7ipPR+8OWX2tkkEZbF194
debug1: Host '192.168.1.52' is known and matches the ECDSA host key.
debug1: Found key in /home/federico/.ssh/known_hosts:1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: federico@federico RSA SHA256:E96Hu2Ee+IyAuoZ06GxTvo+ZmAkzqfihbAKkFqxU1AU agent
debug1: Will attempt key: /home/federico/.ssh/id_rsa 
debug1: Will attempt key: /home/federico/.ssh/id_dsa 
debug1: Will attempt key: /home/federico/.ssh/id_ecdsa 
debug1: Will attempt key: /home/federico/.ssh/id_ecdsa_sk 
debug1: Will attempt key: /home/federico/.ssh/id_ed25519 
debug1: Will attempt key: /home/federico/.ssh/id_ed25519_sk 
debug1: Will attempt key: /home/federico/.ssh/id_xmss 
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: federico@federico RSA SHA256:E96Hu2Ee+IyAuoZ06GxTvo+ZmAkzqfihbAKkFqxU1AU agent
debug1: Server accepts key: federico@federico RSA SHA256:E96Hu2Ee+IyAuoZ06GxTvo+ZmAkzqfihbAKkFqxU1AU agent
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.1.52 ([192.168.1.52]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug1: Remote: /home/pi/.ssh/authorized_keys:2: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /home/pi/.ssh/authorized_keys:2: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Sending environment.
debug1: Sending env LC_ADDRESS = it_IT.UTF-8
debug1: Sending env LC_NAME = it_IT.UTF-8
debug1: Sending env LC_MONETARY = it_IT.UTF-8
debug1: Sending env LC_PAPER = it_IT.UTF-8
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending env LC_IDENTIFICATION = it_IT.UTF-8
debug1: Sending env LC_TELEPHONE = it_IT.UTF-8
debug1: Sending env LC_MEASUREMENT = it_IT.UTF-8
debug1: Sending env LC_TIME = it_IT.UTF-8
debug1: Sending env LC_NUMERIC = it_IT.UTF-8
Last login: Sun Aug 22 22:26:00 2021 from 192.168.1.197
151
1 + 2
ssh
cc flag
ubfan1
Probably picking up a per-host identity file from your config -- you are allowed multiples.
1
Reply
Federico Gentile avatar
fr flag
Federico Gentile
@ubfan1 thanks for your comment! would you be able to elaborate a bit more please? practically speaking what should i change in the config file?
0
Reply
Score:4
vidarlo avatar Ubuntu
om flag
vidarlo

The command cat ~/.ssh/fede_windows.pub >> ~/.ssh/authorized_keys appends the key to authorized_keys, it doesn't replace what's already there.

To replace all old keys, run cat foobar.pub > ~/.ssh/authorized_keys. This will truncate the file and then add the new information.

You can add as many keys as you want. To check, simply open the file with a text editor and have a look at the content.

The ability to have many keys is actually a security feature. It means you can use different keys from different computers, and if a computer is lost, you only have to remove the compromised keys, not all keys.

0 + 12
Federico Gentile avatar
fr flag
Federico Gentile
Thanks for your answer! Well my idea was to keep both keys, I do not want to remove the windows key because I still want to use it when I use my Windows machine. If I use your command I will remove the windows key and replace it with the Ubuntu one right?
0
Reply
vidarlo avatar
om flag
vidarlo
Then do nothing. You can add and remove keys as many times as you want.
0
Reply
Federico Gentile avatar
fr flag
Federico Gentile
sorry but this is confusing me. If i do nothing, then i still have the issue that I for some unknown reason i can ssh from the Ubuntu machine even with the wrong key. How is your answer solving my issue?
0
Reply
vidarlo avatar
om flag
vidarlo
`>>` *adds* content to a file. You added both keys. Open the file in a text editor and examine it; it will show both keys. Remove the one you do not want.
0
Reply
Federico Gentile avatar
fr flag
Federico Gentile
mmm... i checked the file and I have 2 keys: 1 for my Windows Pc (which I still want to use to ssh my raspberry) and 1 for my Ubuntu Pc (which also I want to keep to ssh into my raspberry). When I have both of them, I basically can ssh to my raspberry eve with non existing keys. For example if I type "ssh -i .ssh/key_that_does_not_exist [email protected]" it automatically access the raspberry! This should be impossible
0
Reply
vidarlo avatar
om flag
vidarlo
Edit your question with the output of `ssh -v user@host` to see which key is actually sent.
0
Reply
Federico Gentile avatar
fr flag
Federico Gentile
I added the output as suggested :)
0
Reply
vidarlo avatar
om flag
vidarlo
It picks up previously used key from [`ssh-agent`](https://en.wikipedia.org/wiki/Ssh-agent).
0
Reply
Federico Gentile avatar
fr flag
Federico Gentile
oh i see so practically speaking what should I modify? Something in the sshd_config?
0
Reply
vidarlo avatar
om flag
vidarlo
Why do you want to modify if it works as you want?
0
Reply
Federico Gentile avatar
fr flag
Federico Gentile
But if I can ssh even with non existing keys that is super dangerous because it would mean that I don't need a key at all. This is the problem of my question: "Why am I able to SSH a remote machine even with the wrong keys?" My Windows machine can ssh correctly. My Ubuntu machine can ssh even with wrong or non existing keys. And this should not be happening.
0
Reply
vidarlo avatar
om flag
vidarlo
Because ssh-agent caches the key and uses it for authentication. https://stackoverflow.com/questions/25464930/how-can-i-remove-an-ssh-key
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.