.ssh and authorized_keys file

[stevenriz]

I know this is used to obtain to a linux machine without the password as loong as you have the key. My question is this. What is the best way to remove this type of authentication? Would I simply just delete this directory alltogether? We are currently using iptables as the primary firewall with our IP addresses configured and SSH/SFTP for access. Anyone know how best to cease authorized_keys?

 

[dbase77]

Hi,

which protocol version are you running? try check option in sshd_config:

PubkeyAuthentication - set to no.
AuthorizedKeysFile - uncomment this line.

dbase77

 

[stevenriz]

this is the entire file here.... Everything looks commented out, no?

[root]# more ssh_config
# $OpenBSD: ssh_config,v 1.16 2002/07/03 14:21:05 markus Exp $

# This is the ssh client system-wide configuration file. See
# ssh_config(5) for more information. This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
# 1. command line options
# 2. user-specific file
# 3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for various options

# Host *
# ForwardAgent no
# ForwardX11 no
# RhostsAuthentication no
# RhostsRSAAuthentication no
# RSAAuthentication yes
# PasswordAuthentication yes
# HostbasedAuthentication no
# BatchMode no
# CheckHostIP yes
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# Port 22
# Protocol 2,1
# Cipher 3des
# Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes2
56-cbc
# EscapeChar ~
Host *
ForwardX11 yes

 

[ericbrunson]

First, that's your ssh_config, not your sshd_config.

Second, you're disabling the most secure form of authentication that application has and forcing people to use a tedious, less secure method.

 

[stevenriz]

my bad. here is the sshd_config. Can you explain further? All I Want is to shut off this pass phrase way of logging into the box and just use iptables to login using an SSH/SFTP program such as putty and/or filezilla.

++++++++++++++++++++++++++++++++
[root@webs ssh]# more sshd_config
# $OpenBSD: sshd_config,v 1.59 2002/09/25 11:17:16 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/local/bin:/bin:/usr/bin

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

# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
SyslogFacility AUTHPRIV
LogLevel DEBUG3

# Authentication:

#LoginGraceTime 120
#PermitRootLogin yes
#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

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

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# 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 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/libexec/openssh/sftp-server
[root@webs ssh]#

 

[ericbrunson]

You want to completely deny login, but allow sftp? That's better handled through disabling accounts.

 

[stevenriz]

no, I know how to do that, I am interested in simply getting rid of the capability of using the pass phrase login. I ONLY want to be able to login using SSH2 with a username and a password. I think by removing the authorized_keys file might do the trick but am not 100% sure. Does anyone know?

 

[thedaver]

Removing the authorized_keys file is a method of preventing users from using public key authentication to signin to the SSH/SFTP server without manually supplying id/password. However, a user can reinstate the authorized_keys file for themselves after logging in again and replacing the key string in the file in their homedir.

dbase77 said to use
"PubkeyAuthentication - set to no"

That is supposed to disable the use of the public authentication key method. A decision I find very little merit in making, but the solution as supplied should work.

I'm REALLY curious what circumstances or reasons you have in FORCING a username/password entry. Please explain, I know others are curious here.



Hosting Solutions for Home or Business.

http://www.surfinbox.com/hosting/

 

[stevenriz]

Hi, the reason I want to do this is because there is only one group that knows the passphrase and they are reluctant to give it to us. Since they no longer work for the company, I thought it best to 1) remove the file altogether and force a username/password to access the box, we don't mind this and possibly 2) regenerate the key with a different passphrase. So basically it is for security reasons. Do you still suggest I remove this file?

 

[thedaver]

So you trust them with ID/Password but you don't trust them with a key that they can reinstall?

Hosting Solutions for Home or Business.

http://www.surfinbox.com/hosting/

 

[ericbrunson]

Edit the authorized_keys file to remove their public key and generate a new one. It's that simple.

 

[stevenriz]

We changed the passwords so they can't get in that way. Then when they logged in, we had no idea how until they mentioned they had this backdoor way to obtain access with only a passphrase that only they knew. Now I want to shut that down. It is a learning curve for us which we will do BUT we just want to shut this way down immediately. I can edit that file but it is unclear where the key begins and ends, it all looks encrypted to me.

 

[ericbrunson]

Okay, the passphrase is not the key to logging in.

The contents of the authorized_keys file is on half of a key *pair*, this is common in the arena of 'public key cryptography'. You generate a key *pair*, publish one and keep the other secret, hence public and private key.

The *passphrase* is used to encrypt the private key so it can't be read from the file it is stored in. When you are prompted for a passphrase you are decrypting the private key on the local machine so it can me used to authenticate with the remote machine where the public key is stored in the authorized_keys file.

Possession of the private key is what is allowing the users to log in. If remove the corresponding public key from the authorized_keys file, they can't get it.

You can then generate a new keypair using ssh-keygen and put the new public key in the authorized_keys file, and give the private key to whoever needs it. That user can then encrypt the private key using a passphrase that no one else needs to know.

Or, you can just remove the authorized_keys file and *that* will disable PubKeyAuthentication for that account.

Does that clear things up a bit?

 

[stevenriz]

yes that was a great explanation and I thank you very much. So immediately I will remove the authorized_keys file so these guys can't get in anymore and everyone will be forced to use the username/password just like we were doing before. Then at my convenience I will dabble with the key generation etc.... Thanks a lot!!!!

 

[thedaver]

*OR* you can delete the user account from the machine?!!!!!

Hosting Solutions for Home or Business.

http://www.surfinbox.com/hosting/

 

[stevenriz]

So how exactly does this type of authentication work again? Tell me if I'm right. So you generate a key with a passphrase. Is it sort of like setting up WEP on a wireless router? then you you take half of the key in a file and copy it onto the client machine somewhere. Then from within, say, putty, in the SSH section, you will enter the location and name of the key file. Now, when you click "Open" do you just get a linux prompt? There is no other authentication needed? No additional username/password? Nothing? If the key pair is in the /root/.ssh directory then you are root?

 

[ericbrunson]

I don't know how putty handles key management, but using a linux ssh client:

The public key is stored on the remote machine and is *not* encrypted or protected in any way. It doesn't matter who knows it, post it on a website, it doesn't matter.

The private key is stored on any machine you wish to access the remote system from and must be closely guarded, hence the encryption.

To understand how this authentication works you have to understand a fundamental aspect of public key cryptography.
Given a keypair, A1 and A2, if A1 is used to encrypt a message, *only* the key A2 can decrypt it. The key A1 cannot be used to decrypt a message encoded with key A1, you *must* use its complimentary key A2. Conversely A2 encryption must be decrypted with the key A1.

The difference between a public and a private key is simply that one is published and the other is kept secret, other than that, they are interchangable. Also, keypairs can be identified with an ID and that ID does not need to be kept secret.

So, in a simplified form:
When you try to log in to the remote machine, the client tells the server that it would like to try to authenticate using public keys and tells the server the key ID of the key it would like to use. The sshd server process then looks in the authorized keys file to find a public key with that ID, if it doesn't find it, authentication fails.

If it finds a public key with the correct ID, it then generates a random 'challenge' and encrytps it with the public key. The client takes this challenge and uses the private key to decrypt it then re-encrypts it with the private key and sends it back to the server. Remember that the challenge encrypted with the private key looks different than the challenge encrypted with the public key, so you can't just send the same packet back.

The server then uses the public key to decrypt the packet and verifies the contents are indeed the challenge it originally sent and knows that the remote client has the correct private key and allows access, otherwise, authentication fails.

 

[stevenriz]

this is great. So once I remove the files from the .ssh directory do I need to restart any service or is it pretty dynamic to eliminate this type of authentication?

 

[ericbrunson]

Just remove the files and you're done.