quite OT

Mon Sep 3 15:22:52 UTC 2018

I can log in from a reasonably recent Linux or Solaris 10 or later system (well, the Linux is a VM) to my High Sierra using keys (with or without ssh-agent) just fine.  No problem at all.

In the case of a really old Solaris (9) box, the defaults for High Sierra's sshd didn't include ciphers or key exchange algorithms that the old Solaris 9 client knew about.  But (at the risk of reducing security on the High Sierra system!!!), I could add the following to the High Sierra system's /etc/ssh/sshd_config:

Ciphers chacha20-poly1305 at openssh.com,aes128-ctr,aes128-cbc,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com
KexAlgorithms diffie-hellman-group1-sha1,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1

and after that, get in from the ancient client too. Contrast that with the defaults described in the sshd_config man page, if you want to determine what old stuff was added.  I probably needed both lines; first it failed finding a cipher, then it said "no kex alg", which the 2nd line took care of. Fairly sure the old stuff that was fixed it was the aes128-cbc, and the diffie-helman-group1-sha1, respectively.  I found the 2nd line by googling "no kex alg".  Probably those could be tweaked a bit.  Some clients may cope with a limited number of possibilities for one or the other, so what they need should probably be near the beginning of the list, although being paranoid, I'd just as soon put it as far down the list as the crankiest client would accept, so better stuff would be used whenever possible.

To figure this stuff out from scratch, add a -v or two to the failing ssh command to see what it's trying; if you look through that, and then look through the sshd_config man page on the destination system, you'll hopefully find a common cipher and kex algorithm, which is what you need to make sure you add to the defaults.

Now I think I'm going to go back and comment those lines out, because I can think of ZERO times I'm likely to log in from a 2001 vintage Sun Blade 100 running Solaris 9, to a 2017 MacBook Pro running High Sierra.  Not worth the exposure, esp. if I travel with the laptop, such that unless I VPN, it could get pounded by random crazies.

NOTE: truly ancient clients use version 1 of the ssh protocol, which openssh as of High Sierra says (per the man page) it does NOT support.  The man page for the MacPorts version says the same thing; so in that case, you're out of luck.  And BTW, I just did a diff between Apple's sshd man page and the MacPorts man page, and the ONLY differences were path names for configuration files, the pid file, etc.  So if you can't solve your issues for one, using the other probably won't help either.

> On Sep 3, 2018, at 09:50, James <jam at tigger.ws> wrote:
> 
> Top Posting as all the noise below may be of interest, but it may not be.
> 
> Actually re-reading my post shows my irritation with Jan’s post. I guess that I’m here because of a significant and so far insoluable problem and I welcome any ideas or caveats, I think his tone trivializes my angst, appologies!
> 
> Jan I must assume that you have never done a password-less login to a high sierra machine and the tone of your questions betrays that.
> I have mumble (aah hell 40 years experience using unix and I have and do do many many password-less logins eg gathering data frrom an embedded logger) so the stock right-way is cute, but moot
> 
>> On 3 Sep 2018, at 8:00 pm, macports-users-request at lists.macports.org <mailto:macports-users-request at lists.macports.org> wrote:
>> 
>>> but directly related to a port <smile>
>> 
>> What port?
> 
> actually openssh which works everywhere ( where works == password-less login NB nothing to do with pass-phrase) does not work on high sierra
> 
>> 
>>> I want password-less ssh login
>> 
>> Create a password-less key and copy it into
>> ~/.ssh/authorized_keys on the remote site.
>> 
>> Make sure that ~/.ssh is chmod 700 and authorized_keys is chmod 600
>> if you are creating them from scratch. (The OS possibly did that for you
>> upon user creation.)
>> 
>>> i usually copy the public key by hand, but I also used ssh-copy-id
>>> from 1_mac to another
>>> from 1_mac to itself
>>> from 1_mac to a plethora of linux machines and virtual machines
>>> 
>>> 1_mac cannot login passwd-less to another.
>> 
>> To another what?
> 
> The original post made clear I called the first mac "mac-1" and the second mac “another"
> 
>> What happens if you copy the key by hand, not relying on ssh-copy-id?
>> Have you checked that the key is actually installed there?
> 
> By hand and with ssh-copy-id achieves identical results. I’ve also generated id_rsa and id_rsa.pub on linux machines (In case apple does something bizare)
> 
>>> Passwd is requested then all is well.
>> 
>> What password, if it's a password-less key?
> 
> if public key auth fails then you fall back to password auth
> 
>>> 1_mac CAN login to itself passwdless
> 
> And with openssh that happens too. I’ve not tried user a login to user b, I shall try in the morning
> 
>>> 1_mac CAN login to the linux boxes passwdless
>>> 
>>> The logs show nothing of interest (-vvv, not tried to get server logs yet)
>> 
>> You have succesfully logged in. The logs will say so.
>> What else do you expect to see there?
> 
> Umm I’m confused. I see a password prompt not a shell prompt. I see too public_key auth failed wthi error 51 before password auth gets tried
> 
>>> Google is full of stuff, eg since High Sierra Apple silently enforces a 2048 bit key, but nothing that actually solves the problem
>> 
>> What problem?
> 
> Again ummmm. Password-less login. I can see my suspition is not happening which was blank pass phrase is not allowed.
> 
>> On Sep 01 17:45:13, dave at horsfall.org <mailto:dave at horsfall.org> wrote:
>>>> I want password-less ssh login
>>>> i usually copy the public key by hand, but I also used ssh-copy-id
>>> 
>>> I've done that, but I think it involved temporarily enabling TELNET etc,
>>> then ye olde copy/paste of the public key.
>> 
>> Why would you use TELNET to transfer your ssh key?
>> To completely defeat the purpose?
> 
> I think one of the answers mentioned telnet, I certainly did not.
> 
> James

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20180903/4bc6a201/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 874 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20180903/4bc6a201/attachment.sig>