A great website that has a lot of different tutorials for Linux is: http://www.cyberciti.biz/. Whenever I forget the specifics of a task under Linux, I check there first. They have tutorials on most everything related to Linux.

So I searched that site for public key authentication for ssh and found this link: http://www.cyberciti.biz/tips/ssh-pu...on-how-to.html. It is relatively straightforward and lists each command, step by step.

I have consulted information at that site previously, mralk3. I don't think I've tried to use that particular tutorial, but I have, in the past, consulted and probably used others. The link you offer is pretty straightforward, though there are some points of confusion: for example, he starts off talking about directions applicable to "FreeBSD / Linux / UNIX." But thereafter, he talks only about "FreeBSD workstation" or just "workstation." If someone is not familiar with similarities and differences between the various *nixes, this could cause confusion. In my opinion he should have written something like "these directions will likely apply just as adequately to systems running FreeBSD / Linux / UNIX. But since I am using FreeBSD as I write this, my description will center on FreeBSD."

That said, here's something in that tutorial that I do not understand. He states Does this mean that, with public key authentication, the password prompt one gets when ssh'ing into a remote system actually comes from the machine from which the ssh session is initiated, and not from the remote system? Obviously, I may still have a rather poor comprehension of how this authentication scheme works.

It means you are creating the key pair used to authenticate your user on the ssh server.

Any service that authenticates a user, does so on the server side. SSH is not a unique authentication scheme in that regard.

If you are still confused about ssh read this link that I found in google:
https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys

However, I wouldn't recommend that you continue to run commands on your machine when you have no idea of what they do. You really should try to use the man pages before asking what a command does. In fact, when I was learning *NIX some 12 years ago, all I ever did was search and view the man pages on my system.

Thanks for the further input, mralk3. I created my keypair by running ssh-keygen -t rsa--just like the author of that post instructs to do a few paragraphs above the excerpt I asked about. Are you saying that running the commands ssh-agent $BASH and ssh-add provides an alternate way of creating a keypair? If so, this is the first I hear about that. Though I do not understand the man pages for ssh-agent and ssh-add very well, I cannot derive from them that these commands do any creating of keypairs.
Thanks for the link. I've been using ssh for quite a few years (over 10, definitely), so I feel like I have a decent basic grasp on how it works--at least until the public key authentication wrinkle gets thrown in.

That page has a pretty decent explanation of public key authentication--simple and clear. And, on that note, I gather from the clearer explanation given at this site that it is, in fact, on the local machine (and not on the ssh server) that your passphrase is entered: it is asked for so that your private key (resident on your local machine) can be used to decrypt the message sent from the ssh server. That is what I'm gathering from this paragraph: Am I misinterpreting something here?
It is a misrepresentation to say I have no idea of what commands that I run are doing. Some commands I have a pretty decent layman's understanding of (working with computers is pretty far from my profession). I have a more vague understanding of other commands. But I don't run any commands on my computers that I don't feel I have at least some degree of understanding about. And I read man pages all the time and have been reading them for years. Some I've come to understand fairly well, while others remain pretty inscrutable (they presuppose a level of knowledge that I do not yet have).

You are welcome.

Ssh-agent provides the ability to store multiple identities. It also stores the password for your key pair (if you created one during the generation of the key pair using ssh-keygen). Further still, ssh-agent forwards the connection while it supplies the password of your key pair to the remote host. The $BASH variable is just telling ssh-agent that your preferred shell is /bin/bash. You can see what $BASH stands for on your system by executing "echo $BASH" in a terminal.

Ssh-add just adds the key pair you generated to ssh-agent.

No problem. The first link I sent (www.cyberciti.biz) assume you will follow along with the man pages, as do most of the articles on that site.

The authentication takes places on the remote system when the ssh tunnel is established. The ssh service on the remote system listens for the right authentication token, and if provided by the client, drops the user to a shell. Your local system is the client. The machine you are trying to connect to is the remote system.

I apologize if I seemed a bit abrupt in my previous post. I sometimes get frustrated with the lack of initiative by users of these forums. I realize now, I was quick to judge.

Here is a resource of free ebooks that cover the topic of Linux. They should help you fill the gaps you may identify regarding your knowledge of Linux.

http://it-ebooks.info/search/?q=Linux&type=title

Thanks for the additional link, mralk3. I actually have at least one of those books. But it's good to know that others like it are available free of charge as well.

If I may ask a further bit of forbearance in clarifying my understanding of public key authentication, the following. I think we may be talking past each other to some extent when touching on what is happening with the scheme laid out at the cyberciti link that I first asked about. There seems to me to be a bit of unclarity in what, exactly, "authenticating" on the ssh server means in the ssh-without-public-key-authentication, as opposed to the ssh-with-public-key-authentication, schemes.

I should point out at the outset that I did not ask about authenticating, but rather about the passphrase, and from which machine the prompt for the passphrase originates. That was confusing for me because, in the scenario without public key authentication, I'm pretty certain the passphrase prompt originates from the ssh server. In the public key authentication scheme, however, it seems to me that the passphrase prompt originates from the local machine. Both the cyberciti link and the second link you provided seem to describe running ssh-agent $BASH and ssh-add on the local machine, not on the ssh server, do they not? And, as you've explained it, what those commands do is save the passphrase--on the local machine, I presume--so that, when you go to log in to an ssh system with public key authentication enabled, you do not need to enter any passphrase; is that correct? The actual authentication--which is an additional step that follows on entry of the passphrase--is accomplished by the two machines successfully exchanging certain codes. That authentication is something that occurs subsequent to entry of the passphrase--whether that entry be manual or, in the case of those who have used the ssh-agent $BASH and ssh-add commands, automated. This is what I'm getting out of my reading so far; if it's wrong, I would very much appreciate being corrected.

This passphrase aspect has been one of the most confusing elements of public key authentication for me. And the further understanding of it that I've arrived at--if my understanding is correct--only complicates matters. Because what it means is that there are really two types of passwordless public key authentication possible: one is where you do not use any passphrase to protect your key, simply hitting the "enter" key when being asked, upon creation of the key pair whether you'd like to enter a passphrase, and a second where you do enter a passphrase, but then take the subsequent step of having the computer remember the passphrase for you (by running the commands ssh-agent $BASH and ssh-add). That is in addition to my inital confusion as to why, after I'd created by key pair, I was still being prompted for a passphrase when I would go to log into my ssh server: the passphrase prompt was almost indistinguishable from the standard ssh passphrase prompt I'd gotten before implementing public key authentication. And I've clearly had difficulty in comprehending the fact that the passphrase prompt in the public key authentication scheme actually originates from the local machine, and not from the ssh server. That is, assuming I'm making a correct deduction on that point.

Apologies if I seem a bit dense. The client/server model is fairly transparent for me, but further modifications on that scenario cause me confusion.

Unfortunately, there are a lot of reasons why you would be asked a password, even when it seems like you should be able to login.

To login successfully a few things must be true.

• The server must have a line in its authorized_keys file that goes something like this:

• The client (bob) must have a public key file that matches that key in the authorized key. In the example above, it would exist as ~/.ssh/id_rsa.pub

If either of those are missing or corrupt or wrong, the public key auth fails and you are asked for a password as the next permitted authentication method. If it isn't permitted, you would get a permission denied. Note this next authentication method has nothing to do with public key. It is a case of "public key failed, let's now try the other method, a username and password"

If the private key on client is encrypted and no agent is serving to demonstrate that you "have the key", the connection requires you unlock the key. This requires a password. Otherwise how does it know you have the right private key?
You should be able to tell when a connection is using password as the authentication method and the password is for unlocking the key. It should tell you, you need to enter the password for key ~/.ssh/id_rsa or something to that extent. A normal connection will simply ask to login without referencing a private key.

In my case:
To unlock private key without ssh-agent
With no public key (using password authentication)
Without knowing the intimate details, I am sure the first one is done local side. I would assume the latter would take the hash of the password server side and compare it to the existing hash to see if they are the same.

Thanks for your input, Seyfir. Something very much like the first case is what I'm seeing when I log into my ssh server, now that I'm coming to grips with public key authentication. What I'm saying is that, for the somewhat-educated layman, the two prompts, when not seen side by side, can be easily confused. I think that, in combination with the fact that I was unsure as to from whence the passphrase prompt was originating (I might have different passphrases on on the two machines), is what tripped me up when I initially tried to implement this. In any case, it seems to me you are confirming my supposition that the passphrase prompt originates form the local machine, correct? And I likewise deduce that the commands ssh-agent $BASH and ssh-add, if one wants to implement the second of the two passwordless public key authentication schemes I described above, are to be run on the local machine (not on the ssh server)?

The three different scenarios of SSH user authentication are getting blurred.

1. User authenticates with basic password authentication. This is the least secure configuration of SSH, but it is the default.

• No key pair required
• User enters the username on the remote system for their account
• User enters the password for the user account on the remote system

2. User authenticates with public key authentication of which the key pair is not secured with a password. This is more secure than option 1, but less secure than option 3.

• Key pair required
• User enters the user name of the remote system for their account
• User does not enter any password and is logged in without a request to enter a password

3. User authenticates with public key authentication of which their private key pair is secured with a password. This is the most secure, since a password is also required to decrypt the key pair. It is recommended that a long and complicated password be used to secure this key pair. For example, my key pair is secured with a 36 character password.

• key pair is required
• User enters the user name of the remote system for their account
• User enters the password required to decrypt their public key and then the keys are compared
• This is the scenario where ssh-agent comes in handy, so you do not need to type in your key pair passphrase each time

The step of adding ssh-agent is not necessary if you only log into one machine and are not pressed on time to connect to multiple machines. The point of ssh-agent is to save time for people who log in to many different remote ssh systems. I used ssh-agent when I was a sysadmin and managed hundreds of remote servers day to day. Imagine having to type a 30-40 character based password for 300 different servers over and over. Major time sink.

An example of where ssh-agent is extremely helpful (not likely a scenario you will run into, but off the top of my head.) is if you have written a shell script that needs to log out to remote systems via ssh and execute commands. With ssh-agent it is the possible to write a shell script that loops through the hosts, logs out to each host (in my case, a vpn database of remote servers running ssh), and executes commands or shell scripts automatically.

36 characters? Zounds! Mine is only about 10 characters--maybe I should create a new, longer one?

So, let's say I wanted to implement scenario 3 such as you've described it--whether using the current, or a new, longer password, but in such a way that I do not have to enter the password manually each time. I run the commands ssh-agent $BASH and ssh-add in order to accomplish this, as I understand it. Do I run those commands on my local machine--the one I am ssh'ing from; or do I run them on the ssh server, once I've log into it manually?

You run ssh-agent and ssh-add on your local machine. ssh-agent stores the credentials for your local user account on your local machine.

Thanks for clarifying that, mralk3. I think I'll go ahead and mark this thread "SOLVED," since it seems my queries have all be satisfactorily addressed.

Ran into a bit of trouble recently with my new firewall rules. That's because I have a personal wiki, running on the machine that also acts as a local/remote ssh host, that also serves up pages of wiki material on the LAN. So it became inaccessible to other machines on my LAN because, with the new firewall rules, I'd closed the port on which it runs. So I had to edit the rules and explicitly re-open that port. I did that by adding the following line:
Now access to the wiki is restored anew.

So the full set of rules now looks like: Looking over these rules now, about a year after I initially worked on this, I'm just wondering whether the line -A OUTPUT -j ACCEPT might not need to be in a different place? Like maybe more segregated from the -A INPUT lines, since it's a different chain.

I'll just add to this thread an interesting proposal for blocking specific ip's in iptables. So, if particular ip's show up repeatedly in the log, they could be saved to the blocked-ips.txt file and then the script below could be run. Of course you'd want to restart iptables before running this script to clear out any previous block entries. I found this at https://superuser.com/questions/1091...lock-ip-in-ssh