Trying public/private authentication on SSH

F_style · November 26, 2013, 6:46am

This would be actually continuation of discussion started here, but I thought I should put it into the right section.

Now I’m trying ssh and scp but without need of typing the password each time, which means usage of public/private pair-keys (unless there are more ways…).
I already started reading about this by looking into several websites, and I seem to have the general idea of how is done. But doubts arouse.

First, some documents mentioned that, after adding the generated public key to the remote PC, one still needs to add the “identities” in the origin PC, i.e, loading private key to SSH agent with ssh-add. However other sites did not mention it, stating that the public key adding to remote PC was enough.
I’m confused, is it necessary or not?

Second, I read that in order for all of this to work sshd needed Protocol 2 and RSA Authentication enabled. In short,

Protocol 2
RSAAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Checked my /etc/ssh/sshd_config and the first 2 lines are commented (the file itself says it’s strategy is to include many default settings, but left commented, I don’t know why). Do I need to uncomment? Or would it work as it is by using dsa when creating the key?

Thanks in advance.

hendersj · November 26, 2013, 8:12am

On Tue, 26 Nov 2013 05:56:02 +0000, F style wrote:

> Do I need to uncomment? Or would it work as it is by using dsa when
> creating the key?

The commented out parts are default settings, so no, you don’t need to
uncomment it. The only thing I’ve had to adjust in my config in the past
is to remove password authentication (so I only use pubkey authentication
on certain of my systems, especially if it’s a system that is reachable
from the 'net).

Jim

–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

ab · November 26, 2013, 3:48pm

On 11/25/2013 10:56 PM, F style wrote:
>
> First, some documents mentioned that, after adding the generated public
> key to the remote PC, one still needs to add the “identities” in the
> origin PC, i.e, loading private key to SSH agent with ssh-add. However
> other sites did not mention it, stating that the public key adding to
> remote PC was enough.
> I’m confused, is it necessary or not?

It really depends on the command that you use to transfer the files. The
easiest way to do SSH/SCP/SFTP is to use the SSH agent, and since you’re
in an openSUSE forum I assume you’re using openSUSE. The benefit here is
that one you load your private key into the agent you’ll never need to
again which is awesome. The ssh-agent command does this, and win Gnome
and KDE environments it is somehow handled magically so that any
sub-processes (like shells) to the UI automatically inherit the agent’s
capabilities. The “agent” basically looks for SSH authentication requests
for the keys and then handles those for you so that you can just enjoy
file transfers securely and quickly without typing passphrases repeatedly.
Your existing ssh/scp/sftp commands do not change at all when the agent
is involved, and you can run scripts that include these commands, which
may loop over many systems, and have it all work seamlessly as if you were
accessing or copying to/from your own local system. The agent is great.

The biggest hangup for most people with the ssh-agent command is how to
use it initially. On any system (GUI or not) you’d do this, which loads
ssh-agent and has it wrap /bin/bash (a new subshell from the current one
from which these commands were typed) so that ssh-agent can watch for SSH
requests from within this particular instance of /bin/bash (and nowhere else):

Code:

ssh-agent /bin/bash

Now you’ll see you’re at a shell prompt as always, but this is the new
/bin/bash subshell, so next we load the ssh key:

Code:

ssh-add

Tada… unless you are not in an agent you should have seen some note
about adding an identity to your system. From here you can go ahead and
use keys, at least per the client side. If you have not already copied
the public (never the private) key to the remote system, you can also use
the ssh-copy-id command to do just that, and I’d recommend doing this
because ssh-copy-id is better/safer/faster/more-reliable than copying the
file manually and appending it to your authorized_keys file:

Code:

ssh-copy-id targetuser@remote.host.goes.here

With that said, you can tell the existing ssh/scp/sftp commands to use a
specific identity file without using the agent by using the ‘-i’ option
for each of those commands. For example:

Code:

ssh -i ~/.ssh/id_rsa user@remotesystem

Even if the ~/.ssh/id_rsa key was not loaded into your SSH agent your ssh
command would still try to use it.

> Second, I read that in order for all of this to work sshd needed
> Protocol 2 and RSA Authentication enabled. In short,
>
> Code:
> --------------------
> Protocol 2
> RSAAuthentication yes
> AuthorizedKeysFile .ssh/authorized_keys
> --------------------
>
> Checked my /etc/ssh/sshd_config and the first 2 lines are commented (the
> file itself says it’s strategy is to include many default settings, but
> left commented, I don’t know why). Do I need to uncomment? Or would it
> work as it is by using dsa when creating the key?

As Jim stated, and as the sshd_config file itself states:

Code:

The strategy used for options in the default sshd_config shipped with

OpenSSH is to specify options with their default value where

possible, but leave them commented. Uncommented options override the

default value.

Whenever I modify sshd_config defaults I duplicate the line that is
already commented (so that I have a note about how the original looked)
and then modify the new line after uncommenting it. This is not required
of course, but I like it.

–
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

F_style · November 26, 2013, 5:46pm

Then I understand the whole public/private key making stuff is basically to enhance security, by skipping the simple user-password scheme and using a double security one, composed by a file (the key) and a password (passphrase). Am I right?
If I am, then I assume I’d normally both create key and set a passphrase, and use ssh agent precisely to avoid typing passphrase each time. Right?

But if I were to, for example, create an automated cron task which executed at a fixed hour, I read an option for this case was leaving blank the passphrase (even though it’d skip a level of security, but I don’t know…), rendering usage of ssh agent needless.

Have I understood well? What do you say?

ab · November 26, 2013, 6:47pm

On 11/26/2013 09:56 AM, F style wrote:
>
> Then I understand the whole public/private key making stuff is basically
> to enhance security, by skipping the simple user-password scheme and
> using a double security one, composed by a file (the key) and a password
> (passphrase). Am I right?

Yes, you’re basically swapping out “something you know” (password) with
“something you have” (key file), and then protecting the second something
with a new something (passphrase) to prevent/slow access by evil types,
should they steal your key file somehow. Passwords are additionally
vulnerable because they are guessable and predictable by person (you like
dogs? Okay, I’ll try dog-related passwords instead of the cat ones).
Keys are basically not vulnerable to brute force attacks.

Even more, you can limit function based on key, so you can do things like
set “If somebody logs in with this key they can only run this command, and
I’m disabling X-forwarding, etc.” That gets kinda fun.

In case it is not obvious, it’s trivial to login as another user on a
remote system using keys which is one of the big uses for keys. Sure you
can do the same with passwords, but you need to know every target user’s
password. With keys you can just send your key to that user’s
authorized_keys file and you can get in as them directly.

> If I am, then I assume I’d normally both create key and set a
> passphrase, and use ssh agent precisely to avoid typing passphrase each
> time. Right?

Right. Once you enter the passphrase the first time for ssh-agent to read
the private key you no longer need to do so until you restart the agent
(logout/login, reboot, etc.).

> But if I were to, for example, create an automated cron task which
> executed at a fixed hour, I read an option for this case was leaving
> blank the passphrase (even though it’d skip a level of security, but I
> don’t know…), rendering usage of ssh agent needless.

Exactly on both points. You should always protect your private key file
as it is was your actual password (because, in function, it is) but if you
have a passphrase-less private key protect it even more since nothing will
stop somebody else from taking it and using it if they can copy it from
you somehow. Should that happen fixing the problem is easy (delete the
appropriate line from the target system’s user’s authorized_keys file) but
you may want to implement additional security on the server side here too.
I have some scripts where I do this to just keep some SSH tunnels alive
indefinitely. Since they provide access to my system anybody who runs
these scripts (some customers) could get into my system. They’re non-root
users, but still, that’s one more barrier. As a result I setup my server
to ONLY allow those keys to be used to run a shell script I created that
just prints the date every minute or so. If they try anything else, it
still just runs that script. If they try to enable other functions those
fail silently. If that key is ever compromised the attacker can connect
to my system as that non-root user and just see the time presented once
per minute forever. That’s fine with me.

> Have I understood well? What do you say?

Yes.

–
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

F_style · November 26, 2013, 8:01pm

Oh…

So in the end, what would be your advise for automated cron tasks/scripts? For now I’m just aiming to make backups periodically.

F_style · November 27, 2013, 5:35am

Now that I thought about it, I came with more issues…

First, regarding ssh-copy-id, if I don’t use -i option at all, it will add to remote PC the one or more keys stored in ssh-agent, and if ssh-agent has no stored keys, it will just add the default ~/.ssh/id_rsa.pub. Am I right?

Second, how are keys working at all?
Let’s imagine I create default ~/.ssh/id_rsa.pub in local PC with my local user (let’s call it user1). It’s fingerprint, as I have seen, will end with this user name. Then I add this key with ssh-copy-id to remote PC, where user2 is currently logged in. From what I read, I can only guess I’ve created a key that “links” just both user1 and user2. So if I want to log in remote PC using the key (i.e., without typing password), I must be as user1 on local PC and log in as user2 on remote PC.
Am I right?
But then what are both public and private key files for on local PC? What effect does it make by deleting or moving them to another directory?

I know ssh-keygen generates keys with different fingerprints (.pub file’s content) each time, even if they’re named the same way. Let’s say I first made default ~/.ssh/id_rsa.pub, then I made another one ~/Documents/id_rsa.pub (if I used same save directory it’d be indeed overwritten). Different fingerprints, though they end with the same user name they were created from. What happens if I try to add both to remote PC? How would I log in?

Guess I’m indeed very confused…

malcolmlewis · November 27, 2013, 5:51am

On Wed 27 Nov 2013 04:36:01 AM CST, F style wrote:

Now that I thought about it, I came with more issues…

First, regarding ssh-copy-id, if I don’t use -i option at all, it will
add to remote PC the one or more keys stored in ssh-agent, and if
ssh-agent has no stored keys, it will just add the default
~/.ssh/id_rsa.pub. Am I right?

Second, how are keys working at all?
Let’s imagine I create default ~/.ssh/id_rsa.pub in local PC with my
local user (let’s call it user1). It’s fingerprint, as I have seen, will
end with this user name. Then I add this key with ssh-copy-id to remote
PC, where user2 is currently logged in. From what I read, I can only
guess I’ve created a key that “links” just both user1 and user2. So if I
want to log in remote PC using the key (i.e., without typing password),
I must be as user1 on local PC and log in as user2 on remote PC.
Am I right?
But then what are both public and private key files for on local PC?
What effect does it make by deleting or moving them to another
directory?

I know ssh-keygen generates keys with different fingerprints (.pub
file’s content) each time, even if they’re named the same way. Let’s say
I first made default ~/.ssh/id_rsa.pub, then I made another one
~/Documents/id_rsa.pub (if I used same save directory it’d be indeed
overwritten). Different fingerprints, though they end with the same user
name they were created from. What happens if I try to add both to remote
PC? How would I log in?

Guess I’m indeed very confused…

Hi
You think too much… try it, what happens…?

All I do on my local network is create a key, ssh onto the remote
system and add (via copy/paste) to ~/.ssh/authorized_keys file for
that user, if you had another user on the remote machine, copy the same
key into that users ~/.ssh/authorized keys file.

So from the local machine I could then open a terminal;


ssh user1@remotesystem and be in ~/user1

open another local machine terminal and;


ssh user2@remotesystem and be in ~/user2

I change my sshd config files to use authorized_keys2 since that’s what
no-machine looks for.

–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
SLED 11 SP3 (x86_64) GNOME 2.28.0 Kernel 3.0.101-0.8-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

nrickert · November 27, 2013, 6:27am

Yes, that’s about right.

When I was doing that (while administering a department network of computers), I used host-based authentication. In that case the host key, rather than a personal key, is used. And you would login at the remote site as the same user you are.

It’s probably explained in the same documentation you have been reading.

ab · November 27, 2013, 1:06pm

On 11/26/2013 09:36 PM, F style wrote:
>
> First, regarding ssh-copy-id, if I don’t use -i option at all, it will
> add to remote PC the one or more keys stored in ssh-agent, and if
> ssh-agent has no stored keys, it will just add the default
> ~/.ssh/id_rsa.pub. Am I right?

Mostly. I am not sure (because it has never worked for me) that
ssh-copy-id will grab any keys that are not loaded into the agent.
Perhaps newer versions do, but older versions did not. I only have one
key, so it has only ever copied one key for me. I know that with openSUSE
13 (and SUSE Linux Enterprise Server 11 SP3) the SSH versions have been
moved up to 6.1 which has a smarter ssh-copy-id function so perhaps that’s
an option now.

> Second, how are keys working at all?
> Let’s imagine I create default ~/.ssh/id_rsa.pub in local PC with my
> local user (let’s call it user1). It’s fingerprint, as I have seen, will
> end with this user name. Then I add this key with ssh-copy-id to remote
> PC, where user2 is currently logged in. From what I read, I can only
> guess I’ve created a key that “links” just both user1 and user2. So if I
> want to log in remote PC using the key (i.e., without typing password),
> I must be as user1 on local PC and log in as user2 on remote PC.
> Am I right?
> But then what are both public and private key files for on local PC?
> What effect does it make by deleting or moving them to another
> directory?

For the purposes of making this clear think about passwords. In a typical
*nix system you an /etc/shadow (or maybe /etc/passwd if you’re a little
odd) file that contains something that is linked to your password. That
“something” is a hash, and is the result of a one-way function like crypt,
blowfish, md5, sha-something, etc. This matters because when you login
with a password you do not send the hashed version of your password, but
instead you type the real password and then the system takes it (and
probably a salt that the system has stored for your user) and generates a
hash using the same function, and then compares that hash with the stored
hash for your user (the user you claimed to be when authenticating). If
it matches, you’re in. If not, you’re not. If you have that hash stored
in other files on the server, it does not matter since /etc/shadow is the
file checked. If you have the same password for other users it does not
matter since you specified a specific username for logging in.

When you use SSH keys the same happens, except that instead of each user
controlling their own password on the server using the ‘passwd’ command
they control access to their account by modifying their own
~/.ssh/authorized_keys file (or whatever file sshd is configured to use).
They do this by copying the public key of anybody else into this file.
When a client attempts to authenticate that client sends the username (of
course) and then THAT USER’s, and no other’s, authorized_keys file is
checked. If the private key used on the client side matches the public
key on the server side, they’re in. If not, they’re not. The username
bit as the third parameter in the public key file does not, as far as I
can tell, matter at all and is probably merely so the server side user can
easily see who has access.

> I know ssh-keygen generates keys with different fingerprints (.pub
> file’s content) each time, even if they’re named the same way. Let’s say
> I first made default ~/.ssh/id_rsa.pub, then I made another one
> ~/Documents/id_rsa.pub (if I used same save directory it’d be indeed
> overwritten). Different fingerprints, though they end with the same user
> name they were created from. What happens if I try to add both to remote
> PC? How would I log in?

See above and hopefully that explains everything.

–
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

F_style · November 28, 2013, 5:50am

OK, in order to not be scolded for not doing practice, I did them.

My local “client” PC is my physical openSUSE rig, which specs are on my signature. My remote “server” is a virtualized CentOS through VirtualBox.

Login from remote server to local client tests
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.

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 works.

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 cancelled.
With passphrase protected keys happened the same as explained below.

Turned off sshd.
Tests with passphrase protected keys:
1a–If both key files are in ~/.ssh, first attempt to log in spawns a 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.

Tests with passphrase-less keys:
2a–With both keys in ~/.ssh, I get “Agent admitted failure to sign 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 more.
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 anymore.

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.

Doubts

What’s the point of being able to create keys in another location if you cannot use them unless they were created in ~/.ssh?
What’s the number I got in remote server when creating keys in another location?
Why am I heck of messed up on my local client tests in general?
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…
See why I was always unconfident?

A big thank you beforehand if you are able to help me.

ab · November 28, 2013, 7:40am

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
> VirtualBox.
>
> 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
> works.

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
> cancelled.
> 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
on reboot?

> Tests_with_passphrase_protected_keys:
> 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.
>
> Tests_with_passphrase-less_keys:
> 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
> more.
> 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
> anymore.
>
> 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.
>
>
> Doubts

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
system:
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
for authentication
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
using passwords.

–
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

nrickert · November 28, 2013, 2:29pm

I’m just commenting on this. You already have pretty good answers to most of your questions.

You appear to be using Gnome. The Gnome implementation of ssh-agent preloads the public keys from “.ssh”, and prompts for the private keys on first use.

I use KDE, with the ssh-agent that comes with openssh. So I have to explicitly load keys, using the “ssh-add” command. The keys can be anywhere. They don’t have to be in “.ssh”. I actually have them in “.ssh/keys”.

You can use “ssh-add” with Gnome, too. So you are not confined to putting the keys in “.ssh”.

I guess I’m a bit of a control freak. I put my keys in “.ssh/keys” because I don’t want Gnome to automatically preload them. I want to explicitly load the keys that I intend using.

F_style · November 28, 2013, 4:27pm

@ab:
I thought I was the most explicit possible along my post…

Anyway, as subtitles suggest, I first made tests from remote to local (i.e., from CentOS to openSUSE), later I made tests from openSUSE to CentOS. Therefore, all that comes after “Login from local client to remote server tests” subtitle was done on openSUSE box -the client side-, and I use “systemctl start/stop sshd.service” to turn on/off sshd. “status” for checking it. And I never touch “authorized_keys” file neither on server nor client, unless deleting keys and trying again. “Both keys” refer to both files of the created key-pair.

Maybe now you could read again that part of my post with these things clear, since I’m still doubtful… As you saw, on the CentOS box there are seemingly no problems, I’d just need to test ssh-agent. Problems are on the openSUSE box.

@nickert:
Not being able to use keys created in another location also happens in the CentOS box, which is text-mode, no GNOME, no KDE. Are you saying that it will only work by actually adding them to ssh-agent?
And, do you have by chance an idea of what’s the number in question 2?

nrickert · November 28, 2013, 5:14pm

I’m not sure about “only”, but that’s the way that I know to do it.

No, I have not come across that.

F_style · November 29, 2013, 2:36am

@ab:
I clarified some doubts you had. Any clue about why am I messed up with the keys on the openSUSE box?

nrickert · November 29, 2013, 4:59am

The box you login to is the server. So in this case, the local site where you run “sshd” is the server, and the remote site is the client for your ssh transactions.

On the server (the local site), only the “authorized_keys” files matter. So moving public and private keys around has no effect.

It’s not clear where the keys are. You added them to “authorized_keys” on the local site. So you need the public and private key files on the remote site. And you may need to add them to “ssh-agent” there (or perhaps to “seahorse” which is the Gnome tool that emulates “ssh-agent”).

However, if I still use ~/.ssh for the keys but change the key name, it works.

Try, on the site where you have the keys (I think that’s the remote site)


ssh-add "/path/to/private-key/file"

where, of course, you put the actual path there rather that the text that I used. You should be prompted for any passphrase, and it should start working.

That’s because “seahorse” (or whatever the Gnome software is called) has remembered your private key from the first use. Until you logout and log back in, it will continue to remember. So moving the key files does not matter, because the private key is already remembered.

That’s the was that seahorse works. It takes whatever is in “/.ssh” as the list of available keys.

With passphrase protected keys happened the same as explained below.

I hope that helps to explain things.

F_style · November 29, 2013, 6:35am

Heck, I just realized I messed up with my tests report… and I cannot edit the post anymore… I’ll try fixing some things.

I'll just call openSUSE box my physical rig (the host), and CentOS box the virtualized one (the guest).

Whenever I mention "turning on/off sshd", I mean with systemctl command and **always** on openSUSE box. I never touch sshd on remote CentOS box probably because it's already enabled there. Also I never touch authorized_keys file on neither of both sides, just public or private key files depending on test. So I started off by turning on sshd in order to CentOS box being able to communicate with openSUSE box.

**Login from CentOS box to openSUSE box tests, generating keys on CentOS box**
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 prompted to log in with normal username and password.

Then tried generating a key pair with ssh-keygen but in a different location (~/keys, for example). Then added them to openSUSE box with "ssh-copy-id -i keys/key.pub suseuser@ip_adress". This time I got a number, 16, before being asked for openSUSE user's password. The keys were indeed added to openSUSE's authorized_keys, but when trying to login from CentOS key was totally ignored, as though cancelled, so I 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 works.

**
Login from openSUSE box to CentOS box tests, generating keys on openSUSE box**
*First with sshd still turned on in openSUSE box*
With passphrase-less keys behavior was similar as previous test, 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 cancelled.
With passphrase protected keys happened what is explained below.

*Now turned off sshd in openSUSE box*
Tests with passphrase protected keys:
1a--If both key files are in ~/.ssh, first attempt to log in spawns a 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 file 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.

Tests with passphrase-less keys:
2a--With both keys in ~/.ssh, I get "Agent admitted failure to sign 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 any more.
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 is not requested anymore.

When trying to generate the keys in another location I got same result as previous test, except that I got no number before asked for password.

@ab or nrickert:
You already have explained some things (the seahorse remembering stuff), I just hope it doesn’t change now that I’ve finally clarified things…

When generating keys in another location in the CentOS test, you suggest using ssh-add, but on openSUSE or CentOS box?
Could you now be able to tell why am I messed up with the rest of openSUSE box tests, now that I rectified?

Again, thank you.

nrickert · November 29, 2013, 3:36pm

That’s what I’ll try to do in this reply.

This really has to do with the way that “seahorse” works. I’m a KDE user, so I have only limited experience. Well, truth to tell, one of the reasons that I moved from Gnome to KDE (back in 2009), was that I did not like “seahorse”, and the way that it was making unwarranted assumptions about files in my “.ssh” directory.

My way of using “ssh” is this:

I always use “ssh-add” to add a key to “ssh-agent” if I want to be able to use that key. It does not matter where the key is located, as long as I provide the path in the “ssh-add” command. And that lasts till the end of my login session, or until the “ssh-agent” process is terminated. I find this more consistent and predictable than what “seahorse” tries to do.

I have two public/private key pairs. Let’s call them “key1” and “key2”, and lets assume that they are in “.ssh”.

Without “seahorse” – in KDE, for example:

I decide which key I plan to use, and I load it into “ssh-agent” with the “ssh-add” command. If I later use “ssh-add -l”, that will tell me which keys are loaded. If I use “ssh-add -l” before adding any keys, it tells me “The agent has no identities.”

With “seahorse” (as in Gnome):

“seahorse” claims to know about both keys. If I run “ssh-add -l” before providing any passwords, then it tells me that both of my keys are loaded. When I want to login to a remote site, “seahorse” chooses which key to use, and prompts me for a passphrase. If I run “ssh-add -l” after providing a passphrase, the output is the same as it was before providing a passphrase. So I cannot use “ssh-add -l” to inquire as to which keys are loaded and available.

Roughly speaking, “seahorse” gives me the old mushroom treatment. It keeps me in the dark and feeds me horse manure.

And I think that is what is confusing you. You are finding it a bit easier with “seahorse”, but also a lot more confusing.

My solution, back when I still used Gnome, was to move the keys to “.ssh/keys”, so that “seahorse” would not know about them. I could then still use “ssh-add” to add a key, and “ssh-add -l” to list which keys were already loaded.

ab · November 29, 2013, 4:10pm

Since nrickert took the hard question, I’ll take the easy one:

> 1. When generating keys in another location in the CentOS test, you
> suggest using ssh-add, but on openSUSE or CentOS box?

ssh-add is used to add a client-side private key to the currently-loaded
ssh-agent. As this is a cliens-die utility it ONLY matters on the client
side. In your case, that’d be CentOS. Running ssh-add on the server side
should not have any impact on the success or failure of any SSH connection
since this is a client-side tool only, just like the ‘ssh’ command.

My guess at why things may not always work with your keys in another
location is “Permissions”. I do not have access to a CentOS box right now
but you can probably find answers to your question using the ‘-vvv’ option
I mentioned previously to see what the ssh client is doing when connecting.

Also, if you want to do test without any of the GUI (Gnome/KDE) key agents
doing magic that is harder to track down (because it is automatic and
cross-application unlike pure command-line stuff) try switching to a TTY
to do your tests. Ctrl+Alt+F2, for example, and then login as your user.
This should be completely outside any X/Gnome/KDE/etc. environment and so
your tests will probably make more sense. Again, this is on the client
side since the key agent is a client-side only utility.

–
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…