LLLActive@GMX.Net wrote:
On Thu, 08 Mar 2012 04:39:00 +0100 "LLLActive@GMX.Net"
wrote: Hi all,
I've done the following procedure to get a passwordless login on a remote server:
as root:
$ ssh-keygen Enter file in which to save the key (/home/your_user/.ssh/id_rsa): <Enter> Enter passphrase (empty for no passphrase):<Enter> Enter same passphrase again:<Enter> Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is: (-:) co:ec:aa:a1:de:34:5c:95:24:1d:25:4a:84:aq:65:ca root@server The key's randomart image is: +--[ RSA 2048]----+ | .******* | | ..B-.-. | | kjak | | . ..+<-, | | . #+#^� | | . | | | | | | | +-----------------+
Then I upload the key
as root: $ ssh-copy-id user@myserver.org Password:
message: Now try logging into the machine, with "ssh 'user@ssh.yourserver.org'", and check in: ~/.ssh/authorized_keys to make sure we haven't added extra keys that you weren't expecting.
Now, when I login, the password is asked *again*.
Where does the id_rsa get used? It is in /root/.ssh/ together with id_rsa.pub when generated by ssh-keygen. I am root when performing the login on the remote server at the moment. Later, I will use a dedicated user.
Any suggestions welcome.
:-) Dreiel
I'm doing this all the time now and the way it's typically set up your procedure should 'just work' with one small change. Don't become root on your local system before generating the public / private key pair. It isn't necessary and is likely the source of your problem. IOW:
as user: ssh-keygen [enter, enter, enter]
ssh-copy-id user@domain.tld [password when prompted] [This appends the public key in ~/'user'/.ssh/authorized_keys on the remote system]
now, to log in: ssh user@domain.tld
That's it. If this doesn't work, the remote host configuration is most likely not 'default,' in which case you already know where to look. But be careful turning off password authentication if physical access to the machine is costly or unpleasant. Better to use 'fail2ban' or something similar to fend off the script kiddies.
hth& regards,
Carl Hi Carl,
I'm sure I tied all you said before, but I deleted all the keys everywhere and reverted to the default in the /etc/ssh/ssh_config file. Now it works on one local server.
Indeed, the access to the server was impossible when I changed the "PasswordAuthentication no" and the "ChallengeResponseAuthentication no". Only access to the server console allowed access again. Your warning "be careful turning off password authentication if physical access to the machine is costly or unpleasant", is well advised!!!
I can not physically get to another server where I have the same problem with the 'PasswordAuthentication no". Is there another method to get to it? It is a virtual server at an ISP :( Is there a way to override these settings when logging in with ssh?
You create the keys on the system you use to access the remote host and then copy the public key to the host you wish to connect to. You can do that via ssh (scp) so you don't need physical access. "Permission denied (publickey)" I don't know why you're seeing that warning about physical access without passwords, as you normally don't use ssh on the same box. ? It is a Virtual Server at a service provider, not the local machine. I have 2 Servers, ons local network and another at the ISP as a Virtual Server. I connect to the local server and the Virtual Server (openSUSE) with a desktop (MacBook), and can also connect to the Virtual Server at the ISP from the local server (openSUSE).
|-|------------normal-----------|=|--------->| DSL |---------|ISP-VS| MacBook Local Sever ^ Virtual Server | | |------------alternative----------------------|
So, what you should be doing is:
1) Generate the keys. 2) Copy the public key to the server. Well, this does not work because it does not do "PasswordAuthentication no" and "ChallengeResponseAuthentication no". Now it brings the error: "Permission denied (publickey)". With ssh-copy-id also needs a password, but because of the settings before, it is not Authenticated/Challenged. All users receive "Permission denied (publickey)"
:-(
3) Once that's working, then worry about disabling the password.
This process has to be done as the user you intend on connecting as, not root.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org