[opensuse] ssh without passwd
"ssh-keygen" generated ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub Then ~/.ssh/id_rsa.pub has been copied to the remote site and given the name ~/.ssh/authorized_keys there. Whereas ssh without password from a SuSE 13.2 site to a Leap 15.1 site works perfectly for any user, from a Leap 15.1 site to a SuSE 13.2 site it works for root only, and different users are asked for a password. How can I achieve ssh to be accepted without password for "normal" users, too? Thanks in advance for your help. Wolfgang -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Op maandag 2 september 2019 20:30:46 CEST schreef Wolfgang Mueller:
"ssh-keygen" generated ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub
Then ~/.ssh/id_rsa.pub has been copied to the remote site and given the name ~/.ssh/authorized_keys there.
Whereas ssh without password from a SuSE 13.2 site to a Leap 15.1 site works perfectly for any user, from a Leap 15.1 site to a SuSE 13.2 site it works for root only, and different users are asked for a password.
How can I achieve ssh to be accepted without password for "normal" users, too?
Thanks in advance for your help.
Wolfgang I've seen no changes. It might be the ssh versions not matching. Can't check, I have no 13.2 running anymore ( and IMHO no one should ). ..
-- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/09/2019 20:46, Knurpht-openSUSE wrote:
Op maandag 2 september 2019 20:30:46 CEST schreef Wolfgang Mueller:
"ssh-keygen" generated ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub
Then ~/.ssh/id_rsa.pub has been copied to the remote site and given the name ~/.ssh/authorized_keys there.
Whereas ssh without password from a SuSE 13.2 site to a Leap 15.1 site works perfectly for any user, from a Leap 15.1 site to a SuSE 13.2 site it works for root only, and different users are asked for a password.
How can I achieve ssh to be accepted without password for "normal" users, too?
Thanks in advance for your help.
Wolfgang I've seen no changes. It might be the ssh versions not matching. Can't check, I have no 13.2 running anymore ( and IMHO no one should ). ..
I just noticed today when making note of a new ssh fingerprint that the more recent ones are preceded by SHA256:/, and SHA256 is also shown at the bottom of the randomart image, whilst my oldest ones fingerprints are different, consisting of a string of 16 hex pairs. Maybe that has something to do with it? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 2 Sep 2019 20:30:46 +0200 Wolfgang Mueller wrote:
"ssh-keygen" generated ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub
Then ~/.ssh/id_rsa.pub has been copied to the remote site and given the name ~/.ssh/authorized_keys there.
Whereas ssh without password from a SuSE 13.2 site to a Leap 15.1 site works perfectly for any user, from a Leap 15.1 site to a SuSE 13.2 site it works for root only, and different users are asked for a password.
How can I achieve ssh to be accepted without password for "normal" users, too?
Thanks in advance for your help.
Wolfgang
notwithstanding Knurpht's sensible comments: *Where* the public key is being copied to, on the remote system, might explain these differences in behavior. For example (hypothetical): If ssh-keygen on the local 13.2 system copies the public key somewhere under /etc/ssh/, this could conceivably cause the key to be recognized "globally" -- i.e. on behalf of any user account on the remote system, and, this arrangement would obviously have some potentially very serious negative security implications (I wouldn't allow this,) whereas, if ssh-keygen on the 15.1 local system is placing the file remotely under ~/.ssh *only* in the specified user's home directory -- remember, the "~/" in the commands you're invoking is shorthand for the user's home directory -- then this would explain why "it works for root only" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 2 Sep 2019 at 21:24:16 +0200, Carl Hartung wrote:
On Mon, 2 Sep 2019 20:30:46 +0200 Wolfgang Mueller wrote:
"ssh-keygen" generated ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub
Then ~/.ssh/id_rsa.pub has been copied to the remote site and given the name ~/.ssh/authorized_keys there.
Whereas ssh without password from a SuSE 13.2 site to a Leap 15.1 site works perfectly for any user, from a Leap 15.1 site to a SuSE 13.2 site it works for root only, and different users are asked for a password.
How can I achieve ssh to be accepted without password for "normal" users, too?
notwithstanding Knurpht's sensible comments:
*Where* the public key is being copied to, on the remote system, might explain these differences in behavior. For example (hypothetical):
If ssh-keygen on the local 13.2 system copies the public key somewhere under /etc/ssh/, this could conceivably cause the key to be recognized "globally" -- i.e. on behalf of any user account on the remote system, and, this arrangement would obviously have some potentially very serious negative security implications (I wouldn't allow this,)
whereas,
if ssh-keygen on the 15.1 local system is placing the file remotely under ~/.ssh *only* in the specified user's home directory -- remember, the "~/" in the commands you're invoking is shorthand for the user's home directory -- then this would explain why "it works for root only"
Under 13.2 as well as under 15.1, ssh-keygen generates the files id_rsa and id_rsa.pub and places them in the local ~/.ssh/ *only*, neither in /etc/ssh/, nor anywhere on the remote machine. The user then has has to copy id_rsa.pub to ~/.ssh/authorized_keys on the remote machine. Wolfgang -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 2 Sep 2019 21:55:05 +0200 Wolfgang Mueller wrote:
Under 13.2 as well as under 15.1, ssh-keygen generates the files id_rsa and id_rsa.pub and places them in the local ~/.ssh/ *only*, neither in /etc/ssh/, nor anywhere on the remote machine. The user then has has to copy id_rsa.pub to ~/.ssh/authorized_keys on the remote machine.
Ah, of course, I've always tended to forget the ssh-copy id step :) So, what commands are you invoking to actually copy the keys to the remote systems? Any difference? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 2 Sep 2019 at 22:04:33 +0200, Carl Hartung wrote:
On Mon, 2 Sep 2019 21:55:05 +0200 Wolfgang Mueller wrote:
Under 13.2 as well as under 15.1, ssh-keygen generates the files id_rsa and id_rsa.pub and places them in the local ~/.ssh/ *only*, neither in /etc/ssh/, nor anywhere on the remote machine. The user then has has to copy id_rsa.pub to ~/.ssh/authorized_keys on the remote machine.
Ah, of course, I've always tended to forget the ssh-copy id step :)
So, what commands are you invoking to actually copy the keys to the remote systems? Any difference?
Since the remote systems are mounted with NFS, I use "cp". Wolfgang -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 2 Sep 2019 22:33:13 +0200 Wolfgang Mueller wrote:
On Mon, 2 Sep 2019 at 22:04:33 +0200, Carl Hartung wrote:
On Mon, 2 Sep 2019 21:55:05 +0200 Wolfgang Mueller wrote:
Under 13.2 as well as under 15.1, ssh-keygen generates the files id_rsa and id_rsa.pub and places them in the local ~/.ssh/ *only*, neither in /etc/ssh/, nor anywhere on the remote machine. The user then has has to copy id_rsa.pub to ~/.ssh/authorized_keys on the remote machine.
Ah, of course, I've always tended to forget the ssh-copy id step :)
So, what commands are you invoking to actually copy the keys to the remote systems? Any difference?
Since the remote systems are mounted with NFS, I use "cp".
Wolfgang
ssh-copy-id appends the user's public key to the specified ~/.ssh/.authorized_keys file on the remote system (and, simultaneously, the remote system's public key to ~/.ssh/known_hosts, locally.) Are you using a comparable invocation of 'cp' to accomplish the same thing? Instead of parsing out details 'on demand,' what if you were to copy and paste real, complete examples of the commands you've invoked which have resulted in bringing the 13.2 vs 15.1 differences to light? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Wolfgang Mueller <wm@ariannuccia.de> [09-02-19 14:34]:
"ssh-keygen" generated ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub
Then ~/.ssh/id_rsa.pub has been copied to the remote site and given the name ~/.ssh/authorized_keys there.
Whereas ssh without password from a SuSE 13.2 site to a Leap 15.1 site works perfectly for any user, from a Leap 15.1 site to a SuSE 13.2 site it works for root only, and different users are asked for a password.
How can I achieve ssh to be accepted without password for "normal" users, too?
and you generated a different key for root and <user> and ssh-copy-id to subject systems? -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 2 Sep 2019 at 21:47:20 +0200, Patrick Shanahan wrote:
Wolfgang Mueller <wm@ariannuccia.de> [09-02-19 14:34]:
"ssh-keygen" generated ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub
Then ~/.ssh/id_rsa.pub has been copied to the remote site and given the name ~/.ssh/authorized_keys there.
Whereas ssh without password from a SuSE 13.2 site to a Leap 15.1 site works perfectly for any user, from a Leap 15.1 site to a SuSE 13.2 site it works for root only, and different users are asked for a password.
How can I achieve ssh to be accepted without password for "normal" users, too?
and you generated a different key for root and <user> and ssh-copy-id to subject systems?
The keys of root and each of my two users are different. An attempt to use the same keys generated a big mess which I don't want to expose here for not further complicating this discussion. Wolfgang -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Wolfgang Mueller <wm@ariannuccia.de> [09-02-19 16:44]:
On Mon, 2 Sep 2019 at 21:47:20 +0200, Patrick Shanahan wrote:
Wolfgang Mueller <wm@ariannuccia.de> [09-02-19 14:34]:
"ssh-keygen" generated ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub
Then ~/.ssh/id_rsa.pub has been copied to the remote site and given the name ~/.ssh/authorized_keys there.
Whereas ssh without password from a SuSE 13.2 site to a Leap 15.1 site works perfectly for any user, from a Leap 15.1 site to a SuSE 13.2 site it works for root only, and different users are asked for a password.
How can I achieve ssh to be accepted without password for "normal" users, too?
and you generated a different key for root and <user> and ssh-copy-id to subject systems?
The keys of root and each of my two users are different. An attempt to use the same keys generated a big mess which I don't want to expose here for not further complicating this discussion.
but that is how it works: you generate the key as root ssh-copy-id -i .ssh/id_rsa.pub root@<site> and check it worked you generate the key as <user> ssh-copy-id -i .ssh/id_rsa.pub <user>@<site> and check it worked what's to expose? you need to follow the procedure. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Patrick Shanahan wrote:
but that is how it works: you generate the key as root ssh-copy-id -i .ssh/id_rsa.pub root@<site> and check it worked
you generate the key as <user> ssh-copy-id -i .ssh/id_rsa.pub <user>@<site> and check it worked
what's to expose?
you need to follow the procedure.
It probably has zero bearing on Wolfgang's issue, but I also never use "ssh-copy-id" - vi and copy&paste has (sofar) always worked for me. -- Per Jessen, Zürich (12.6°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/09/2019 07.29, Per Jessen wrote:
Patrick Shanahan wrote:
but that is how it works: you generate the key as root ssh-copy-id -i .ssh/id_rsa.pub root@<site> and check it worked
you generate the key as <user> ssh-copy-id -i .ssh/id_rsa.pub <user>@<site> and check it worked
what's to expose?
you need to follow the procedure.
It probably has zero bearing on Wolfgang's issue, but I also never use "ssh-copy-id" - vi and copy&paste has (sofar) always worked for me.
I do, in the initial setup. It is easier. But once the server disables password entry, it stops working for new users, obviously: they can not shh till a user with access does it for them. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Wolfgang Mueller wrote:
"ssh-keygen" generated ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub
Then ~/.ssh/id_rsa.pub has been copied to the remote site and given the name ~/.ssh/authorized_keys there.
Whereas ssh without password from a SuSE 13.2 site to a Leap 15.1 site works perfectly for any user, from a Leap 15.1 site to a SuSE 13.2 site it works for root only, and different users are asked for a password.
How can I achieve ssh to be accepted without password for "normal" users, too?
Hi Wolfgang FWIW, I cannot reproduce. I have just now run ssh-keygen (default options) on a 15.1 system, for user 'per', copy&pasted the public key to a 13.2 system into ~/.ssh/authorized_keys. It worked very well: per@heron:~> ssh dupont8.enidan.com The authenticity of host 'dupont8.enidan.com (192.168.4.208)' can't be established. ECDSA key fingerprint is SHA256:WJz6TSc/Wh6RNpxWD6/E3jFFr/qCdyM2fy3juljWNoc. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'dupont8.enidan.com,192.168.4.208' (ECDSA) to the list of known hosts. Last login: Tue Dec 4 09:27:42 2018 from 2001:db8:9c68:1:221:86ff:fe4f:8ac4 Have a lot of fun... per@dupont8:~> I also tried rsa with a longer key, with ecdsa and ed25519 - no problems. -- Per Jessen, Zürich (11.3°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/02/2019 01:30 PM, Wolfgang Mueller wrote:
Then ~/.ssh/id_rsa.pub has been copied to the remote site and given the name ~/.ssh/authorized_keys there.
Note: "given the name ~/.ssh/authorized_keys there." can only occur when you are adding the FIRST key to authorized_keys, for all other additions, you must APPEND the key to the end of the authorized keys file, e.g. cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys Also note: the permission for the file authorized keys must be 0640, e.g.: -rw------- 1 david david 5205 May 24 14:28 authorized_keys When testing your connection, check with: ssh -vv you@remote.host That will give detailed information on each authentication attempt. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David C. Rankin wrote:
On 09/02/2019 01:30 PM, Wolfgang Mueller wrote:
Then ~/.ssh/id_rsa.pub has been copied to the remote site and given the name ~/.ssh/authorized_keys there.
Note: "given the name ~/.ssh/authorized_keys there." can only occur when you are adding the FIRST key to authorized_keys, for all other additions, you must APPEND the key to the end of the authorized keys file, e.g.
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
Also note: the permission for the file authorized keys must be 0640, e.g.:
-rw------- 1 david david 5205 May 24 14:28 authorized_keys
Uh, why would that be? They're just public keys. Works fine here with 0644. -- Per Jessen, Zürich (14.5°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2019-09-03 09:37, Per Jessen wrote:
Uh, why would that be? They're just public keys. Works fine here with 0644.
Although I agree with you the man page recommends 600. from man ssh: ~/.ssh/authorized_keys Lists the public keys (DSA, ECDSA, Ed25519, RSA) that can be used for logging in as this user. The format of this file is described in the sshd(8) manual page. This file is not highly sensitive, but the recommended permissions are read/write for the user, and not accessible by others. -- /bengan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Wolfgang, et al -- ...and then David C. Rankin said... % % On 09/02/2019 01:30 PM, Wolfgang Mueller wrote: % > Then ~/.ssh/id_rsa.pub has been copied to the remote site and given the name % > ~/.ssh/authorized_keys there. % ... % Also note: the permission for the file authorized keys must be 0640, e.g.: % % -rw------- 1 david david 5205 May 24 14:28 authorized_keys [snip] I read "should" rather than "must", but permissions are definitely a concern. I'm pretty sure that sshd will barf if either the .ssh dir is open to others at all or if any parent directory is writable by others, which could lead to a substitution hack. I'd check davidtg@wench:~/.ssh> ls -ld / ; P='' ; for D in ` pwd | tr '/' ' ' ` ; do P=$P/$D ; ls -ld $P ; done drwxrwxr-x 21 root root 4096 Sep 3 01:15 / drwxr-xr-x 4 root root 4096 Mar 19 2018 /mnt drwxrwxr-x 10 root root 360 Jul 6 2018 /mnt/data drwxr-xr-x 4 root root 96 Jan 31 2018 /mnt/data/home drwxr-x--x 40 davidtg users 1800 Sep 3 23:09 /mnt/data/home/davidtg drwx------ 2 davidtg users 272 Aug 22 21:54 /mnt/data/home/davidtg/.ssh the perms of all dirs from root to user as well. HTH & HAND :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David C. Rankin wrote:
When testing your connection, check with:
ssh -vv you@remote.host
Seconding that one, and check if the remote host supports the encryption type... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (11)
-
Bengt Gördén -
Carl Hartung -
Carlos E. R. -
David C. Rankin -
David T-G -
gumb -
Knurpht-openSUSE -
Patrick Shanahan -
Per Jessen -
Peter Suetterlin -
Wolfgang Mueller