# ssh blank passwords shouldn't work but are

## jkcunningham

I'm trying to tightenup security on my Gentoo machines and I noticed that I can ssh into them with a blank password. Yet, I set

```

PermitEmptyPasswords no

```

I am running protocol 2 only, RSAA only, and tried PasswordAuthentication both yes and no. 

Any idea what's wrong? The same configuration on an older version of openssh (SuSE) works as it should. 

-Jeff

----------

## puggy

I remember helping you with rsa ssh a while back. Is it rsa or standard ssh passwords your talking about here. As that setting only effects standard ssh passwords.

And which config file are you talking about?

Puggy

----------

## jkcunningham

Yes, I remember. Thank you. 

I set up rsa keys using "ssh-keygen -t rsa" on two machines, and swapped public keys. When I generated the keys I used an explicit password, and I went into /etc/ssh/sshd_config and changed it as follows:

```

Protocol 2

ListenAddress 127.0.0.1:22

ListenAddress 192.168.1.100:22

#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 3600

ServerKeyBits 768

# Logging

#obsoletes QuietMode and FascistLogging

SyslogFacility AUTH

LogLevel INFO

# Authentication:

LoginGraceTime 120

PermitRootLogin no

StrictModes yes

RSAAuthentication yes

PubkeyAuthentication yes

AuthorizedKeysFile   .ssh/authorized_keys

# rhosts authentication should not be used

#RhostsAuthentication no

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

#IgnoreRhosts yes

# 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

AllowGroups wheel admin

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

PasswordAuthentication yes

PermitEmptyPasswords no

# Change to no to disable s/key passwords

ChallengeResponseAuthentication no

# Kerberos options

#KerberosAuthentication no

#KerberosOrLocalPasswd yes

#KerberosTicketCleanup yes

#AFSTokenPassing no

# Kerberos TGT Passing only works with the AFS kaserver

#KerberosTgtPassing no

# Set this to 'yes' to enable PAM keyboard-interactive authentication 

# Warning: enabling this may bypass the setting of 'PasswordAuthentication'

#PAMAuthenticationViaKbdInt no

X11Forwarding yes

#X11DisplayOffset 10

X11UseLocalhost yes

#PrintMotd yes

#PrintLastLog yes

#KeepAlive yes

#UseLogin no

#UsePrivilegeSeparation yes

#PermitUserEnvironment no

#Compression yes

MaxStartups 10

# no default banner path

#Banner /some/path

#VerifyReverseMapping no

# override default of no subsystems

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

```

I am concerned about having someone set a blank password, which gives anyone access without the receiver knowing. So to test it, I reset the password on one side to a blank password and found that it still works. Someone typing "ssh" from that machine gets in instantly. It seems to me that there ought to be a way to turn that off. 

Regards.

-Jeff[/code]

----------

## Naan Yaar

Empty passwords are not permitted by default.  Did you restart sshd after you changed settings?

Also, this setting is relevant only to password authentication tunneled through ssh.  It does not apply to empty passphrases being used when encrypting private keys for rsa.  

 *jkcunningham wrote:*   

> ...
> 
> I am concerned about having someone set a blank password, which gives anyone access without the receiver knowing. So to test it, I reset the password on one side to a blank password and found that it still works. Someone typing "ssh" from that machine gets in instantly. It seems to me that there ought to be a way to turn that off. 
> 
> Regards.
> ...

 

----------

## jkcunningham

Yes, I restarted sshd. I know it says that blank passwords aren't permitted by default, but in fact they work. Try an experiment on your machine: reset your password (ssh-keygen -p <ret> <ret> <ret> <ret>), restart sshd and see if it doesn't work.

----------

## Naan Yaar

As I said, the setting refers to logging into a box as a user who has a blank password in /etc/shadow.  It does not refer to using blank passphrases in rsa keys.  This passphrase has nothing to do with the server at all and is handled fully at the client end.

 *jkcunningham wrote:*   

> Yes, I restarted sshd. I know it says that blank passwords aren't permitted by default, but in fact they work. Try an experiment on your machine: reset your password (ssh-keygen -p <ret> <ret> <ret> <ret>), restart sshd and see if it doesn't work.

 

----------

## jkcunningham

I understand that. The question remains: is there a way to prevent blank rsa key passwords?

----------

## puggy

 *jkcunningham wrote:*   

> I understand that. The question remains: is there a way to prevent blank rsa key passwords?

 

As far as I'm aware, no.

Puggy

----------

## paranode

But it's not as insecure as it sounds because the person logging in would need access to the private key generated with the blank RSA password.  And they won't have that (or at least they shouldn't!).

----------

## Naan Yaar

Empty passwords are actually neeeded for host keys.  I don't think there is a way to prevent users from specifying empty passphrases unless you modify ssh-keygen source.

 *jkcunningham wrote:*   

> I understand that. The question remains: is there a way to prevent blank rsa key passwords?

 

----------

## puggy

 *Naan Yaar wrote:*   

> Empty passwords are actually neeeded for host keys

 .

What exactly do you mean by that?

 *Quote:*   

> I don't think there is a way to prevent users from specifying empty passphrases unless you modify ssh-keygen source.

 

I don't think it's possible even then seeing as it's the key that has the pass-phrase. It has nothing to do with the ssh connection. Certainly theres no way to do this without modifying the ssh client at the connecting end. You won't be able to do it by hacking ssh server code.

Puggy

----------

## jkcunningham

Thank you, that's the conclusions I had about come to myself. What started me off on this was a comment made by an IT consultant that we needed to make sure blank passwords were disabled. I said I was only allowing rsa keys anyway. He said blank passwords were bad there for the same reason they are bad in PGP encryption. But he definitely implied it there was a way to disallow them by proper configuration. I just couldn't find it. 

-Jeff

----------

## puggy

 *jkcunningham wrote:*   

> Thank you, that's the conclusions I had about come to myself. What started me off on this was a comment made by an IT consultant that we needed to make sure blank passwords were disabled. I said I was only allowing rsa keys anyway. He said blank passwords were bad there for the same reason they are bad in PGP encryption. But he definitely implied it there was a way to disallow them by proper configuration. I just couldn't find it. 
> 
> -Jeff

 

Yeah. This security depends on whoever is responsible for making and maintaining the keys.

Puggy

----------

## ARC2300

If you (or the IT guy) are that hard up about security, just regen the keys every couple of days and then distribute them.   :Confused: 

But just out of curiousity, why use RSA keys??  You can force people to use certain passwords (in terms of what the password must contain), and just use that.  That way you don't have to worry about someone holding a key that could potentially get stolen.  IMHO, disbursing keys is something that is insecure unless the person you're giving them to is highly trustable.  Just wondering, that's all.

And you could probably make a cron job to regen the server's sshd keys so that non-RSA keys must be changed every 2 or 3 days.  Yeah, I know, a pain in the ass, but like I said, I hate giving people something that they HAVE to hold on to and keep secured.  I mean, I go through my server at home and delete the sshd keys and regen them every few weeks even though I know EVERYONE that logs into it (which are about 2 or 3 people).

----------

## puggy

 *ARC2300 wrote:*   

> If you (or the IT guy) are that hard up about security, just regen the keys every couple of days and then distribute them.

 

This is a terrible idea. Better to just use standard ssh passwords or have a policy of pass phrases as mandatory on rsa keys.

And do you always have to post in an annoying colour?

Puggy

----------

## Naan Yaar

Host keys for sshd are generated using a null password (cf. /etc/init.d/sshd, e.g.) using the -N option with a blank argument.  You don't (typically) want human intervention for daemon start up in init files, which is what you would require if you had passphrase protected keys.

 *puggy wrote:*   

>  *Naan Yaar wrote:*   Empty passwords are actually neeeded for host keys .  
> 
> What exactly do you mean by that?
> 
> 

 

The passphrase is certainly not stored in the key; this would be terrible security.  Actually, if you lose your passphrase, there is no way to recover it.  Only check bytes are stored in private keys in order to validate the passphrase.  The private key itself is encrypted by the passphrase.  When you make a connection, the private key is decrypted using the passphrase provided by you.  Also, you could disable null passphrases by modifying ssh-keygen or the ssh client code itself;  I was referring to the former alternative.  As I mentioned earlier, all this has nothing to do with the server which gets to see neither the passphrase nor the private key.

 *Quote:*   

> 
> 
> I don't think it's possible even then seeing as it's the key that has the pass-phrase. It has nothing to do with the ssh connection. Certainly theres no way to do this without modifying the ssh client at the connecting end. You won't be able to do it by hacking ssh server code.
> 
> Puggy

 

----------

## ARC2300

 *Quote:*   

> This is a terrible idea. Better to just use standard ssh passwords or have a policy of pass phrases as mandatory on rsa keys.
> 
> And do you always have to post in an annoying colour?

 

How is this terrible??  If you're changing keys say, two times a week, it's much harder to crack them.  You'll be on a much tighter deadline to crack a key than if you had a whole 7 days to crack one.  All you'd have to do it put it on a SD card or something like that, and whenever the keys change collect them, then hand them back out.  How hard is that??

And knowing the lengths some companies go to for security, there are companies out there that change keys once a day.  One friend's dad has to keep a card that is coded with the same algorithm as the system he logs into, because the keys for him to access that system change every 13 seconds.  

And I was proposing to use standard ssh passwords, however, standard ssh uses keys also, and you can simply delete them, restart sshd, and regen those keys.  

And do you always have to post in a color everyone else does??  I've always gone to the tune of a different band.  There are things people do everywhere that annoy you.  Are you going to ask everyone to stop just to please you?? 

----------

## puggy

 *Naan Yaar wrote:*   

> Host keys for sshd are generated using a null password (cf. /etc/init.d/sshd, e.g.) using the -N option with a blank argument.  You don't (typically) want human intervention for daemon start up in init files, which is what you would require if you had passphrase protected keys.
> 
> 

 

Ah. But it isn't required. I would never do this.

 *Quote:*   

> 
> 
> The passphrase is certainly not stored in the key; this would be terrible security.  Actually, if you lose your passphrase, there is no way to recover it.  Only check bytes are stored in private keys in order to validate the passphrase.  The private key itself is encrypted by the passphrase.  When you make a connection, the private key is decrypted using the passphrase provided by you.  Also, you could disable null passphrases by modifying ssh-keygen or the ssh client code itself;  I was referring to the former alternative.  As I mentioned earlier, all this has nothing to do with the server which gets to see neither the passphrase nor the private key.
> 
> 

 

Isn't that what I just said? Maybe I was slightly ambigous. When I said it "has the passphrase", I meant it was protected by the passphrase.

----------

## puggy

 *ARC2300 wrote:*   

>  *Quote:*   This is a terrible idea. Better to just use standard ssh passwords or have a policy of pass phrases as mandatory on rsa keys.
> 
> And do you always have to post in an annoying colour? 
> 
> How is this terrible??  If you're changing keys say, two times a week, it's much harder to crack them.  You'll be on a much tighter deadline to crack a key than if you had a whole 7 days to crack one.  All you'd have to do it put it on a SD card or something like that, and whenever the keys change collect them, then hand them back out.  How hard is that??
> ...

 

rsa keys are virtually invulnarable to any sort of attack other than compromising the passphrase. Hence distributing keys unprotected by a passphrase will always be less secure than a key with a decent passphrase.

It is true. There are things everywhere that annoy me, and yes, I would have everyone stop doing things to annoy me. Wouldn't everyone? I think so, unless you subscribe to some sort of alturistic philosophy.

----------

## Naan Yaar

"Never do" what?  I assume using a passphrase for host keys?  According to ssh-keygen, host keys must have an empty passphrase.  I don't believe there is a way to specify a passphrase for host keys to sshd.

 *puggy wrote:*   

>  *Naan Yaar wrote:*   Host keys for sshd are generated using a null password...
> 
>  
> 
> Ah. But it isn't required. I would never do this.
> ...

 

I was referring to: as it's the key that has the pass-phrase...

 *Quote:*   

> 
> 
> Isn't that what I just said? Maybe I was slightly ambigous. When I said it "has the passphrase", I meant it was protected by the passphrase.

 

----------

## puggy

 *Naan Yaar wrote:*   

> "Never do" what?  I assume using a passphrase for host keys?  According to ssh-keygen, host keys must have an empty passphrase.  I don't believe there is a way to specify a passphrase for sshd host keys.

 

Ah, host keys. Yes. I thought we were talking about keys for logging in, rather than keys for ensuring the end connection is who we think it is.

I'd never not supply a passphrase on an rsa key

----------

