On 11/27/2013 09:56 PM, F style wrote:
> OK, in order to not be scolded for not doing practice, I did them.
I appreciate attempting to learn via tests. You’ll learn a lot that way,
as you probably know.
> My local “client” PC is my physical openSUSE rig, which specs are on my
> signature. My remote “server” is a virtualized CentOS through
> Login from remote server to local client tests
I understand what you are saying, but connections are never initiated from
a server to the client.
> First turned on sshd first obviously. In general tests were successful.
> With passphrase protected keys I was asked for passphrase each time I
> logged in, while with passphrase-less I logged in freely. I could see
> that moving public key file from ~/.ssh or renaming it had no effect, I
> still could login with the key. But moving/renaming private key file
> cancelled the key indeed and I was prompt to login with normal username
> and password.
All of the tests of moving away the public key from the client side are
working correctly. The Public Key is akin to the server-side password
hash, so no matter what you do to it on the client side it will not affect
authentication. The only downside to moving the public key on the client
is that it makes copying that key to a server hard/impossible.
Moving/renaming the private key on the client side is like forgetting the
password that you would use to connect to the server. If you do not know
the password you cannot get in.
> Then tried generating a key pair with ssh-keygen but in a different
> location (~/keys, for example). Then added them to local client with
> “ssh-copy-id -i keys/key.pub localuser@ip_adress”. This time I got a
> number, 16, before being asked for local user’s password. The keys were
> indeed added to local’s authorized_keys, but when trying to login from
> remote server key was totally ignored, as though cancelled, logged with
> username and password. Even when moving both files to ~/.ssh still
> didn’t work.
> However, if I still use ~/.ssh for the keys but change the key name, it
This make sense to me as you described it, which is without using an
ssh-agent or SSH command that referred to a key. If you did not setup an
SSH agent then the only way for the SSH client to know which key to send
is to look for one where it knows they should be ~/.ssh but I do not know
that it even does that by default. Anyway, unless you specify the private
key when calling ssh/scp/sftp, or unless you use the agent, the public key
attempt will never work. If you really want to see this process play out
add ‘-vvv’ to your SSH command and see what happens before the password
prompt comes up.
> Login from local client to remote server tests
> First with sshd still turned on.
> With passphrase-less keys behavior was similar to remote’s one, except
> that if I moved private key file right after a successful login was
> done, I was still able to login! And no matter if I moved back and forth
> private key file, it was not until I moved public key file that key was
> With passphrase protected keys happened the same as explained below.
> Turned off sshd.
On which box? If sshd is stopped on a server side then SSH will not work.
sshd on the client side does not matter at all since ‘ssh’ is what does
all of the work on the client side. How did you stop sshd, and how are
you checking to ensure is it stopped and not just disabled from starting
> 1a–If both key files are in ~/.ssh, first attempt to log in spawns a
When you write "both keys are in ~/.ssh do you mean on the client or
server side or both, and do you mean that the public key is just in
id_rsa.pub or in authorized_keys or both?
The authorized_keys file only matters on the server side of an SSH connection.
> graphical prompt out of console (as if it was GNOME’s) requesting key’s
> passphrase. Later attempts passphrase is no longer requested at all.
> 1b–If I move public key file to another location, I get text prompt in
> console this time requesting passphrase each time I log in. Returning it
> back leads to 1a.
> 1c–If I move private key file to another location, passphrase is not
> requested at all. Neither if I return it to ~/.ssh, unless I move public
> key as well, leading to 1d.
> 1d–If I move both keys to another location, I get to log in with normal
> username and password, as expected. Returning them back leads to 1a.
> 2a–With both keys in ~/.ssh, I get "Agent admitted failure to sign
Again, in what forms and on which systems? If sshd is still stopped on
the server side nothing else matters.
> using the key" and forced to log in with normal username and password,
> all of this in each login attempt.
> 2b–Moving public key to another location, passphrase is not requested
> at all, but by putting it back passphrase neither is requested not any
> 2c–Moving private key to another location has no effect at all, nor
> putting it back. Exact same results as 2a.
> 2d–Moving both keys to another location, prompted to use normal
> username and password, but when both put back passphrase not requested
> When trying to generate the keys in another location I got same result
> as above, except that I got no number before asked for password.
This is a common language thing; you mean ‘Questions’.
> 1. What’s the point of being able to create keys in another location if
> you cannot use them unless they were created in ~/.ssh?
There is no requirement on creation location of SSH keys as location is
just a way for mere mortals (humans like us) to think about how to access
blocks of data on some kind of storage medium.
> 2. What’s the number I got in remote server when creating keys in
> another location?
No idea. I have never seen that before, and I use SSH all day, every day.
> 3. Why am I heck of messed up on my local client tests in general?
Wildly guessing, confusion with the SSH agent and misunderstanding of
“client” vs. “server”, but that’s just a guess.
> 4. During tests, there was message on remote server saying “INIT:
> version 2.86 reloading”, don’t know what it means or if it has something
> to do…
‘init’ reloading almost certainly has nothing to do with SSH. ‘init’ is
the parent process of all processes on a *nix system.
> 5. See why I was always unconfident?
Yes, so test again with a few changes.
Passphrase-less vs. passphrase-protected does not matter other than in
how the client utility (ssh/scp/sftp) gets to the private key. Once it
has access to the private key nothing else matters since the passphrase
has nothing to do with the actual authentication process. As a result, do
not worry about testing with/without it at this point until you understand
the SSH basics really well.
Do not confuse the client and the server. Here are the only parts
that matter for authentication using RSA keys in a normal, simple, basic
a. ~/.ssh/id_rsa #private key, on the client side ONLY; important
b. ~/.ssh/id_rsa.pub #public key, on the client side, but not important
c. ~/.ssh/authorized_keys #holds one to many public keys and related
data, server side only, important
That’s it. If the private key is used by the SSH client, and if the
public key is in the server’s user’s authorized_keys file, and if the
permissions are set correctly on both sides (the SSH client and/or server
checks to ensure the keys cannot be compromised), and assuming the server
is configured to allow public keys in the correct (~/.ssh/authorized_keys)
file, the rest should just work. Some things can, and do, go wrong here:
- Permissions on public or private key files, or the ~/.ssh directory
itself. This is one of the reasons ssh-copy-id is such a great tool, that
and it prevents overwriting old keys which can easily happen when using
scp instead of ssh-copy-id.
- Server disallowing use of public key authentication.
- Too many authentication failures before the public keys are tried. If
the client tries challenges, then gssapi and the next option is pubkey,
and the server only allows two failures, you’ll never get in. I once had
to relax my box because a friend’s still Ubuntu box had to try every
method under the sun before it reached public key authentication, and so
he could never get in. This can affect other things too, since after two
failures (when the limit is two) anything else is also prohibited, like
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…