How to accurately setup ssh password only?

M

max21

https://unix.stackexchange.com/questions/15138/how-to-force-ssh-client-to-use-only-password-auth

Rare question, right? Those very (google) few got all kinds of trick that may be treated royally by Sinbad. I dare not play the game(s) until the knowingly, say-so.

I want/need to setup three types of sshd_config files. One for keys only, one for password only, and one that must use both keys and password/passphase.

I know keys are the most popular but I really want to be sure of a password only setup with no peepholes in any of its configuration files. That’s it, and that’s all ... other than, I don’t want to screw-up my one and only vps, ever again.

Appreciate all!
 
I really hope you don't expect me to follow that link, because I won't. There's a reason I'm active here and not on that website, so I really have 0 interest in visiting.

As to your question I suggest to read sshd_config(5) or actually look inside the default file, then it should be pretty obvious which options you need:

Code: 
# Authentication:

#LoginGraceTime 2m
#PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes
There's even:
Code: 
# Change to yes to enable built-in password authentication.
#PasswordAuthentication no
#PermitEmptyPasswords no

# Change to no to disable PAM authentication
#ChallengeResponseAuthentication yes
No offense intended but I get the impression that you never even bothered to look into this file, which should honestly be the first place to look. Especially considering the fact that the options themselves are pretty obvious, and for anything else there's always the manualpage.
 
ShelLuser said:
I really hope you don't expect me to follow that link, because I won't.
Click to expand...
Why so rude? This is not about you. There are many interesting things to test in that link, and they provided their own reason for it. Just because this is the only forum that I ever been a member of in my life don’t mean the world will not turn without it. Good technology/ideas are everywhere. It's was the outsiders that help FreeBSD to become what it is.

About my efforts; I been reading the Handbook and hundreds of thousands of thread since I been here. After 10 years it should have been 10,000 questions, not 400. It took many great minds to build this systems and even they don't know it all.

I never ask for weeks to months about anything until I done most or all that I could figure. I just got into some serious ssh during the pass few weeks because I realize what I had put into production a few months ago was not working the way I imagine it was. I don’t have a team like most of you who works in the field, or retired from. FreeBSD is more or less been a hobby to me and I do want to learn all I can.

Anyway, I have only one final question and it is not in the handbook and I’m too afraid to chance it without knowing for sure that it will harm anything on a running VPS. An answer to this question will solve ALL my ssh issues. Text file scanning is for machines and experts. It don't work for me. The less I see the more I understand:

Is it OK to delete lines that I will never use inside sshd_config file?

Such as only KerberosOrLocalPasswd yes may remain because it has something to do with /etc/passwd which may effect other variables. Even sshd_config(5) don't have room to go deep into all the gritty details. We usually stumble upon stuff like that years latter or in a security update. Yes I do my homework since day-1.the best I can.

Things like that I would keep around to keep the brain-juice flowing. All the rest are totally useless for what I plan to do. Can I safely delete them?

Code: 
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

AND SOME OF THESE TYYES:
#X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
 
max21 said:
Is it OK to delete lines that I will never use inside sshd_config file?
Click to expand...
Depends on the lines in question and your preferences. If they are commented out then you obviously won't miss them because they never did anything in the first place.

If they're not commented out and you remove them then SSH will resort back to the default behavior. Something usually showcased within the lines that are commented out.

Something which the sshd_config(5) manualpage would also have told you.
 
Michael Lucas has an excellent presentation on this (here's the video). This is the rough technique for testing new configuration for sshd without disturbing your existing configuration until you are confidant.

1. ssh in as a regular user (or root if you must).
2. Create a new sshd_config file, let's call it sshd_config_test . Either copy the stock one or make up your own from scratch, it doesn't matter.
3. Execute sshd -D -p 2222 -f sshd_config_test. You now have a second ssh daemon running on port 2222 in foreground.
4. Try to ssh into the box from the outside using ssh -p 2222 connect to that port.

If it works, great you are all set, replace the stock sshd_config with the test file. Restart the sshd daemon which will kick you off the host.

If it doesn't work, re-run step 3, but add -d and read the messages. More -d's to get more detail. You can also add the debug switch on the ssh side but usually one side is enough to figure it out.
 
leebrown66 said:
Michael Lucas has an excellent presentation on this (here's the video). This is the rough technique for testing new configuration for sshd without disturbing your existing configuration until you are confidant.

1. ssh in as a regular user (or root if you must).
2. Create a new sshd_config file, let's call it sshd_config_test . Either copy the stock one or make up your own from scratch, it doesn't matter.
3. Execute sshd -D -p 2222 -f sshd_config_test. You now have a second ssh daemon running on port 2222 in foreground.
4. Try to ssh into the box from the outside using ssh -p 2222 connect to that port.

If it works, great you are all set, replace the stock sshd_config with the test file. Restart the sshd daemon which will kick you off the host.

If it doesn't work, re-run step 3, but add -d and read the messages. More -d's to get more detail. You can also add the debug switch on the ssh side but usually one side is enough to figure it out.
Click to expand...
ShelLuser, procrastinators ticks me off too, but that is not me. When I follow proven suggested instructions to no avail, it leads me to believe that something is mis-configured elsewhere. Sometimes I ask nothing more about it when I can't find it. So I sometimes move on to the next steps of my project; which usually leads me back to the previous issue. Now I’m back to asking basically the same question over again weeks latter. You were not being rude. It was like the oldest speaking to one of his sibling ... I feel honored. Thank you.

leebrown66, about the video and your brief: I had the video on repeat for three days (all-day), even through my sleep I was trying to listen. There was three easy-to-miss points that I was trying to catch. They made things all so clear when I always thought the opposite or never thought much about them at all. I ended up going through the relevant parts doing trial and error with sshd_config - - testing each line enabled or disallowed (the with and with outs) to the point of understanding where even PAM comes in and what she does. I started reading each debug output while testing many good and bad ssh commands; over and over again until last night. That is why I’m replying so late. However, for some reason I still cannot get passwordless to work. I kind of rather see what PAM has to say at the end of the debugging anyway. The good thing is I can live without passwordless for now. Everything else works perfectly and I mostly understand what’s going on under the hood. That what’s important.

I Thanks you both
 
You must log in or register to reply here.
Back
Top