SSH problem

[linkfan]

Hi,

Did someone came by this warning?

ED25519 key fingerprint is SHA256:xxxxx
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'xxxx' (ED25519) to the list of known hosts.
client_input_hostkeys: received duplicated ecdsa-sha2-nistp256 host key
Last login: Fri Feb 4 15:36:02 2022 from xx.xx.xx.xx

Particularly: client_input_hostkeys: received duplicated ecdsa-sha2-nistp256 host key

Regards,
Linkfan

 

[Slartibart]

Are you connecting to (a) VM(s)? Something like this can happen when e.g. a linux machine or VM is cloned after generating its SSH server host key. So the resulting servers all have the same host key.

In general when a client connects to a given server for the first time, that client has no saved public key for that server yet, so the human user is supposed to check the server key fingerprint against an authoritative source (e.g. a phone call to the sysadmin).

if the machines are not meant to be equivalent to each other with regards to security, sharing a private key shouldn’t happen. If one of these machines was compromised and an attacker was able to steal the key, he would 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 machines are equivalent, sharing the private key can make some operations simpler. It actually has to be done when some forms of load balancing is employed - how SSH fits into such scenario? I have no idea. - private key duplicating/sharing might be acceptable for systems which a part of a computing cluster.

 

[linkfan]

Yes, it's VM, and there are some cloned in the infrastructure, but it's coming up even if known_hosts file is cleared. Any other ideas?

Regards

 

[Slartibart]

Yes, it's VM, and there are some cloned in the infrastructure, but it's coming up even if known_hosts file is cleared. Any other ideas?

Regards

Did you remove the private key from keychain?

 

[linkfan]

This is new MacBook, only public and private key was transferred from old machine.

Regards

 

[Slartibart]

Depending on how SSH is configured on your machine, keys will be added to the MacOS keychain. Cleaning up known_hosts has no effect on that.

EDIT: here are Apple’s technical notes for MacOS 10.12.2 related to this.

 

[linkfan]

Hi!

Thank you for all the tips but nothing helped, the is no key in keychain. Any ideas?

Regards

 

[owidhh]

When the ssh client connects to the server, it receives the server's host key fingerprint. If they key is unknown (e.g. is NOT present in ~/.ssh/known_hosts) then ssh will show the warning.

Once you have verified the fingerprint is correct, and write "yes", then the fingerprint is added to your known_hosts file and saved for later use.

If, later, the hostname or IP address you connect to provides you a different fingerprint, ssh will again show you a warning that the fingerprint has changed. This could be because the communication is being intercepted, the server has changed (e.g. rebuilt a VM, using the same IP or hostname for an entirely new server, etc).

 

[drcpub]

When the ssh client connects to the server, it receives the server's host key fingerprint. If they key is unknown (e.g. is NOT present in ~/.ssh/known_hosts) then ssh will show the warning.

Once you have verified the fingerprint is correct, and write "yes", then the fingerprint is added to your known_hosts file and saved for later use.

If, later, the hostname or IP address you connect to provides you a different fingerprint, ssh will again show you a warning that the fingerprint has changed. This could be because the communication is being intercepted, the server has changed (e.g. rebuilt a VM, using the same IP or hostname for an entirely new server, etc).

Hi, I am trying to understand this. My situation is this. I have a mac pro home running Monterey. I have a work computer running Catalina and I have a macbook laptop I use running Big Sur. My isp has blocked all SMB ports and will not allow one use, myself to have the unblocked. That would be Comcast. Using a tunnel from Work, running Catalina, and because I am not allowed to use the work internet for personal tasks, I use my phone as a teathered modem, setup as hotspot. At work, Again Catalina, the ssh tunnel works fine, I can file share and mount all available volumes needed at the time for business. If I am on the road, not in work, using my MB, I use the same phone as a teather, and trying to establish the same connection an ssh tunnel I get an error, that says that I do not have permission to access local host on the server. I am not sure what server it is talking about. My procedure is this from both locals. sudo ssh -L 55445:localhost:445 username@ipaddress upon hitting enter, both on my MB and in work it connected to the macpro at home, it asks me for the local password, then again for the remote password. it connects. Then I open smb://localhost:55445 and in work my shares are displayed. On the laptop, is when I get the error. At work I was asked originally, the first time I logged in about the fingerprint, I typed yes and it worked fine. On the laptop I was never presented with the info about the fingerprint. Just that error.

Can anyone offer any help as to why the laptop is behaving this way? Anyway to force the ssh to reset the fingerprint between laptop and macpro? The work computer is being used as a test to try and figure out what I missed. but I do not believe I have missed anything. The ssh tunnel works fine but not with the MB

 

[owidhh]

2 ways to reset the fingerprint (or 3...)

1) rm ~/.ssh/known_hosts <--- this is the brute force way, not recommended unless you're really lazy, as it will remove all known fingerprints

2) edit ~/.ssh/known_hosts <--- find the line that refers to the specific host you are connecting to and delete it

3) the precise, elegant way:
ssh-keygen -R hostname_or_ip_address


BTW since you're using sudo, the hosts files, key files, etc are probably in /root/.ssh/ instead of your user's .ssh directory... Just something to keep in mind... But I really doubt you need sudo, since you are mapping the remote port 445 to the local port 55445...

 

[linkfan]

Hi!

It's very weird but problem still persists, new system only key migrated and I have this error: client_input_hostkeys: received duplicated ecdsa-sha2-nistp256 host key - no idea why, maby some new ssh config settings?

Regards

 

[Brian33]

client_input_hostkeys: received duplicated ecdsa-sha2-nistp256 host key

Going from some quick google results, this means that two or more hosts (machines) on your local network are using the same host key. My understanding is that every computer on the network should have its own unique key pair for ssh. I think I read that the key is generated when ssh is installed on the system.

This is new MacBook, only public and private key was transferred from old machine.

I don't know how you set up your new MacBook. Did you use Apple's Migration Assistant, or did you make a clone of your old system in some other way? Perhaps this caused your old Mac and the new Mac to have identical "host keys."

 

[Brian33]

More about host keys:
https://www.ssh.com/academy/ssh/host-key

 

[linkfan]

For you information, problem was in sshd_config, there was duplicated entries:

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key

Sorry that was my mistake.

Regards,
Linkfan

 

[dwnldr]

Dear community !

My topic is related to SSH, so i try to put my question here. I would like to kindly ask you for some ideas :

I made a shot and installed macOS Monterey 12.7 on unsupported i7 MacMini. Everything went absolutely great, but i was "unable to establish a working SSH connection to this machine". The method im using is a standard password authentification way (no ports opened for this device, FW in MikroTik, without public IP etc...). The issue i was facing, that no password request appeared after SSH, but immediately "ssh_exchange_identification: read: Connection reset by peer" message popped up. I was searching for some solutions, and i was able to solve it by editing /private/etc/ssh/ssh_config or-and-only /private/etc/ssh/sshd_config.d/100-macos.conf...
Today, after month of testing - finding out what SW runs on this OS with which workaround etc, i decided to reinstall the whole system with newest 12.7.1 Monterey and configure it for unattended "Server". BUT i made amateur mistake, since i didnt saved that/those config files. Now im facing again the same issue, im unable to connect via ssh to this device. I lost today 4hours of searching, and i didnt get the right solution. As i mentioned, the password request didnt pops up in terminal, absolutely fresh installation again. Can you please help me to solve it guys ?

Thank you very much !

SSH from terminal from remote device to mentioned "server with Monterey" :

OpenSSH_7.9p1, LibreSSL 2.7.3
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug1: Connecting to 192.168.1.2 [192.168.1.2] port 22.
debug1: Connection established.
debug1: identity file /Users/macbookair11/.ssh/id_rsa type -1
debug1: identity file /Users/macbookair11/.ssh/id_rsa-cert type -1
debug1: identity file /Users/macbookair11/.ssh/id_dsa type -1
debug1: identity file /Users/macbookair11/.ssh/id_dsa-cert type -1
debug1: identity file /Users/macbookair11/.ssh/id_ecdsa type -1
debug1: identity file /Users/macbookair11/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/macbookair11/.ssh/id_ed25519 type -1
debug1: identity file /Users/macbookair11/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/macbookair11/.ssh/id_xmss type -1
debug1: identity file /Users/macbookair11/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
ssh_exchange_identification: read: Connection reset by peer
MacBook-Air-11:~ macbookair11$

SSH config :

# $OpenBSD: ssh_config,v 1.35 2020/07/17 03:43:42 dtucker Exp $

# This is the ssh client system-wide configuration file. See
# ssh_config(5) for more information. This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
# 1. command line options
# 2. user-specific file
# 3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# This Include directive is not part of the default ssh_config shipped with
# OpenSSH. Options set in the included configuration files generally override
# those that follow. The defaults only apply to options that have not been
# explicitly set. Options that appear multiple times keep the first value set,
# unless they are a multivalue option such as IdentityFile.
Include /etc/ssh/ssh_config.d/*

# Site-wide defaults for some commonly used options. For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

Host *
# ForwardAgent no
# ForwardX11 no
# PasswordAuthentication yes
# HostbasedAuthentication no
# GSSAPIAuthentication no
# GSSAPIDelegateCredentials no
# BatchMode no
# CheckHostIP yes
# AddressFamily any
# ConnectTimeout 0
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# IdentityFile ~/.ssh/id_ecdsa
# IdentityFile ~/.ssh/id_ed25519
# Port 22
# Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
# MACs hmac-md5,hmac-sha1,umac-64@openssh.com
# EscapeChar ~
# Tunnel no
# TunnelDevice any:any
# PermitLocalCommand no
# VisualHostKey no
# ProxyCommand ssh -q -W %h:%p gateway.example.com
# RekeyLimit 1G 1h
# UserKnownHostsFile ~/.ssh/known_hosts.d/%k

Host *
SendEnv LANG LC_*

SSHD_config.d = 100-macos.conf

EMPTY

 

[Grumpus]

@dnwldr: On the host you're trying to ssh into, open System Preferences..., click Sharing and make sure that Remote Login is enabled.

 

[dwnldr]

On the host you're trying to ssh into, open System Preferences..., click Sharing and make sure that Remote Login is enabled.

Thank you for your reply. Sure it is enabled The connection is also visible in logs :

debug1: Connecting to 192.168.1.2 [192.168.1.2] port 22.
debug1: Connection established.

 

[Grumpus]

On my supported Monterey 12.7.1 laptop, /etc/ssh/sshd_config.d/100-macos.conf looks like this:

# Options set by macOS that differ from the OpenSSH defaults.
UsePAM yes
AcceptEnv LANG LC_*
Subsystem    sftp    /usr/libexec/sftp-server

 

[dwnldr]

On my supported Monterey 12.7.1 laptop, /etc/ssh/sshd_config.d/100-macos.conf looks like this:

# Options set by macOS that differ from the OpenSSH defaults.
UsePAM yes
AcceptEnv LANG LC_*
Subsystem    sftp    /usr/libexec/sftp-server

Thank you very much !

Sadly, this doesnt helped :/ Damn, im so angry on myself that i didnt backed up those lines ive added month ago.
This issue is, that password prompt doesnt pop up, it just throws the message. Also the "question" about adding fingerprint doesnt shows up...

 

[Grumpus]

Log on to the Monterey server locally and start sshd in a terminal window with the debug option, listening on port 2222:

sudo /usr/sbin/sshd -d -p 2222

Debug messages should be printed in the terminal window. You can use multiple '-d' options, up to 3, to increase the debug level.

Now, back on your client machine, try to ssh in to the server:

ssh -v -p 2222 192.168.1.2

where 192.168.1.2 is the ip address of your server. Maybe sshd will print out something useful.

 

[dwnldr]

Log on to the Monterey server locally and start sshd in a terminal window with the debug option, listening on port 2222:

sudo /usr/sbin/sshd -d -p 2222

Debug messages should be printed in the terminal window. You can use multiple '-d' options, up to 3, to increase the debug level.

Now, back on your client machine, try to ssh in to the server:

ssh -v -p 2222 192.168.1.2

where 192.168.1.2 is the ip address of your server. Maybe sshd will print out something useful.

Thank you very very much for your effort !
So, actually the first command for starting the second server gave me some hints, since the output from terminal was :

homeserver@MacMini-HomeServer ~ % /usr/sbin/sshd -d -p 2222
/etc/ssh/sshd_config: No such file or directory

I dont understand how is it possible, since this is again fresh installation of this OS. I have only
/etc/ssh/sshd_config.d folder with the 100-macos.conf file (maybe this is some fingerprint of OpenCore patcher ? But how is it possible that i am the only one who had issues with SSH?) So ill grab the mentioned ".d" folder, made a dupllicate in /etc/ssh/ and renamed it to sshd_config. At this point, i was immediately able to execute the command and start the second sshd instance. HOWEVER, i can immediately use the "default" one on port 22. So "use" is not the right word, since now the issue with password appeared after third attempt to type it :

homeserver@192.168.1.2: Permission denied (publickey,password,keyboard-interactive)

debug1: Next authentication method: publickey
debug1: Trying private key: /Users/macbookair11/.ssh/id_rsa
debug1: Trying private key: /Users/macbookair11/.ssh/id_dsa
debug1: Trying private key: /Users/macbookair11/.ssh/id_ecdsa
debug1: Trying private key: /Users/macbookair11/.ssh/id_ed25519
debug1: Trying private key: /Users/macbookair11/.ssh/id_xmss
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
homeserver@192.168.1.2's password:
debug1: Authentications that can continue: publickey,password,keyboard-interactive
Permission denied, please try again.

I gave a shot and added some lines to the newly created sshd_config .conf file, but it still refuses to accept the password and ends with same Permission denied, please try again.

KbdInteractiveAuthentication yes
PasswordAuthentication yes
ChallengeResponseAuthentication yes

So we are closer, but i still cannot find the right way. I have no clue why is this happening, but i can point this issues only to LegacyPatcher, since i neved had such issues during 15years on macOS.

Do you have idea please, what should i try as next please ?

Thank you once again !

 

[Brian33]

I dont understand how is it possible, since this is again fresh installation of this OS. I have only
/etc/ssh/sshd_config.d folder with the 100-macos.conf file

Do I understand correctly? You are saying that you do not have a file '/etc/ssh/sshd_config' ?? You should have both that file and the /etc/ssh/sshd_config.d folder, which contains "100-macos.conf".

If you don't have an /etc/ssh/sshd_config file, that could well be the problem. On Monterey that file is almost all comments, but includes these two un-commented lines:

Include /etc/ssh/sshd_config.d/*
AuthorizedKeysFile   .ssh/authorized_keys

So ill grab the mentioned ".d" folder, made a dupllicate in /etc/ssh/ and renamed it to sshd_config.

I'm confused. You copied the ".d" folder and called it (the new folder) sshd_config, or did you copy the "100-macos.conf" file out of the .d folder and name it to sshd_config?

Either way, I would un-do this change. Leave the ".d" folder alone, and try making a "/etc/ssh/sshd_config" file containing the above lines. The first line causes the standard "100-macos.conf" to be automatically included in the configuration. I'm guessing that your sshd process isn't getting the lines within "100-macos.conf".

 

[Grumpus]

I'm attaching a copy of the sshd_config from my Monterey laptop. Copy it to /etc/ssh/sshd_config and make sure the owner and permissions are set correctly:

sudo cp sshd_config.txt /etc/ssh/sshd_config
sudo chown root:wheel /etc/ssh/sshd_config
sudo chmod 644 /etc/ssh/sshd_config

I'm not sure how much it will help though, as there are only 2 lines in the file which aren't commented out:

Include /etc/ssh/sshd_config.d/*
AuthorizedKeysFile    .ssh/authorized_keys

All of the commented lines should reflect the defaults, with the include overriding a few of those. My version of sshd is slightly newer than yours, but I don't think that should matter.

It's hard not to suspect OCLP at this point, and I did find this post on reddit complaining that OCLP's root patches broke sshd. Sorry, I'm out of ideas, but if I think of something I'll let you know.

EDIT: While you're trying to figure things out, it might not hurt to move the ~/.ssh directory on your client out of the way and start fresh:

mv ~/.ssh ~/old.dot.ssh
mkdir ~/.ssh
chmod 700 ~/.ssh

 

[dwnldr]

Do I understand correctly? You are saying that you do not have a file '/etc/ssh/sshd_config' ?? You should have both that file and the /etc/ssh/sshd_config.d folder, which contains "100-macos.conf".

If you don't have an /etc/ssh/sshd_config file, that could well be the problem. On Monterey that file is almost all comments, but includes these two un-commented lines:

Include /etc/ssh/sshd_config.d/*
AuthorizedKeysFile   .ssh/authorized_keys

I'm confused. You copied the ".d" folder and called it (the new folder) sshd_config, or did you copy the "100-macos.conf" file out of the .d folder and name it to sshd_config?

Either way, I would un-do this change. Leave the ".d" folder alone, and try making a "/etc/ssh/sshd_config" file containing the above lines. The first line causes the standard "100-macos.conf" to be automatically included in the configuration. I'm guessing that your sshd process isn't getting the lines within "100-macos.conf".

Brian, thank you for your comment and help !

Do I understand correctly? You are saying that you do not have a file '/etc/ssh/sshd_config' ??
- Exactly ! i have "/etc/ssh/sshd_config.d folder with 100-macos.conf" and i have "/etc/ssh/ssh_config file (with uncommented parameters for ssh)". But NO sshd_config file or folder was present in /etc/ssh/ = what was also the output from terminal, when i would like to start second instance of sshd.



I'm confused. You copied the ".d" folder and called it (the new folder) sshd_config, or did you copy the "100-macos.conf" file out of the .d folder and name it to sshd_config?
- So, ill grab the whole sshd_config.d (including 100-macos.conf"), made a duplicate and renamed (only) the folder to sshd_config (while the 100-macos.conf) is still untouched in this folder. After that i was immediately able to start new instance of sshd, but also the ssh homeserver@192.168.1.2 responded with fingerprint exchange, password prompt and -v output (till now it was only ssh_exchange_identification: read: Connection reset by peer message, and nothing else)

 

[dwnldr]

I'm attaching a copy of the sshd_config from my Monterey laptop. Copy it to /etc/ssh/sshd_config and make sure the owner and permissions are set correctly:

sudo cp sshd_config.txt /etc/ssh/sshd_config
sudo chown root:wheel /etc/ssh/sshd_config
sudo chmod 644 /etc/ssh/sshd_config

I'm not sure how much it will help though, as there are only 2 lines in the file which aren't commented out:

Include /etc/ssh/sshd_config.d/*
AuthorizedKeysFile    .ssh/authorized_keys

All of the commented lines should reflect the defaults, with the include overriding a few of those. My version of sshd is slightly newer than yours, but I don't think that should matter.

It's hard not to suspect OCLP at this point, and I did find this post on reddit complaining that OCLP's root patches broke sshd. Sorry, I'm out of ideas, but if I think of something I'll let you know.

EDIT: While you're trying to figure things out, it might not hurt to move the ~/.ssh directory on your client out of the way and start fresh:

mv ~/.ssh ~/old.dot.ssh
mkdir ~/.ssh
chmod 700 ~/.ssh

I cannot believe this !! Mate, actually this was the KEY = The missing sshd_config file and its permissions ! Honestly, i dont know how to thank enough for such effort, patience and help ! Thank you very much for that !
Im pretty sure, that MY workaround was totally different, since i know it was only about content editing.I dont understand the whole thing now... Honestly, this is the first time im using OCLP (since my i7 Server still works great, but the software limitations was the blockers), OCLP guys are doing INCREDIBLE job, they have lot of documentations, but no mention about this issue and about workaround how to solve it. I think, i will report this immediately and provide also your solution ! Im also wondering, how is it possible, that nobody from users experienced this huge error :/

!! Once again, thank you @Grumpus , thank you @Brian33 !!