Solved Questions about ssh

[sidetone]

There is ssh_config and sshd_config in /etc/ssh/ to set ssh security.

Are these two only needed for ssh root access? In other words I don't need them for a program such as firefox using ssh? Also, is it correct, if I'm not running a server I don't need sshd?

About enabling protocol 2, an rkhunter result showed me confusion. In sshd_config and ssh_config I had

Protocol 2

with Protocol 1 commented out, yet rkhunter's results showed ssh protocol 1 running. Maybe this is malicious software overriding my settings.

I don't fully understand ssh_config and sshd_config. I read that setting

PasswordAuthentication no

with a setting for using keys, disables the use of passwords in favor of keys. Is this correct, in that this doesn't mean no type of authentication at all?

These settings seem counter-intuitive.

 

[UnixRocks]

Have you looked at the man pages for ssh_config(5) and sshd_config(5)? Turning off password authentication leaves either UsePAM with ChallengeResponseAuthentication and/or key-based authentication. Which I presume is what you want.

To determine your ssh(1) protocol version with which you can connect, type ssh -v localhost on the system in question and look for

...
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1_hpn13v11 FreeBSD-20140420
...

Specifically the part containing "Remote protocol version ...".

Finally, for the record, I strongly recommend not enabling direct root login on ssh. Add your user to the wheel group and use su - to get root after login with your user.

 

[wblock@]

Are these two only needed for ssh root access?

SSH root access to what? sshd_config determines what the sshd daemon allows on the machine it runs on. ssh_config determines how the SSH client runs, but cannot provide root SSH access to a remote machine if that machine does not allow it. Which it shouldn't.

In other words I don't need them for a program such as firefox using ssh?

Very few programs use SSH programs directly. As far as I know, Firefox does not use SSH at all. SSL, maybe?

Also, is it correct, if I'm not running a server I don't need sshd?

What is a server, exactly? Without sshd(8) running, a machine will not be able to accept SSH connections.

 

[sidetone]

Both of those together answered my questions. For my purposes of what I'm doing, that answers it. There's more stuff I don't fully understand, but I'll have to do more research on it, or find the right questions to ask if that becomes an interest to me.

I wasn't sure about Firefox. I recognized it used SSL, but there was some association between that and SSH, I wasn't sure about. Your responses answer all I need to know for now.

ssh -v localhost

That's great for what I'll need to troubleshoot.

Thanks for your answers.

 

[sidetone]

It won't hurt but there's no need for it, sshd(8) uses protocol version 2 (and only version 2) by default.

That's what I read, but wasn't fully understanding it. Version 2 is initially commented out. Is it similar to how /etc/defaults/rc.conf is the default, and it's like having /etc/rc.conf with the same redundant option?

I know how to disable sshd, but if I wanted to toggle ssh, is there an ssh_enable=" " ability in rc.conf? It wasn't in the manpages, or listed in defaults. Or is that toggled on and off by sshd?

 

[ShelLuser]

I know how to disable sshd, but if I wanted to toggle ssh, is there an ssh_enable=" " ability in rc.conf? It wasn't in the manpages, or listed in defaults. Or is that toggled on and off by sshd?

What exactly do you mean with 'toggle'? To enable/disable it? ssh is a mere userland program, same as ls and telnet for example. You don't "toggle" those, but if you insist you can of course make it impossible for others to use it. One option could be to change it's permissions using chmod(1) but I'd recommend against that, instead I'd suggest disabling the outgoing port 22 in your firewall.

If you want to get rid of SSH entirely then that's also possible, but would require a bit more effort. SSH is part of the FreeBSD base system which you can compile yourself. While doing that you can also specify which parts of the base system need to be compiled by defining those options in /etc/src.conf. See src.conf(5) for an overview.

And if you want to know more about compiling the base system then you should refer to the handbook; it has a chapter about rebuilding the world.

Still.. If this is about discovering and experimentation then this could be an interesting thing to do. But if we're talking about a live server and your only goal is to secure it (just a guess on my part) then I wouldn't bother here. There are much better ways to address FreeBSD security, and a good starting point for it is chapter 13 of the handbook.

 

[sidetone]

To enable/disable it? ssh is a mere userland program, same as ls and telnet for example. You don't "toggle" those, but if you insist you can of course make it impossible for others to use it. One option could be to change it's permissions using chmod(1) but I'd recommend against that, instead I'd suggest disabling the outgoing port 22 in your firewall.

This part answers my question. The rest I am familiar with. I can also block sshd on hosts.allow.

I wanted to go beyond the firewall, because on one setup, everything went haywire anyways. I blocked some ports on the firewall before doing anything else, and rkhunter showed problems on them anyways. rkhunter even showed SSH1 running when I had only SSH2 enabled (for ssh and sshd) in the /etc/ssh/ directory. Then logs of rkhunter errors disappeared. It was a lot of funky behavior. I think this only happens when rkhunter is compiled with nmap (to check against portscans). It's not rkhunter by itself, or portsentry, because they're warning me. I can't be the only person who notices this, unless I have no clue of what I am doing at all and I'm causing my own errors here. Thread portsentry-possibly-causing-false-positives-in-rkhunter.54210

I was already considering the option of recompiling the world, but was reluctant to do that so far because I remembered it's complexity. It is a surefire way to prevent something from running that shouldn't be. It looks like it has gotten easier since then, and It looks like I'll be doing that.

That chapter in the Handbook didn't help me much. FreeBSD is secure, but the Handbook appears to make the assumption it is already locked down. FreeBSD 6 Unleashed (in the bonus section which is only on .pdf) is much better for security, but much of it is obsolete, and I couldn't make out some differences from it and the documentation of the default here.

 

[kpa]

Do not trust /etc/hosts.allow (and the related files) for actually providing any sort of protection, the files are a leftover from the naive era of internet where most of the hosts had static IP addresses and you could assume that IP addresses didn't change. Use a proper firewall like PF for all filtering.

 

[SirDice]

That's what I read, but wasn't fully understanding it. Version 2 is initially commented out. Is it similar to how /etc/defaults/rc.conf is the default, and it's like having /etc/rc.conf with the same redundant option?

No, it's simply the application's default setting. And has been since OpenSSH 5.4:

* After a transition period of about 10 years, this release disables
SSH protocol 1 by default. Clients and servers that need to use the
legacy protocol must explicitly enable it in ssh_config / sshd_config
or on the command-line.

http://www.openssh.com/txt/release-5.4

 

[sidetone]

Do not trust /etc/hosts.allow (and the related files) for actually providing any sort of protection, the files are a leftover from the naive era of internet where most of the hosts had static IP addresses and you could assume that IP addresses didn't change. Use a proper firewall like PF for all filtering

hosts.allow lists applications by

 : ALL : deny

. What you said makes sense when IP matters.

No, it's simply the application's default setting.

This default install has both

#Protocol 2,1

commented out in ssh_config and sshd_config of the directory /etc/ssh/. So this blocks it. It appears, the protocols also have to be uncommented to use the application's default settings.

Here's what I gather. To use SSH protocol 1, it must be specified on the command line and by uncommenting Protocol 1 in /etc/ssh/.