ssh failure after upgrading to high sierra

after lots of tweaking I was never ever to get connected by password.. but when I went through process of adding a ssh key it works fine You will haveto find a workaround for getting the key to the server

https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys--2

i also copied across my public key to try that nothing works

jjennings089 wrote:

can you post your debug from SSH? ssh -v user_name@server_address

OpenSSH_7.2p2, OpenSSL 1.0.2k-freebsd 26 Jan 2017

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: Connecting to 10.0.1.175 [10.0.1.175] port 22.

debug1: Connection established.

debug1: identity file /home/jason/.ssh/id_rsa type 1

debug1: Fssh_key_load_public: No such file or directory

debug1: identity file /home/jason/.ssh/id_rsa-cert type -1

debug1: Fssh_key_load_public: No such file or directory

debug1: identity file /home/jason/.ssh/id_dsa type -1

debug1: Fssh_key_load_public: No such file or directory

debug1: identity file /home/jason/.ssh/id_dsa-cert type -1

debug1: Fssh_key_load_public: No such file or directory

debug1: identity file /home/jason/.ssh/id_ecdsa type -1

debug1: Fssh_key_load_public: No such file or directory

debug1: identity file /home/jason/.ssh/id_ecdsa-cert type -1

debug1: Fssh_key_load_public: No such file or directory

debug1: identity file /home/jason/.ssh/id_ed25519 type -1

debug1: Fssh_key_load_public: No such file or directory

debug1: identity file /home/jason/.ssh/id_ed25519-cert type -1

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_7.2 FreeBSD-20161230

debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6

debug1: match: OpenSSH_7.6 pat OpenSSH* compat 0x04000000

debug1: Authenticating to 10.0.1.175:22 as 'jason'

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: kex: algorithm: curve25519-sha256@libssh.org

debug1: kex: host key algorithm: ecdsa-sha2-nistp256

debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none

debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none

debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

debug1: Server host key: ecdsa-sha2-nistp256 SHA256:FJYXYK+/nTJfwB767fRSryWEEVDyo7UyVAX3+xttD6k

debug1: skipped DNS lookup for numerical hostname

debug1: Host '10.0.1.175' is known and matches the ECDSA host key.

debug1: Found key in /home/jason/.ssh/known_hosts:2

debug1: rekey after 134217728 blocks

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug1: rekey after 134217728 blocks

debug1: SSH2_MSG_NEWKEYS received

debug1: SSH2_MSG_EXT_INFO received

debug1: Fssh_kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sh a2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>

debug1: SSH2_MSG_SERVICE_ACCEPT received

debug1: Authentications that can continue: publickey,password,keyboard-interactive

debug1: Next authentication method: publickey

debug1: Offering RSA public key: /home/jason/.ssh/id_rsa

debug1: Authentications that can continue: publickey,password,keyboard-interactive

debug1: Trying private key: /home/jason/.ssh/id_dsa

debug1: Trying private key: /home/jason/.ssh/id_ecdsa

debug1: Trying private key: /home/jason/.ssh/id_ed25519

debug1: Next authentication method: keyboard-interactive

debug1: Authentications that can continue: publickey,password,keyboard-interactive

debug1: Next authentication method: password

jason@10.0.1.175's password:

debug1: Authentications that can continue: publickey,password,keyboard-interactive

Permission denied, please try again.

jason@10.0.1.175's password:

ssh -vvv can provide more detail on the connection, and you'll also want to check the server sshd logs for any clues from that end of the connection. Usual trigger I've seen with these is a client and a server disagreeing on the key exchange or on the available encryption algorithms.

Are there any (more) details for the following, or is that "xxxxxxx" string what was really returned?

debug1: Remote protocol version 2.0, remote software version xxxxxxx

debug1: no match: xxxxxxx

If you have it around on one of your local systems and don't otherwise have access to the settings on the remote server, nmap can be used to scan the ssh server and return its capabilities. nmap is available via homebrew or can be downloaded and built for various platforms including macOS from the canonical sources.

nmap --script ssh2-enum-algos -sV -p 22 your.server.example.net

For the other end of the ssh connection, you can ask your ssh client what ciphers, message authentication codes and key exchanges are supported with the following:

ssh -Q cipher

ssh -Q mac

ssh -Q kex

Of these, I've been usually been encountering problems with kex deprecations, and with deprecated ciphers. Where the newer configurations dropped support for the more insecure choices for the key exchange and for encryption. I haven't seen incompatibilities involving the message authentication code support (yet?).

As others have mentioned, I'd also set up the local .ssh directories, and make sure the private files are all appropriately protected. ssh can get really cranky about incorrect protections on the files, though I don't suspect that's the case here.

Here is the default configuration for SSH on the Mac: Do a compare or copy and restart ssh. Be sure to check the PAM I have seen some people say Pam NO is better.

# This is the sshd server system-wide configuration file. See

# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with

# OpenSSH is to specify options with their default value where

# possible, but leave them commented. Uncommented options override the

# default value.

#Port 22

#AddressFamily any

#ListenAddress 0.0.0.0

#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key

#HostKey /etc/ssh/ssh_host_dsa_key

#HostKey /etc/ssh/ssh_host_ecdsa_key

#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying

#RekeyLimit default none

# Logging

#SyslogFacility AUTH

#LogLevel INFO

# Authentication:

#LoginGraceTime 2m

#PermitRootLogin prohibit-password

#StrictModes yes

#MaxAuthTries 6

#MaxSessions 10

#PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2

# but this is overridden so installations will only check .ssh/authorized_keys

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none

#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts

#HostbasedAuthentication no

# Change to yes if you don't trust ~/.ssh/known_hosts for

# HostbasedAuthentication

#IgnoreUserKnownHosts no

# Don't read the user's ~/.rhosts and ~/.shosts files

#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!

#PasswordAuthentication yes

#PermitEmptyPasswords no

# Change to no to disable s/key passwords

#ChallengeResponseAuthentication yes

# Kerberos options

KerberosAuthentication yes

KerberosOrLocalPasswd yes

KerberosTicketCleanup yes

#KerberosGetAFSToken no

# GSSAPI options

GSSAPIAuthentication yes

GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing,

# and session processing. If this is enabled, PAM authentication will

# be allowed through the ChallengeResponseAuthentication and

# PasswordAuthentication. Depending on your PAM configuration,

# PAM authentication via ChallengeResponseAuthentication may bypass

# the setting of "PermitRootLogin without-password".

# If you just want the PAM account and session checks to run without

# PAM authentication, then enable this but set PasswordAuthentication

# and ChallengeResponseAuthentication to 'no'.

UsePAM yes

#AllowAgentForwarding yes

#AllowTcpForwarding yes

#GatewayPorts no

#X11Forwarding no

#X11DisplayOffset 10

#X11UseLocalhost yes

#PermitTTY yes

#PrintMotd yes

#PrintLastLog yes

#TCPKeepAlive yes

#UseLogin no

#PermitUserEnvironment no

#Compression delayed

#ClientAliveInterval 0

#ClientAliveCountMax 3

#UseDNS no

#PidFile /var/run/sshd.pid

#MaxStartups 10:30:100

#PermitTunnel no

#ChrootDirectory none

#VersionAddendum none

# pass locale information

AcceptEnv LANG LC_*

# no default banner path

#Banner none

# override default of no subsystems

# Example of overriding settings on a per-user basis

#Match User anoncvs

I had a similar issue. Here was my fix. Re: Re: SSH server not working after upgrade to MacOS High Sierra (11.3)

Does your ssh user look like the image I posted here? Re: Re: SSH server not working after upgrade to MacOS High Sierra (11.3)

This is a "me too" I went to your fix and found that I too already had a "-sshd user" there. Any more thoughts??

never mind this didnt work either

can you post your debug from SSH? ssh -v user_name@server_address

copied the sample across you provided and it worked perfectly!!! thanks

Glad to help. Sorry I know you started this tread a while ago, Holidays time is crazy.