Passwordless SSH login

R C cjvijf at gmail.com
Thu Feb 11 04:21:11 UTC 2021


On 2/10/21 9:09 PM, Bob wrote:
> ** Reply to message from R C <cjvijf at gmail.com> on Wed, 10 Feb 2021 20:25:00
> -0700
>
>> On 2/10/21 8:19 PM, Bob wrote:
>>> ** Reply to message from R C <cjvijf at gmail.com> on Wed, 10 Feb 2021 17:35:40
>>> -0700
>>>
>>>> On 2/10/21 5:17 PM, Karl Auer wrote:
>>>>> On Wed, 2021-02-10 at 15:49 -0800, Bob wrote:
>>>>>> I have set up SSH between two computers on my LAN and am trying to
>>>>>> disable password login.
>>>>> I'm wondering if you are confusing the password on the account with the
>>>>> passphrase on the ssh key.
>>>>>
>>>>> Also, each time you change the sshd configuration file you need to
>>>>> restart the sshd server for the change to "take":
>>>>>
>>>>>       systemctl restart sshd
>>>> I think OP is trying to do key based logins. (host based or priv/pub key
>>>> pair?)
>>> I am trying to only allow a key based login.
>>>
>>>
>>>> You can disable  'regular' password logins with
>>>> "|PasswordAuthentication no" I believe, BUT, that would only allow
>>>> logons from machines key based.|
>>> Which is what I want.  I do have "PasswordAuthentication no".  The
>>> documentation I have says that you also need "ChallengeResonpseAuthentication
>>> no".
>>>
>> probably not necessary to ask, but, did you restart sshd? (systemctl
>> restart sshd)  after the changes ?  and if so   what does systemctl
>> status sshd say?
>> bob1 at Juptier:~$ systemctl status sshd
>     ssh.service - OpenBSD Secure Shell server
>       Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset:
> enabled)
>       Active: active (running) since Wed 2021-02-10 14:13:00 PST; 5h 33min ago



It doesn't look like you restarted the service in the last few hours, it 
has been up  for over 5 hours


do a "systemctl restart sshd". as root or a "sudo systemctl restart 
sshd" on the server, not the client


>         Docs: man:sshd(8)
>               man:sshd_config(5)
>      Process: 14029 ExecStartPre=/usr/sbin/sshd -t (code=exited,
> status=0/SUCCESS)
>     Main PID: 14030 (sshd)
>        Tasks: 1 (limit: 4514)
>       Memory: 2.3M
>       CGroup: /system.slice/ssh.service
>               └─14030 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
>
> Feb 10 14:13:00 Juptier systemd[1]: Starting OpenBSD Secure Shell server...
> Feb 10 14:13:00 Juptier sshd[14030]: Server listening on 0.0.0.0 port 22.
> Feb 10 14:13:00 Juptier sshd[14030]: Server listening on :: port 22.
> Feb 10 14:13:00 Juptier systemd[1]: Started OpenBSD Secure Shell server.
> Feb 10 14:19:01 Juptier sshd[14047]: Accepted publickey for bob1 from
> 192.168.60.182 port 57830 ssh2: RSA
> SHA256:2vjQjFca63GJ3xu9FMPbqOmpR5yb+VEImHWexHfg510
> Feb 10 14:19:01 Juptier sshd[14047]: pam_unix(sshd:session): session opened for
> user bob1 by (uid=0)
> Feb 10 14:36:10 Juptier sshd[14132]: Accepted password for bob1 from
> 192.168.60.182 port 52326 ssh2
> Feb 10 14:36:10 Juptier sshd[14132]: pam_unix(sshd:session): session opened for
> user bob1 by (uid=0)
> bob1 at Juptier:~$
>   
>> also,  you can see debugging info with ssh -v uid at host.dom,  or -vv or
>> -vvv  to see what methods it is trying.
> I will try this.
>
> Not sure it  will be helpful.  I think the problem is SSH configuration and the
> information I have is most likely incorrect.
>
>
>>>> |(you can also make changes in the pam stack,  but I'd be hesitant to do
>>>> that)
>>>> |
>>>>
>>>> |If you'd go either route, I'd allow  root logins at the console, so
>>>> that when something gets messed up with the keys (and users (including
>>>> yourself) will mess up their keys), you'd still have a  reasonable way in.
>>>> |
>>>>
>>>>
>>>> R
>>>>
>>>>> Regards, K.




More information about the ubuntu-users mailing list