LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 06-20-2015, 07:38 PM   #16
mralk3
Senior Member
 
Registered: May 2015
Distribution: Slackware, OpenBSD
Posts: 1,559

Rep: Reputation: 882Reputation: 882Reputation: 882Reputation: 882Reputation: 882Reputation: 882Reputation: 882

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.
 
Old 06-22-2015, 01:04 PM   #17
jamtat
Member
 
Registered: Oct 2004
Distribution: Debian/Ubuntu, Arch, Gentoo, Void
Posts: 132

Original Poster
Rep: Reputation: 24
Quote:
Originally Posted by mralk3 View Post
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
Quote:
Use of ssh-agent to avoid continues pass-phrase typing
At freebsd workstation type:
Code:
ssh-agent $BASH
ssh-add
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.
 
Old 06-22-2015, 01:31 PM   #18
mralk3
Senior Member
 
Registered: May 2015
Distribution: Slackware, OpenBSD
Posts: 1,559

Rep: Reputation: 882Reputation: 882Reputation: 882Reputation: 882Reputation: 882Reputation: 882Reputation: 882
Quote:
Originally Posted by jamtat View Post
That said, here's something in that tutorial that I do not understand. He states
Quote:
Use of ssh-agent to avoid continues pass-phrase typing
At freebsd workstation type:
Code:
ssh-agent $BASH
ssh-add
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.
 
Old 06-22-2015, 09:00 PM   #19
jamtat
Member
 
Registered: Oct 2004
Distribution: Debian/Ubuntu, Arch, Gentoo, Void
Posts: 132

Original Poster
Rep: Reputation: 24
Quote:
Originally Posted by mralk3 View Post
It means you are creating the key pair used to authenticate your user on the ssh server.
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.
Quote:
Originally Posted by mralk3 View Post
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/communi...ients-and-keys
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:
Quote:
When a client connects to the host, wishing to use SSH key authentication, it will inform the server of this intent and will tell the server which public key to use. The server then check its authorized_keys file for the public key, generate a random string and encrypts it using the public key. This encrypted message can only be decrypted with the associated private key. The server will send this encrypted message to the client to test whether they actually have the associated private key.
Am I misinterpreting something here?
Quote:
Originally Posted by mralk3 View Post
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.
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).

Last edited by jamtat; 06-22-2015 at 09:02 PM.
 
Old 06-22-2015, 10:22 PM   #20
mralk3
Senior Member
 
Registered: May 2015
Distribution: Slackware, OpenBSD
Posts: 1,559

Rep: Reputation: 882Reputation: 882Reputation: 882Reputation: 882Reputation: 882Reputation: 882Reputation: 882
Quote:
Originally Posted by jamtat View Post
Thanks for the further input, mralk3.
You are welcome.

Quote:
Are you saying that running the commands ssh-agent $BASH and ssh-add provides an alternate way of creating a keypair?
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.

Quote:
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.
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.

Quote:
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:

[..snip..]

Am I misinterpreting something here?
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.

Quote:
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).
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
 
Old 06-23-2015, 11:49 AM   #21
jamtat
Member
 
Registered: Oct 2004
Distribution: Debian/Ubuntu, Arch, Gentoo, Void
Posts: 132

Original Poster
Rep: Reputation: 24
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.

Last edited by jamtat; 06-23-2015 at 11:57 AM.
 
Old 06-23-2015, 12:07 PM   #22
Sefyir
Member
 
Registered: Mar 2015
Distribution: Linux Mint
Posts: 633

Rep: Reputation: 316Reputation: 316Reputation: 316Reputation: 316
Quote:
I should point out at the outset that I did not ask about authenticating, but rather about the passphrase,
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:
Code:
ssh-rsa AAAAsgdh...longstringofcharacters... == bob@host
  • 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
Code:
Enter passphrase for key '/home/bob/.ssh/id_rsa:
With no public key (using password authentication)
Code:
bob@host's password:
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.

Last edited by Sefyir; 06-23-2015 at 12:13 PM.
 
Old 06-23-2015, 12:27 PM   #23
jamtat
Member
 
Registered: Oct 2004
Distribution: Debian/Ubuntu, Arch, Gentoo, Void
Posts: 132

Original Poster
Rep: Reputation: 24
Quote:
Originally Posted by Sefyir View Post
In my case:
To unlock private key without ssh-agent
Code:
Enter passphrase for key '/home/bob/.ssh/id_rsa:
With no public key (using password authentication)
Code:
bob@host's password:
Without knowing the intimate details, I am sure the first one is done local side.
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)?
 
Old 06-23-2015, 06:20 PM   #24
mralk3
Senior Member
 
Registered: May 2015
Distribution: Slackware, OpenBSD
Posts: 1,559

Rep: Reputation: 882Reputation: 882Reputation: 882Reputation: 882Reputation: 882Reputation: 882Reputation: 882
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.

Last edited by mralk3; 06-23-2015 at 06:23 PM.
 
Old 06-23-2015, 08:29 PM   #25
jamtat
Member
 
Registered: Oct 2004
Distribution: Debian/Ubuntu, Arch, Gentoo, Void
Posts: 132

Original Poster
Rep: Reputation: 24
Quote:
Originally Posted by mralk3 View Post
For example, my key pair is secured with a 36 character password.
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?
 
Old 06-23-2015, 10:42 PM   #26
mralk3
Senior Member
 
Registered: May 2015
Distribution: Slackware, OpenBSD
Posts: 1,559

Rep: Reputation: 882Reputation: 882Reputation: 882Reputation: 882Reputation: 882Reputation: 882Reputation: 882
Quote:
Originally Posted by jamtat View Post
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.
 
Old 06-24-2015, 05:41 PM   #27
jamtat
Member
 
Registered: Oct 2004
Distribution: Debian/Ubuntu, Arch, Gentoo, Void
Posts: 132

Original Poster
Rep: Reputation: 24
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.
 
Old 07-12-2016, 05:36 PM   #28
jamtat
Member
 
Registered: Oct 2004
Distribution: Debian/Ubuntu, Arch, Gentoo, Void
Posts: 132

Original Poster
Rep: Reputation: 24
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:
Code:
-A INPUT -p tcp --dport 1234 -m state --state NEW -j ACCEPT
Now access to the wiki is restored anew.

So the full set of rules now looks like:
Code:
*filter
# most rules below pilfered from https://www.linode.com/docs/security/securing-your-server
#  Allow all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT -d 127.0.0.0/8 -j REJECT

#  Accept all established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

#  Allow all outbound traffic - you can modify this to only allow certain traffic
-A OUTPUT -j ACCEPT

#  Allow SSH connections so long as not more than 3 in 10 seconds are attempted, in which latter case drop packets (courtesy Seyfir at Linuxquestions)
-A INPUT -m recent --set --name SSH
-A INPUT -p tcp --dport 22 ! -s 192.168.1.1/24 -m recent --name SSH --update --seconds 10 --hitcount 3 --rttl -m conntrack --ctstate NEW -j DROP
-A INPUT -p tcp --dport 22 -j ACCEPT
-A INPUT -p tcp --dport 1234 -m state --state NEW -j ACCEPT

#  Allow ping
-A INPUT -p icmp --icmp-type echo-request -j ACCEPT*filter

#  Log iptables denied calls
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

#  Drop all other inbound - default deny unless explicitly allowed policy
-A INPUT -j DROP
-A FORWARD -j DROP
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.

Last edited by jamtat; 07-12-2016 at 05:43 PM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Securing SSH jonnybinthemix Linux - Newbie 3 06-04-2014 06:00 AM
Securing SSH ZilverZtream Linux - Security 5 12-10-2004 03:33 PM
securing using firestarter or iptables PennyroyalFrog Linux - Security 3 10-13-2004 01:36 PM
Securing iptables kola Linux - Security 20 09-13-2004 03:28 AM
securing ssh robberttheman Linux - Security 8 08-27-2004 07:36 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 01:18 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration