# (newbie) Openssh-hardening

## while true

Ola

I have at home 2 laptops, both with Gentoo  :Smile: 

I decided to use ssh to transfere files between them.

Now it is working nicely, but...

I read that I have "kevlar vest with open zipper".

So I found out that I have to configure /etc/ssh/sshd_config file.

I looked at it, and almost all lines are commented out (starting with #)

Uncommented lines are:

PasswordAuthentication no

UsePAM yes

PrintMotd no

PrintLastLog no

Subsystem	sftp	/usr/lib64/misc/sftp-server

Others are commented out.

Is 'PasswordAuthentication no' safe? 

Right now I do need to enter password, in order to log in.

I learned that I have to: 

change port,

use protocol 2,

not to permit root login,

and to use privileged separation.

So, is this just the thing of removing the # and set values?

Like:

#Port 22 to

Port XXXXX ?

#Protocol 2 to

Protocol 2 ?

#PermitRootLogin yes to

PermitRootLogin no ?

#UsePrivilegeSeparation yes to

UsePrivilegeSeparation yes ?

I know what port is, and I guess the Protocol 2 is newer, more secure.

Does denieing root login means, that I can not operate as root when I connect?

Or does this mean that I can log in in shell only as user and than easily go su -?

Because I will need to get root access...

I have no idea what UsePrivilegeSeparation stands for...

What are other necessary steps?

I guess I do not need X (video mode), this is disabled by default?

(for this I am thinking of using vnc, or is this considered as security bridge?)

And another thing,

I have dynamic IP, does this mean, that I can not log in from outside?

If I can, what should I do?

Thank you

----------

## krinn

 *while true wrote:*   

> 
> 
> Is 'PasswordAuthentication no' safe? 
> 
> Right now I do need to enter password, in order to log in.

 

better set usepam to no so you won't have any password access but only by keys and it's better (and easier)  http://www.gentoo-wiki.info/SECURITY_SSH_without_a_password

 *Quote:*   

> I learned that I have to: 
> 
> change port,

 lmao, yeah, pickup 135 that's a nice port to use, 80 is too common

(no, you don't have too, it's totally stupid to even think that could be a shield)

 *Quote:*   

> Or does this mean that I can log in in shell only as user and than easily go su -?

 

That

 *Quote:*   

> I guess I do not need X (video mode), this is disabled by default?
> 
> (for this I am thinking of using vnc, or is this considered as security bridge?)

 

not if you tunnel it

http://www.gentoo-wiki.info/Tunnel_VNC_over_SSH

 *Quote:*   

> And another thing,
> 
> I have dynamic IP, does this mean, that I can not log in from outside?
> 
> If I can, what should I do?
> ...

 

of course you can, but you need to find what is that ip.

you can make a script on the computer that check your ip and if ip <> previousip mail it to somewhere. this way the email is fix, so you can get the info in your email.

or simply use a dns service, noip dyndns ... tools exist to update them easy (emerge -s noip2), it's just this time your computer send the infos to the service and the service provide a dns that will point to your ip.

----------

## Mousee

These are my suggestions of what you might do, though they are in no way a complete list of possible things you could do to further secure yourself:

Use a non-common port. - So instead of using the default port 22, use something like port 2222 or such instead. Keep in mind however that some external locations, such as a place of business or a university, may likely be extremely limited in the which ports they will allow you to connect to. In some cases only port 80 will be available.

Disallow/Disable root login. - As you've already stated, you'll want to be able to login as root. If someone were to figure out your root password, they could do quite a bit of damage to your Linux system and possibly anything connected to it. Therefore disabling root and connecting first as a common/privileged user, would be best. As long as your user is in the wheel group, you should be able to use the su command to switch to root, like so:  

```
mousee@localhost$ / su -
```

 Where using the command su - will prompt you for your root password and you'll then be "logged in" as root. You can type "exit" at any time to return to your normal user.

Above, I suggested switching to root using the su - command. While I suggest doing so if you know you're going to be running many commands that require root privilege, I heavily advise against doing so in any other case. Use a program like sudo ('emerge app-admin/sudo') when you only need to run a few commands with root privileges. Doing so further eliminates the chance of anyone "hijacking" your connection to damage your remote system (at home). Mind you this is a common security precaution and has little to do with your SSHD - I just recommend it if you intend to be logging in to your *nix system, away from home, often. Be sure to read up on using Sudo too.

Use Public Key Authentication instead of a password. - Be sure to read the wiki page I linked to for more details, but this essentially eliminates (or nearly does anyways) the possibility of an outside party procuring your user password. They could, however, potentially hijack your RSA Key but the chance of doing so is less likely than hijacking your password. It's also quite convenient!

Dynamic IP? No problem! (That sounded retarded...) - I won't go into too much detail, because this wiki page explains it quite well, but essentially you setup the 'ddclient' to check if your IP has been updated every once in a while, and if it has, it updates a (free) domain name of your choosing. Be sure to read up on it before just launching into doing so, but I've used both no-ip.com and dyndns services before and they work for your purposes quite well. You'd be logging into your home system via something like "my-home.info" instead of "123.456.789.123" (quite a pain to remember, especially if it's dynamic!).

Other things within /etc/ssh/sshd_config that you might consider modifying are the KeyRegenerationInterval and ServerKeyBits settings. For your purposes, as a home user, I would suggest not bothering with these however as they should be quite alright as is. As long as your home network is behind a firewall of some sort anyways.

----------

## while true

Hello guys and thank you for your time and quick answers.

Let me take little steps first:

I changed:

#Port 22 to

Port XXXXX 

#PermitRootLogin yes to

PermitRootLogin no 

#UsePrivilegeSeparation yes to

UsePrivilegeSeparation yes  

Now as I try to log in as root it keeps asking me for password, like I mistyped it, and since I havent, I guess I can not log on directly as root.

I coul log in as user and take it from there to root. GREAT! (khuHAHAHAHAHA!!!!)

Now, next thing I tryed was copying files, and I could not. 

I am working on 'grom', I connected myself to 'munja' and:

```
munja@1-4 ~ $ scp -r skripte/ grom@192.168.1.100:/home/grom/

ssh: connect to host 192.168.1.100 port 22: Connection refused

lost connection

munja@1-4 ~ $
```

for connecting I had to specify: ssh -p XXXXX munja@192.168.1.101

but how come I can not copy?

thank you

----------

## NeddySeagoon

while true,

The commented lines in sshd.config are reminders of the default values, so  

```
#PermitRootLogin yes to

PermitRootLogin no 
```

is a good thing. 

```
#UsePrivilegeSeparation yes to

UsePrivilegeSeparation yes 
```

does nothing as yes is the default anyway - its harmless.

Security by obscurity is no security at all. You should not regard using a random port for ssh as a security measure.

----------

## Hu

 *while true wrote:*   

> 
> 
> ```
> munja@1-4 ~ $ scp -r skripte/ grom@192.168.1.100:/home/grom/
> ```
> ...

 Your connection was refused because scp, like ssh, uses port 22 by default.  Use -P XXXX with scp or modify your ~/.ssh/config to remember that the system always requires the alternate port.  The latter change will remove the need to explicitly set -p XXXXX when calling ssh, also.

 *NeddySeagoon wrote:*   

> Security by obscurity is no security at all. You should not regard using a random port for ssh as a security measure.

 Indeed.  The only value to using a random port is that it will make bot attacks less frequent, which will reduce the noise in system logs from failed authentications.  It does not prevent a bot that does find the chosen port from attacking as normal.

[Edit: fixed name of per-user ssh configuration file.]Last edited by Hu on Sun Sep 26, 2010 6:55 pm; edited 1 time in total

----------

## while true

Ola guys, thanks for input!

aha, so I have two options:

to change back to port 22 in /etc/ssh/sshd_config or

to modify ssh_config file for each user?

If I understand correctly, 

if I change /etc/ssh/ssh_config 

it will not work since if goes first with one in user .ssh/ folder?

but:

```
grom@C6820s ~/.ssh $ ls -a

.  ..  known_hosts
```

lists me no ssh_config file...on neither computer

If I change port in /etc/ssh/ssh_config (in there it does mention port 22 at some point) and as long as I do not have ~/.ssh/ssh_config file, it should work?

also I tried adding -p XXXXX to scp:

```
munja@1-4 ~ $ scp -p XXXXX -r /home/munja/skripte/ grom@192.168.1.100:/home/grom/

ssh: connect to host 192.168.1.100 port 22: Connection refused

lost connection

munja@1-4 ~ $
```

and

```
munja@1-4 ~ $ scp -p 22 /home/munja/skripte/ grom@192.168.1.100:/home/grom/

ssh: connect to host 192.168.1.100 port 22: Connection refused

lost connection

munja@1-4 ~ $
```

but no go... 

I would prefer to change port, unless I do not succeed, than I'll change it back to port 22 ...

*******************************

*******************************

Ok, so port in no big issue security wise, 

so I am left with disabled root login.

Next thing are those keys that Mousee & krinn suggested 

(I read a bit, but it is not the same thing, or is it?)

About connecting from outside, on my dynamic IP.

I asked that because I was hoping the answer would be NO, kheh... From security point of view, what should I do in order to NOT BE ABLE to reach my machines from outside? I guess if I need dns or other stuff, I am quite secure? (I am uncertain about Krinn's mentioning the email)

From that point of view, do I need those keys?

Bottom line is, that I want to use ssh, but I wan it to be secure. I will use it to move files/folders from one computer to another, but that is home based. I do not attend to reach my computers from any other place.

Mostly, I do not want others to reach them  :Wink: 

----------

## Hu

Per man ssh_config, user configuration is read before system configuration.  If the user configuration specifies an option, then the corresponding directive in the system configuration is ignored.  If the user configuration does not specify a value, then the one from the system configuration is used.  If the user configuration file is missing, that is equivalent to it being present and empty.

You added -p XXXXX.  I said to use -P XXXXX.  Case matters.

If your goal is to prevent access from outside the local network, then changing the port is not the solution I would use.  Rather, I would use some combination of a packet filter to prevent incoming connections from reaching the sshd and an sshd_config that prevented it from receiving or allowing those connections.  Use iptables for a packet filter.  Use ListenAddress to force sshd to listen only on the internal interface if your machine is multihomed.  You can probably abuse the Match directive and DenyUsers directive to create a rule that only allows users coming from your local network.

----------

## krinn

Hu sometimes simple things is enough  :Smile: 

If you want only your local network to access SSH and nobody from outside just do that :

```

echo "sshd: ALL" >> /etc/hosts.deny

echo "sshd: LOCAL 192.168.0.*" >> /etc/hosts.allow
```

(replace 192.168.0.* with your network ip range: this rule will allow 192.168.0.1 upto 192.168.0.255 to access sshd)

----------

## Mousee

 *while true wrote:*   

> 
> 
> Bottom line is, that I want to use ssh, but I wan it to be secure. I will use it to move files/folders from one computer to another, but that is home based. I do not attend to reach my computers from any other place.
> 
> Mostly, I do not want others to reach them 

 

Then my suggestion is to leave your SSH port closed on your firewall until you know you're going to be out-of-the-house and will require its use. Another option would be to leave the port open to the public for only certain times of the day/week when you know you'll be out and might use it. Keeping that port closed as often as possible (and any others) is the best security you can have.

There's no point in changing your SSHD port if you have no intention of ever connecting to the SSHD server via your external IP anyways, as no one but yourself, within your home/local network, will be able to connect to it anyways -- again, assuming you do have a firewall/router and it is setup properly.

Hu's suggestion is excellent as well - if you aren't behind a firewall/router.

----------

## while true

Ola

kheh, Krinn is usualy krinn -v, kheh,

but his suggestion is short and simple to understand, for me.

```
echo "sshd: LOCAL 192.168.1.1-255" >> /etc/hosts.allow
```

 would be the right syntax?

The thing is that I do not have those two files, this is no biggy, is it?

We have router, I have room-mate and router is his.

We looked, but we could not locate and close port 22.

Hu

aha p & P, kheh, thanx...

I do not have iptables... if I install them, (is it gui?) will I find ListenAddress, Match and DenyUsers? 

If I go Krinn's way, are iptables necessary?

I believe I do not have firewall, (watch out, newbie shooting: are iptables firewall?) 

(I read somewhere if I have router, than there is not much call for firewall). 

I don't want EVER to access my machines from outside.

I am quite inclined (I like, because I understand) krinn's solution.

Should I have firewall installed on my machines? 

Which ones are recommended?

Thank you.

----------

## krinn

```
echo "sshd: LOCAL 192.168.1.*" >> /etc/hosts.allow
```

Like that for computers range 192.168.1.1 upto 192.168.1.255

You don't need iptables just for sshd, this will do the same, but you may need iptables for many others things.

 *Quote:*   

> (I read somewhere if I have router, than there is not much call for firewall). 
> 
> I don't want EVER to access my machines from outside.

 

If you really never wish access your computer from outside, the easiest solve is :

- set your router to discard ping from internet

- set your router to not allow distant logging (name like that or similar, on mine it's named "Turn Remote Management On", lol in this case, don't turn that on)

- set your router DMZ to nothing

- disable your router wireless function and use wire for your network

You can also drop them to a dead host by setting a DMZ host to a not used IP, let's say you will never use 192.168.1.2

- Set your router to DMZ 192.168.1.2

- Set your router to DHCP 192.168.1.10-192.168.1.255

- Still don't set distant login on your router (this is a stupid idea)

- Still don't allow ping from internet on your router

- disable your router wireless function and use wire for your network

- And now: never forget no one should be on 192.168.1.2 as everything coming from internet will goes to 192.168.1.2

you can also (still with a "i don't want anyone to access it from outside" in mind).

```
echo "ALL: ALL" >> /etc/hosts.deny

echo "ALL: LOCAL 192.168.1.*" >> /etc/hosts.allow

```

First command will blacklist everyone for everything

Second one, will allow anyone from your local network to do anything <- important, might not be something you wish, but for a start, that's a good way to allow your local network to run everything easy. A real bad idea if your network is wireless.

You will might need a better filtering like iptables if you wish a finer control, routing, log who is doing what (or trying)... on your local network. But for a basic "i want" "i don't wan't", hosts.deny & hosts.allow will made the job. 

Just remember that using a wireless network, the rules won't apply to someone coming close to you, as his computer will get on your local network, those rules are holes on that case, also is someone plug his computer to your router, but it's something you should see if you're not blind  :Very Happy: 

----------

## Etal

 *Mousee wrote:*   

> Use Public Key Authentication instead of a password. - Be sure to read the wiki page I linked to for more details, but this essentially eliminates (or nearly does anyways) the possibility of an outside party procuring your user password. They could, however, potentially hijack your RSA Key but the chance of doing so is less likely than hijacking your password. It's also quite convenient!

 

And if you set the password on your private key (as you should!), no one will be able to break in unless they both got your private key and your password.

I also like this guide more, since it is far more in depth and also explains keychain, which is much more convenient than just ssh-agent.

----------

## while true

Ola,

Sorry for delayed reply,

Khuhm well, I had a long talk with room-mate, who has strong opinion that we should keep wireless...

Now, I am very opposed to ill the relationship over some thing, 

even it is computer security... 

So I will just have to keep my passwords on some usb stick or so..

Other than that I do not have 'top secret' data...

Of course, there is a possibility of breaking into the system, 

but once I heard one old man with big gray beard say, 

that: "more than having good OS, it is more important 

to have a good and healthy society" ...or something in that line...

*************************

So, working under those terms, if I do not use wireless connection, 

but just wired, and someone else breaks into wireless, 

can she/he connect to my machines?

Thank you

----------

## cach0rr0

like many others I recommend you go to key-based authentication and forgo the issue of someone getting into your sshd entirely. They simply cannot short of a vuln in sshd itself, or wherever you keep your keys becoming compromised 

The result is something like this:

```

[meat@gw ~]$ ssh root@sms1

Permission denied (publickey).

[meat@gw ~]$ ssh -i ~/.ssh/id_dsa root@sms1

Enter passphrase for key '/home/meat/.ssh/id_dsa':

Last login: Mon Sep 27 04:34:00 GMT 2010 from gw.whitehathouston.com on pts/0

```

The docs people have suggested thus far detail creating a private/public key pair. Short version? Run ssh-keygen, enter a password when asked, take your public key (it will be id_dsa.pub by default), copy it to /root/.ssh/authorized_keys on the server running sshd, then configure sshd_config to use only pubkey auth. 

As an example, this is literally the entirety of my sshd_config file (i strip comments from my config files  :Wink:  )

```

Protocol 2

PubkeyAuthentication yes

AuthorizedKeysFile      .ssh/authorized_keys

PasswordAuthentication no

ChallengeResponseAuthentication no

UsePAM yes

PrintMotd no

PrintLastLog no

Subsystem       sftp    /usr/lib64/misc/sftp-server

```

With this configuration, user/password based auth is not allowed. You only need to enter the password to unlock your private key, but the ssh daemon itself accepts no attempts to login with user/pass

Ultimately you will get annoyed by the brute-force attempts with any other method. With some it takes longer than others (e.g. port knocking), but eventually you will become fed up with it, and go the key-only route, so might as well save yourself some time up front  :Smile: 

----------

## Cyker

Just an aside regarding the port:

There is very little point changing the port from 22 for the sshd server UNLESS that system is directly accessible.

It is safe to leave it at 22; Even if you later open up a port forward to your server, it is the port forward's port that you change.

For instance, on my system the external sshd port is port 1337, but this is port-mapped to 22 on my server so internally I can still use port 22.  :Smile: 

Using a non-standard port externally is a good idea if only to cut down on the log pollution from the zillions of port scanners running out there, especially now that they've become distributed and made IP blacklisting a lot less effective.

----------

## Mousee

 *Cyker wrote:*   

> 
> 
> Using a non-standard port externally is a good idea if only to cut down on the log pollution from the zillions of port scanners running out there, especially now that they've become distributed and made IP blacklisting a lot less effective.

 

Aye exactly. It makes you a less likely target when some "cracker" goes about scanning residential ISP's for commonly known vulnerabilities, when using a specific port range, which I've seen often enough in my logs. Otherwise it is, as Neddy suggested, quite pointless.

----------

## while true

Ola guys,  

First, thanks for all input and time!

OK I went with this key authentication, 

so I need more help since I sc***ed up something...

my sshd_config:

```
Port 22

Protocol 2

PermitRootLogin no

PubkeyAuthentication yes

AuthorizedKeysFile   .ssh/authorized_keys

PasswordAuthentication no

ChallengeResponseAuthentication no

UsePAM yes

PrintMotd no

PrintLastLog no

UsePrivilegeSeparation yes

Subsystem   sftp   /usr/lib64/misc/sftp-server
```

here is what i did in terminal:

```
C6820s ~ # ssh-keygen

Generating public/private rsa key pair.

Enter file in which to save the key (/root/.ssh/id_rsa): 

Enter passphrase (empty for no passphrase): 

Enter same passphrase again: 

Your identification has been saved in /root/.ssh/id_rsa.

Your public key has been saved in /root/.ssh/id_rsa.pub.

The key fingerprint is:

xy:xy:xy:xy:xy:xy:xy:xy:xy:xy:xy:xy:xy:xy:xy:xy root@C6820s

The key's randomart image is:

+--[ RSA xyxy]----+

|    wwwwwww      |

|    wwwwwww      |

|    wwwwwww      |

|    wwwwwww      |

|    wwwwwww      |

|    wwwwwww      |

|    wwwwwww      |

|    wwwwwww      |

|    wwwwwww      |

+-----------------+

C6820s ~ # 
```

I went to /root/.ssh/ and there was no authentication_keys file, so I did:

```
cp id_rsa authentication_keys
```

Now, I know this is a mistake, since I need to copy id_rsa.pub file...

I did the same on other computer.

Using the usb I moved id_rsa files 

from one computer to other and did this on both computers

```
cat /media/disk/id_rsa >> /root/.ssh/authorized_keys
```

Since it did not work, (it did ask me to store) I review and I found out

that I used wrong file id_rsa instead of id_rsa.pub

So I deleted authorized_keys files and repeated

cp id_rsa.pub authentication_keys

moved id_rsa.pub with usb from one computer to another and

at /media/disk/id_rsa >> /root/.ssh/authorized_keys

Now, it is still not letting me in...

```
grom@C6820s ~ $ ssh munja@192.168.1.101

Permission denied (publickey).

grom@C6820s ~ $ su -

Password: 

C6820s ~ # ssh munja@192.168.1.101

Permission denied (publickey).

C6820s ~ # ssh root@192.168.1.101

Enter passphrase for key '/root/.ssh/id_rsa': 

Enter passphrase for key '/root/.ssh/id_rsa': 

Enter passphrase for key '/root/.ssh/id_rsa': 

Permission denied (publickey).

C6820s ~ # ssh root@192.168.1.101

Enter passphrase for key '/root/.ssh/id_rsa': 

Permission denied (publickey).

C6820s ~ # ssh root@192.168.1.101

Enter passphrase for key '/root/.ssh/id_rsa': 

Enter passphrase for key '/root/.ssh/id_rsa': 

Enter passphrase for key '/root/.ssh/id_rsa': 

Permission denied (publickey).

C6820s ~ #
```

and:

How to restart remote computer in ssh, ok I know that, but it has slim for logging in, so how to log in and continue working?

Thank you.

EDIT:

ok, I guess the mistake was that i was doing those steps as root!

I just did it as user, and it works!!!

(UHAHAHAHAHAHAHA!!!!!!)

Now, I have a question, my /root/.ssh/ has those files that I do not need any more.

Can I simply delete them? is that ok?

Now I use my key to log in in ssh. kheh.

How high is my zipper on my kevlar vest?

----------

## krinn

ahah ssh hell  :Very Happy: 

No it's simple, you just misunderstood who is doing what.

1/ you have setup /root/.ssh/authorized_keys

So you are just telling your computer: if anyone wish to be root with ssh on that computer, it might do that only if he is in authorized_keys

2/ then you tried:

ssh munja@192.168.1.101

This time you say: "hello i'm someone on another computer and i wish to be munja here"

And the answer from 192.168.1.101 was "let me check, hmmmm, no one is allow to access munja here sorry"

Why ? Because to do that you need to setup /home/munja/.ssh/authorized_keys to allow that. Setting /root/.ssh/authorized_keys will put rules to be root on that computer, but not munja

3/ then you tried

ssh root@192.168.1.101

Here you said: "hello i'm someone on another computer and i wish to be root here"

Answer from 192.168.1.101 was "let me check, hmmmm, no someone is allow to access root here sorry"

4/ and then

root>ssh root@192.168.1.101

Here : "hello this time i'm root, still on the other computer and i wish to be root here"

Answer from 192.168.1.101 was "let me check, hmmm, ok i know who you are, you can then.... wait no sorry, root isn't welcome here"

Because your sshd is configure with PermitRootLogin no  anyone that wish be root is just not welcome, even having the good phrase or not.

What you should do is:

On client computer for every account you wish to use to access the other computer

Login as that user and create your id_rsa key

To just let this stay simple i will use root and bob as example

You've already do that for root, so it's ok for that part

for bob it's the same, login as bob and redo the key creation as you made it with root

Now the server computer (still with no root login allowed, that's a nice idea to keep it as-is)

So in order to have bob or root access munja

You go to /home/munja/.ssh

and do cat the_root_keyfile.pub >> authorized_keys

and do cat the_bob_keyfile.pub >> authorized_keys

Doing that, you just said: "if root or bob wish to access munja, we will be ok if the key are good"

and you can even do that easy without moving keys on usb...

on your client computer, just create the wanted file

(do that as root)

```
cd /root/.ssh

cat id_rsa.pub > /tmp/keytmp

cat /home/bob/.ssh/id_rsa.pub >> /tmp/keytmp

scp /tmp/keytmp munja@192.168.1.101:/home/munja/.ssh

(here the password you need to enter is munja password, not the password for the ssh key but the one you use to login as munja)

ssh munja@192.168.1.1

(munja password again)

cd /home/munja/.ssh

mv keytmp authorized_keys

chown munja:munjagroup authorized_keys

chmod 0600 authorized_keys

```

----------

## cach0rr0

just to summarize that:

-on the client you run ssh-keygen, which will generate a private/public key pair (private = /home/youruser/.ssh/id_dsa, public = /home/youruser/.ssh/id_dsa.pub

-on the client, do cat /home/youruser/.ssh/id_dsa.pub, and copy this text

-on the destination server, authorized_keys does not exist by default. so you vi /root/.ssh/authorized_keys, paste in what you copied above. 

what that does is tell SSH on the destination server, that someone presenting what you have in /home/youruser/.ssh/id_dsa.pub on the client machine, is authorized to login as root

if you were to copy /home/youruser/.ssh/id_dsa.pub from the client machine, and on the remote server paste it into /home/someuser/.ssh/authorized_keys, it would tell that remote server that someone presenting id_dsa.pub to it should be allowed to login as someuser

For example, I used ssh-keygen to make this key on my home machine:

```

$ cat /home/meat/.ssh/id_dsa.pub 

ssh-dss A<SNIPPED>Xg== meat@gw.local

```

I would then login to to a remote server (call it 'bauer' )as root, vi /root/.ssh/authorized_keys, and paste that key in. 

That would let me login as root. 

To login as root, from my machine at home, I would

ssh -i ~/.ssh/id_dsa root@bauer

This document explains it in detail: http://www.gentoo.org/doc/en/articles/openssh-key-management-p1.xml

----------

## while true

Ola krinn,

by now you have a beer every time we see!!!

Yes, I confused who is who, and on top of that I was working as root with NO-ROOT-ACCESS, kheh.

I must say it is much simpler than I thought, but you know when feared we have big eyes..

So I went with no root, just users with root privileges.

It is working nicely so far. csp also works, so I have what I need.

- - - - - - - - - - - - - - - - - - - - 

if I may repeat my question,

How high is my zipper on my kevlar vest?

- - - - - - - - - - - - - - - - - - - - 

oh, and one last thing!

during this discussion, couple of people said that log file showed snif, or attempt to log in...

or something in that line...

I have syslog-ng, how can I check what is written there?

I looked around (on internet and my gentoo) but found nothing of use?

How can I check that out?

Thank you.

EDIT:

ola cach0rr0,

yes, first I managed to screw id_rsa instead of id_rsa.pub

(I have RSA, not DSA)

than in sshd_config I have set RootLogin to no,

and I made keys as root, so no go there.

As I made keys as user than it worked nicely, kheh.

----------

## krinn

 *while true wrote:*   

> 
> 
> - - - - - - - - - - - - - - - - - - - - 
> 
> if I may repeat my question,
> ...

 

Depend, if you have keep your wireless on, middle i would say

If you have your wireless with WEP, he will need 30s to enter

If you have your wireless with WPA he will need 5 minutes to enter

If you have MAC filtering he will need to wait your client speaking

As-is your server ssh is accepting anyone from your network to try to access it on port 22 with password login enable.

Now that he is on your network, he will be allow to try to access your server, your server will just ask the user and password.

If he try root, hopefully you have disable that.

He could just try random user until he will find munja, next step is to find munja password as you're allowing login with munja password.

I would say, not something a random person passing next to you would try, but for a neighborg it's doable (still if he wish to break in, he might just stop when he access the network to get internet)

And if he know you a bit, he might just guess already "munja", and might guess your password too if it's a weak one (lol, don't use your girlfriend name as password!)

And if he read that forum, you're in underpant  :Smile: 

But don't be scared, security doesn't depend on your strengh to secure something, it depend on the attacker strengh.

You can harden as strong as you wish, as long as someone can try a door, if he is skilled enough he will enter.

I mean you can be the NSA, if someone from the CIA wish to break in, he will, because admin fill holes while attackers discover them. Attacker will always have a step forward on that battle.

----------

## depontius

 *krinn wrote:*   

> 
> 
> If you have your wireless with WPA he will need 5 minutes to enter
> 
> If you have MAC filtering he will need to wait your client speaking
> ...

 

The crack against WPA is dictionary-based.  Use a good non-dictionary password/passphrase >> 10 characters, and you're safe, for the current state of the art.  Since the crack is dictionary based, a "good" and "large" password/passphrase I would think can be considered safe.  A few years back when I set up my WRT54G, I used pwsafe to generate a 63-character pseudorandom string.

Another thing...  The WPA crack generally uses precalculated "rainbow tables" based on the dictionary plus your SSID.  The rainbow tables take much longer to generate than the crack itself.  You could occasionally change your SSID, invalidating whatever rainbow tables have been generated for you.

As you say, but weren't explicit with, MAC filtering won't stop anyone for long.  Sniff some traffic, get the MAC, spoof the MAC.

----------

## Etal

I'm a bit confused... Aren't we talking about SSH with public key authentication, not wireless security?

If the only port open on your machines is the SSH port, with 1024-bit DSA, aren't you pretty secure?

----------

## cach0rr0

 *AM088 wrote:*   

> I'm a bit confused... Aren't we talking about SSH with public key authentication, not wireless security?
> 
> If the only port open on your machines is the SSH port, with 1024-bit DSA, aren't you pretty secure?

 

There's a concern for him with overall security footprint because there is a wireless conduit into his network (with the 8 thousand routers he has in his setup)

I think that's why wireless crypt is coming into play.

----------

## cach0rr0

 *while true wrote:*   

> 
> 
> - - - - - - - - - - - - - - - - - - - - 
> 
> if I may repeat my question,
> ...

 

As far as ssh goes, if you're only allowing key-based authentication, and not allowing user/pass auth at all (as you would if you use the config I posted above), short of a flaw in the SSH daemon itself, they're not getting in - and if there's a flaw that's remotely exploitable for giving root, it won't much matter what sort of auth you use, as they don't have to attack the auth at all

NOW...even if someone does manage to break into your wireless network, assuming you only allow key-based auth for SSH, they're still not really going to have any chance of getting onto your sshd, because that same pitfall of them not having the public key/private key pair. 

So to that end, if ssh is the *only* service you're exposing to the outside world, you're pretty damn safe. 

Just understand that as you expose more and more services beyond sshd, you have to worry about tightening them down as well, because who knows - someone attacks $somedaemon, executes arbitrary code, successfully sets up a bindshell, so on and so forth.

----------

## while true

Ola,

I don't have samba (I unmerged that)

but I do have vnc viewer, but I am thinking of unmerging it.

what are other services that expose to outside?

I guess I can persuade room-mate that we change SSID every couple of months.

After this I will be quite safe...

The thing this thread got a bit wide is, 

that I am a newbie, and I have so many questions, 

so I apologize for that.

a lot of people answering me here said something about logs...

How can I check my logs?

I use syslog-ng.

Thank you.

----------

## cach0rr0

 *while true wrote:*   

> Ola,
> 
> I don't have samba (I unmerged that)
> 
> but I do have vnc viewer, but I am thinking of unmerging it.
> ...

 

Only the ones you decide to expose. VNC can be tunneled through SSH, it's not really a risk to have it running so long as you're not exposing that port to the outside world. If you are, that's yet another attack vector. 

 *while true wrote:*   

> 
> 
> I guess I can persuade room-mate that we change SSID every couple of months.
> 
> 

 

Unnecessary. ESSID (commonly just 'ssid')just isn't really useful for any attacks against your wireless network. The MAC address is what one typically uses with the likes of aircrack, and even if you decide not to even broadcast the essid, your network will be found. 

Having your essid does not really benefit an attacker in any way. Now, having said that, one common attack against users, but not against a wireless network, is for someone to set up a fake wireless access point, and set the access point to 'spoof' your essid. This doesn't get them access to your network, but if a user unknowingly connects to this wireless network, and starts sending data, the user may have potentially inadvertently given this fake AP info that could be used to compromise you. Unfortunately, changing your essid will not protect against this - nothing will except for user vigilance. 

MAC filtering is also mostly useless, since that can be spoofed. 

If there were something that would be worthwhile to change periodically, it would be your passphrase for connecting to the network. 

 *while true wrote:*   

> 
> 
> After this I will be quite safe...
> 
> 

 

The big thing is to know what attack vectors you're leaving open. 

If the only service you expose to the outside world is SSH, and your wireless network is WPA2, you should be more than sufficiently safe. 

If you're unsure what's being exposed to the outside world? Check out nmap. Pull nmap down on one of your laptops, take it to a friend's network, and:

```
nmap -sV -P0 -vv x.x.x.x
```

 where x.x.x.x is your public IP address. It -sV will attempt to do a full TCP connection to any listening ports, and try to determine versions of running services. If you don't care about versions of running services, just use -sT

People overstate the risks of TKIP vs AES. You're still looking at a dictionary attack with TKIP. It's still horribly inefficient, and not quick in the least. 

Run WPA2, dont expose anything but SSH, and allow ONLY key-based auth for SSH, and you should be good to go. Just don't do something silly and let one of your laptops/desktops become infected, because once something on your internal network is infected, all bets are off  :Smile: 

 *while true wrote:*   

> 
> 
> a lot of people answering me here said something about logs...
> 
> How can I check my logs?
> ...

 

Loads of fun information in /var/log

Most things will be in /var/log/messages unless you're running hardened (hardened separates things out quite nicely). dmesg output is also useful. 

That should get you started. Questions? Ask away!

----------

## while true

Hello,

khehm yes, I do have a follow up questions,

two more:

First, how can I tunnel vnc over ssh?

I want to be able to connect from maint to side computer,

(to watch side computer on main computer)

and also in opposite direction, from side to main computer

(to watch main computer on side computer).

So far, I can watch side computer on main, since it is found via Avahi.

but on side computer there is no list of main computer in Avahi, only itself(?!?)

I tried suggested line that I found via search engines,

but this does not work:

```
grom@C6820s ~ $ ssh -L 50000:grom@192.168.1.100:50000 -N -f -l munja munja@192.168.1.101

Enter passphrase for key: 

grom@C6820s ~ $ 

grom@C6820s ~ $ ssh -L 50001:192.168.1.100:50001 -N -f -l munja 192.168.1.101

Enter passphrase for key: 

grom@C6820s ~ $ 

grom@C6820s ~ $ ssh -L 50002:192.168.1.100:50002 -N -f -l munja munja@192.168.1.101

Enter passphrase for key: 

grom@C6820s ~ $
```

So this all establishes connection, I guess.

It does not matter what I run through it?

If this is correct, how can I set vnc to go through that port?

Also, can I use port 22, that is already running ssh?

So I tried this, none worked:

```
grom@C6820s ~ $ vncserver :50000 -geometry 800x600 -depth 16

-bash: vncserver: command not found

grom@C6820s ~ $ vncviewer :50000 -geometry 800x600 -depth 16

channel 2: open failed: administratively prohibited: open failed

vncviewer: VNC server closed connection

grom@C6820s ~ $ vncviewer :50000 -geometry 800x600 -depth 16          

channel 2: open failed: administratively prohibited: open failed

vncviewer: VNC server closed connection

grom@C6820s ~ $ vncserver :50000 -geometry 800x600 -depth 16

-bash: vncserver: command not found

grom@C6820s ~ $ vncviewer 192.168.1.100:50001 -geometry 800x600 -depth 16

vncviewer: ConnectToTcpAddr: connect: Connection refused

Unable to connect to VNC server

grom@C6820s ~ $ vncviewer 192.168.1.101:50001 -geometry 800x600 -depth 16

vncviewer: ConnectToTcpAddr: connect: Connection refused

Unable to connect to VNC server

grom@C6820s ~ $ vncviewer 127.0.0.1:50002 -geometry 800x600 -depth 16

channel 2: open failed: connect failed: Connection refused

vncviewer: VNC server closed connection

grom@C6820s ~ $
```

And second question:

Is there a gui for iptables?

If I understand correctly, 

I can close all ports, 

and open just the ones that I need, when I need?

This would further harden my Gentoo?

Thank you

----------

