Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Question:

Question: ssh failure after upgrading to high sierra

Hello apple network users/experts

Since upgrading our laboratory MacBook Pro laptops OS to high Sierra almost all of our computers fail to connect to the remote servers using our laboratory intranet cable with the embedded errors :

I thought some of the experts here might be able to give some advice.

surprisingly it works fine with WIFI and older OS. No firewall/ blocking issue was identified.

We will deeply appreciate your helps.


Arsalans-MacBook-Pro:~ arsalan$ ssh -v ***

OpenSSH_7.6p1, LibreSSL 2.6.2

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: /etc/ssh/ssh_config line 48: Applying options for *

debug1: Connecting to *** port 22.

debug1: Connection established.

debug1: key_load_public: No such file or directory

debug1: identity file /Users/arsalan/.ssh/id_rsa type -1

debug1: key_load_public: No such file or directory

debug1: identity file /Users/arsalan/.ssh/id_rsa-cert type -1

debug1: key_load_public: No such file or directory

debug1: identity file /Users/arsalan/.ssh/id_dsa type -1

debug1: key_load_public: No such file or directory

debug1: identity file /Users/arsalan/.ssh/id_dsa-cert type -1

debug1: key_load_public: No such file or directory

debug1: identity file /Users/arsalan/.ssh/id_ecdsa type -1

debug1: key_load_public: No such file or directory

debug1: identity file /Users/arsalan/.ssh/id_ecdsa-cert type -1

debug1: key_load_public: No such file or directory

debug1: identity file /Users/arsalan/.ssh/id_ed25519 type -1

debug1: key_load_public: No such file or directory

debug1: identity file /Users/arsalan/.ssh/id_ed25519-cert type -1

debug1: Local version string SSH-2.0-OpenSSH_7.6

debug1: Remote protocol version 2.0, remote software version xxxxxxx

debug1: no match: xxxxxxx

debug1: Authenticating to foo :22 as 'foo'

debug1: SSH2_MSG_KEXINIT sent

Connection closed by *.*.*.* port 22

<Personal Information Edited by Host>

Posted on

Reply

Dec 20, 2017 7:13 AM in response to arsalane In response to arsalane

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

Dec 20, 2017 7:13 AM

Reply Helpful

Dec 20, 2017 9:39 AM in response to jjennings089 In response to jjennings089

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:

Dec 20, 2017 9:39 AM

Reply Helpful

Dec 20, 2017 9:50 AM in response to arsalane In response to arsalane

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.

Dec 20, 2017 9:50 AM

Reply Helpful (1)

Dec 20, 2017 9:52 AM in response to Jason Hirsh In response to Jason Hirsh

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.


#$OpenBSD: sshd_config,v 1.101 2017/03/14 07:19:07 djm Exp $



# 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

AuthorizedKeysFile.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

Subsystemsftp/usr/libexec/sftp-server



# Example of overriding settings on a per-user basis

#Match User anoncvs

#X11Forwarding no
#AllowTcpForwarding no
#PermitTTY no
#ForceCommand cvs server

Dec 20, 2017 9:52 AM

Reply Helpful (2)
User profile for user: arsalane

Question: ssh failure after upgrading to high sierra