# OpenSSH starting but not listening on any port

## Syzygy

I set up OpenSSH per the Security Handbook, using RSA key authentication and a config file pretty much exactly as shown in the handbook.  It worked fine, was able to ssh into my user account and do whatever.  Then I changed my USE flags, so I re-emerged my entire world, and now ssh is giving me "connection refused" every time I try to connect.

The sshd logs used to say "Cannot bind to any address," but then I completely unmerged OpenSSH and recompiled and reinstalled it, with a fresh config file.  Now the logs claim sshd starts up fine, and I can see the daemon in ps, but netstat shows no program listening on port 22.

No software firewall, router is set to forward port 22 to my box.  ListenAddress is 127.0.0.1, PAM disabled, root login disabled, RSA authentication required.  Any help or ideas on what to do would be greatly appreciated.  Thanks!

P.S. Was careful to differentiate between ssh (client) and sshd (server) in my description.

----------

## Deepak420

Please post your sshd config and your new USE flags.

----------

## think4urs11

 *Syzygy wrote:*   

> ... ListenAddress is 127.0.0.1 ...

 

Sure? With that setting only connections from localhost should be possible at all but not from anywhere 'outside' your machine. Use your LAN address instead.

----------

## Syzygy

Changing the ListenAddress to my LAN IP gets me a step further.  Now ssh claims "Permission denied (publickey,keyboard-interactive)." when I log in as a non-root user in the wheel group.  (I'll admit the Security Handbook is very secure by suggesting 127.0.0.1, at least...)

The only change I made to my USE flag was adding march=pentium3 instead of march=i686.

My sshd config:

 *Quote:*   

> 
> 
> Protocol 2
> 
> ListenAddress 192.168.0.3
> ...

 

Can someone verify that this config is appropriate for an RSA verification setup?

(Side note -- I want to be able to SSH from anywhere in the Internet -- should I set my ListenAddress to my FQDN in that case?  Or my WAN IP?)

----------

## rex123

Best to comment out the listen address, then you will have ssh listening on all interfaces, which will at least remove one potential cause of problems. If you are behind a router doing NAT, ssh will need to be listening at least on the address of the interface connected to the router, and the router will need to forward tcp requests on the ssh port to your gentoo machine. It looks like you've got that set up already, so you should be fine.

The change in your USE flag looks like a change to CFLAGS (not USE), so it shouldn't do anything to ssh or sshd at all. It must be a configuration problem that you are having. You could try setting UsePAM to yes (which should allow you to use your username/password), or try using an authorized RSA key.

What do you get if you do verbose ssh (ssh -vvv)?

----------

## Syzygy

You're right, I meant CFLAGS.  :Rolling Eyes: 

After commenting out ListenAddress, the following is my über-verbose ssh output:

 *Quote:*   

> 
> 
> OpenSSH_3.8.1p1, OpenSSL 0.9.7b 10 Apr 2003
> 
> debug1: Reading configuration data /etc/ssh_config
> ...

 

----------

## rex123

Well, it seems that your problem is this:

- none of your identities (/Users/tmorgan/.ssh/identity, /Users/tmorgan/.ssh/id_rsa, /Users/tmorgan/.ssh/id_dsa) are in the authorized_keys2 file on the server, so publickey authentication is failing.

- keyboard-interactive is not working, because you haven't set UsePAM yes. I'm a little hazy about this, but it seems that in the config file, setting "ChallengeResponseAuthentication yes" (which is the default) doesn't actually do anything unless you also specify more information. UsePAM is the normal one.

- password authentication, which would probably work, has been disabled.

So your options are (as far as I can see):

- manually enter a correct public key in the appropriate authorized_keys2 file

- set UsePAM to yes

- enable password authentication

----------

## Syzygy

Alright.  The most secure solution would be to create this authorized_keys file (as none exists in my home folder).  I'm a little hazy on the whole RSA/DSA thingamajig, so I'm not sure what to do.  I have one user account on my server (named tmorgan) that I'd like to ssh into from my client (with a user name that also happens to be tmorgan).  Per the Gentoo handbook instructions, I used ssh-keygen to generate a key on the server tmorgan account, which went into ~/.ssh

So, what do I have to do on the client and the server for them to trust each other?

----------

## jamapii

 *Syzygy wrote:*   

> So, what do I have to do on the client and the server for them to trust each other?

 

The client's public key (it is in .ssh/id_dsa.pub or similar) goes into the server's .ssh/authorized_keys.

Enable password authentication (temporarily) in /etc/ssh/sshd_config on the server to make an initial connection possible. "/etc/init.d/sshd restart" to apply the changes.

----------

## Syzygy

So I used ssh-keygen on my client machine to create a key.  Just to be safe, I created an RSA, DSA, and RSA1 key (id_rsa.pub, id_dsa.pub, and identity.pub, respectively).  I scp'd those .pub files to the server, and merged them together to make a new authorized_keys file:

cat *.pub > authorized_keys

which I placed in ~/.ssh/ of my root account.  I restarted ssh, and got the same error, albeit with different verbose output:

 *Quote:*   

> OpenSSH_3.8.1p1, OpenSSL 0.9.7b 10 Apr 2003
> 
> debug1: Reading configuration data /etc/ssh_config
> 
> debug2: ssh_connect: needpriv 0
> ...

 

My two guesses ... it seems that OpenSSH expects a key of type RSA1, but nowhere is it checking identity.pub, only id_rsa.pub and id_dsa.pub on the client machine.

Alternatively, perhaps I have the format of the authorized_keys file wrong.  Is there documentation on how to properly format such a file?

----------

## rex123

 *Syzygy wrote:*   

> Just to be safe, I created an RSA, DSA, and RSA1 key (id_rsa.pub, id_dsa.pub, and identity.pub, respectively). 
> 
> 

 You should be fine with just an rsa key... *Syzygy wrote:*   

> I scp'd those .pub files to the server
> 
> 

 How? scp uses ssh, doesn't it? Or was that with normal password access on? *Syzygy wrote:*   

> [...]
> 
>  *Quote:*   [...]
> 
> debug1: identity file /Users/tmorgan/.ssh/id_rsa type 1 
> ...

 I agree. The reason is (I'm fairly sure) that your sshd config has only ssh protocol 2 in use *Syzygy wrote:*   

> 
> 
> Alternatively, perhaps I have the format of the authorized_keys file wrong.  Is there documentation on how to properly format such a file?

 

man sshd has this information. Basically, it should look something like this:

```
ssh-rsa AAAA...[lots of characters, but no line break]...ofw== comment about key 1

ssh-rsa AAAAB3...[lots of characters, but no line break]...TOJI2aGZpdk= comment about key 2

ssh-rsa AAAAB3Nza...[lots of characters, but no line break]...wiHrOtZBguQ== comment about key 3
```

There's more you can do (fields before the start of the actual public key), but that should get you going.

----------

## robdd

Hi there.  I wasted quite a few hours trying to get sshd working on my home server. Left it for a couple of days, and bingo, it worked first go. So here's what I did.

But first, I strongly recommend that you set your ssh server up to ONLY accept private key authentication.  If you google for 'ssh brute force attacks' you'll see that there are constant attacks on ssh servers using a dictionary of user names and passwords.  If you don't accept passwords at all then you can't be compromised (except for something like a buffer overflow exploit, so you'll need to watch for patches to ssh).

First here's my complete sshd_config, set up to only accept private key authentication:

```

#   $OpenBSD: sshd_config,v 1.65 2003/08/28 12:54:34 markus Exp $

# This is the sshd server system-wide configuration file.  See

# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with

# OpenSSH is to specify options with their default value where

# possible, but leave them commented.  Uncommented options change a

# default value.

#Port 22

#Protocol 2,1

#ListenAddress 0.0.0.0

#ListenAddress ::

# HostKey for protocol version 1

#HostKey /etc/ssh/ssh_host_key

# HostKeys for protocol version 2

#HostKey /etc/ssh/ssh_host_rsa_key

#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key

#KeyRegenerationInterval 1h

#ServerKeyBits 768

# Logging

#obsoletes QuietMode and FascistLogging

SyslogFacility AUTH

LogLevel VERBOSE

# Authentication:

#LoginGraceTime 2m

#PermitRootLogin yes

#StrictModes yes

#RSAAuthentication yes

#PubkeyAuthentication yes

#AuthorizedKeysFile   .ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts

#RhostsRSAAuthentication no

# similar for protocol version 2

#HostbasedAuthentication no

# Change to yes if you don't trust ~/.ssh/known_hosts for

# RhostsRSAAuthentication and HostbasedAuthentication

#IgnoreUserKnownHosts no

# Don't read the user's ~/.rhosts and ~/.shosts files

#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!

PasswordAuthentication no

#PermitEmptyPasswords no

# Change to no to disable s/key passwords

#ChallengeResponseAuthentication yes

# Kerberos options

#KerberosAuthentication no

#KerberosOrLocalPasswd yes

#KerberosTicketCleanup yes

# GSSAPI options

#GSSAPIAuthentication no

#GSSAPICleanupCreds yes

# Set this to 'yes' to enable PAM authentication (via challenge-response)

# and session processing. Depending on your PAM configuration, this may

# bypass the setting of 'PasswordAuthentication'

#UsePAM yes

#AllowTcpForwarding yes

#GatewayPorts no

#X11Forwarding no

#X11DisplayOffset 10

#X11UseLocalhost yes

#PrintMotd yes

#PrintLastLog yes

#KeepAlive yes

#UseLogin no

#UsePrivilegeSeparation yes

#PermitUserEnvironment no

#Compression yes

#ClientAliveInterval 0

#ClientAliveCountMax 3

#UseDNS yes

#PidFile /var/run/sshd.pid

#MaxStartups 10

# no default banner path

Banner /etc/ssh/ssh_banner

# override default of no subsystems

Subsystem   sftp   /usr/lib/misc/sftp-server

```

Next, I ran 'ssh-keygen -t dsa' on my ssh server, and saved the public and private key files in my home/.ssh directory (the default).

Then I copied the public key to authorized_keys2, still in the .ssh directory - 'cp id_dsa.pub authorized_keys2' (make sure the spelling is right - that's one thing I got wrong !)

Next I copied the private key file to  home/.ssh on my client machine.

Finally I started the ssh daemon - you can start it automatically at boot by typing 'rc-update add sshd default'

Now you should be able to type 'ssh your-server-name' from your client, and log straight in.  :Smile: 

The truly paranoid might specify a passphrase, but you're only at risk if someone hacks into your client machine and copies your private key - then they have immediate access to your server too.

Good Luck !

BTW, I'm on 2.6.11-gentoo-r11, and using openssh-3.9_p1-r2

----------

## jamapii

 *robdd wrote:*   

> If you google for 'ssh brute force attacks' you'll see that there are constant attacks on ssh servers using a dictionary of user names and passwords.

 

They seem to only try a few passwords per user, so if you need password auth, use something like x674WBSBh as a password.

 *Quote:*   

> Then I copied the public key to authorized_keys2, still in the .ssh directory - 'cp id_dsa.pub authorized_keys2' (make sure the spelling is right - that's one thing I got wrong !)

 

Yes, with the filename authorized_keys2 it should work I think.

----------

## robdd

 *Quote:*   

> jamapii wrote
> 
> They seem to only try a few passwords per user, so if you need password auth, use something like x674WBSBh as a password. 
> 
> 

 

Yes, but if you are only relying on passwords then your security is only as good as your weakest password. Let's say that months after enabling ssh/passwords you download and install some lame package that creates a user test with password test - and you don't notice. Then, bingo, you're vulnerable.  Now there's nothing on my home server that's very interesting  :Smile:   bit it would be a pain to have to re-build it after being compromised.

And you might be surprised at the number of user names being tried by these automated hack attempts - I looked at our office ssh logs yesterday, and one compromised host that was attacking us sent hundreds of user names. Of course the attackers have all day ( and all night !) to hack away - doesn't cost them a cent.

----------

## jamapii

 *robdd wrote:*   

> Let's say that months after enabling ssh/passwords you download and install some lame package that creates a user test with password test - and you don't notice. Then, bingo, you're vulnerable.

 

... and set AllowUsers in /etc/ssh/sshd_config. And don't allow "Allowed users" to have any weak passwords. (AllowUsers restricts ssh access completely, not only for password auth)

----------

## Syzygy

Rob, our config files now match almost exactly.  I followed the steps you gave me and get this:

 *Quote:*   

> OpenSSH_3.8.1p1, OpenSSL 0.9.7b 10 Apr 2003
> 
> debug1: Reading configuration data /etc/ssh_config
> 
> debug2: ssh_connect: needpriv 0
> ...

 

----------

