ssh - listing of authorized_keys file

[S.Rider]

Is there a way to list the other servers that can ssh into a server. I was hoping there was a command that would check the local authorized_keys file (which is actually called id_dsa.pub here for strange & wonderfull reasons) and give me a list of the other servers that can ssh to this guy without a password ?
I see that most of the lines in "authorized_keys" end in "root@servername" but not all. Some end in just "root" and some have no eyecatcher at the end.

[Tim Nelson]

Each user should have a .ssh directory in their $HOME. In that an authorized_keys directory.

At the end of each key is the username@host of the allowed remotes.

[blah2blah]

well it isn't all that easy, because there are so many ways to use ssh and it all depends on how your using ssh.

the easy answer is to check the knownhosts files in etc and the users home directory(ies). of course, you could not be using the known hosts files, not very wise to do but you can.

and that will only tell you which clients have connected, not which one could.

your sshd could be complied to use other files as the default. the defaults could be overridden by commandline options, or keyword values, etc, etc.

while the authorized keys might end with a user@server, remember the file is editable by the user. so there is no gaurantee that is correct.

your logging (you are doing that aren't you) should tell you where users have logged in from.

of course, with port forwarding, they might really be logging in from a different client

who can can loggin without a password all depends on how you have the authentication setup. if password authentication isn't required then anyone can loggin using the other authentication methods that you allow, public key, etc.

[Bill Hassell · Accepted solution]

A bit of clarification: id_***.pub is not the authorized keys. They are totally different files. The files such as id_rsa.pub and id_dsa.pub are the public keys generated on this local computer. Typically, you would append this key to the end of the authorized_keys file on the remote system, thus enabling the authorization of the local computer to the remote computer.

So the lines in authorized_keys do indeed tell what computer is allowed to communicate use ssh to this local system, but it is up to the remote computer's keygen program to create the ending string. So some of the remote computers are not generating the optional user@host string.

[S.Rider]

Bill, actually in this case the "id_dsa.pub" is what people normally refer to as the "authorized_keys" file. In sshd_config, "AuthorizedKeysFile = .ssh/id_dsa.pub". It's a setup forced by some 3rd party software the customer purchased a while ago.

All, I ended up pulling the 3rd parm off the lines in root's id_dsa.pub file to get the list of what other servers can ssh in.

I have some lines with just "root" at the end, not "root@hostname".

[Matti_Kurkela]

Sounds like that 3rd party application is being used to manage SSH keys, and the program apparently might require that each managed account can ssh to itself. The strange configuration requirement is a way to make sure that happens by default.

Anyway, the "root@servername" or whatever at the _end_ of the key line is just a comment: it has no meaning at all in determining whether the access is allowed or not, or where the connection is coming from. The private keys can be grabbed from one host and used on another host. If this is done, the comment(s) on the public key(s) on the target server will no longer be up to date. So the best you can do is get some information on where the corresponding private key may have been generated.

Furthermore, anyone handling the public key is free to edit the comment field at will - so if someone wants to put false or incomplete information to the comment field, nothing prevents him/her from doing so.

With SSH keys, unless specified otherwise, the identity of the client host is considered unimportant as long as the proper key is presented. You'll need to examine your firewalls and other forms of access restriction, otherwise all the hosts on the Internet will be on your list of "other servers that can possibly connect to this server".

You can use the 'from="pattern-list"' syntax in authorized_keys file to enforce a limited set of hosts from which a connection is accepted. This list is specified separately for each key, so each key can have a different list of accepted hostname patterns. Options like these go on the _beginning_ of the public key lines in the authorized_keys file. See "man sshd" and read the "AUTHORIZED_KEYS FILE FORMAT" chapter for more information.

If there are no firewalls, it's perfectly possible to snatch a SSH private key from one of your servers, feed it to a SSH client on a BlackBerry and use it to connect from the other side of the country.

If a traditional physical key is lost (or you lose track of people who have a key that fits a particular lock), you'll have to change the lock in case someone malicious now has the key and attempts to use it. If you have a SSH public key in the authorized_keys file and you don't know who has the corresponding private key, you should treat it much the same way.

MK

[Ralph Grothe]

I am not sure if this is of any help.

If you run a pretty recent version of SSH its ssh-keygen utility's list option can be somewhat exploited if directed at the users' authorized_keys files instead of public keys files.
Some versions may print the fingerprints of each entry along with the comment that usually contains the ssh client's source address.
But this is by far not guaranteed to work,
especially as comments are more or less optional as well as their contents.

e.g.

# awk -F: '{print$6}' /etc/passwd|while read home;do ak=$home/.ssh/authorized_keys;[ -f $ak -a -s $ak ] && ssh-keygen -l -f $ak;done

This could print an easily parseable list of fingerprints.

Anyway, you could use a similar loop and parse the users' authorized keys files instead directly for the trailing comments in each key's line.
This would only mean slightly more effort,
but is also not fool proof.

[Steven E. Protter]

Shalom,

Several ideas come to mind.

1)TCP Wrappers. Limit by hostname or IP address. Can be problematic in a DHCP environment.

2) Key only login for root. You can set up ssh to only permit root login if a public key has been placed. id_dsa.pub as authorized_keys. This disables interactive ssh login. I do this on Internet exposed servers. I also leave console login enabled so if there is a problem I can get in via the back door.


< #PermitRootLogin yes
---
> #PermitRootLogin no
> PermitRootLogin without-password
42c43
< #PubkeyAuthentication yes
---
> PubkeyAuthentication yes
106a108
>

Thats the diff output between a standard sshd_config file and the internet exposed system.

PermitRootLogin without-password

You will note that we tried to block root login altogether but this stopped automated file transfer between the secure network and this system which sits in a DMZ

SEP

[Ralph Grothe]

I had similar concerns as SEP with regard to a DMZ cluster.
Between cluster nodes root logins should still be permitted for automated cluster maintenance (sw distribution, job scheduling, monitoring etc.)
So obviously, no matter how sensible in such a hostile environment usually, PermitRootLogins No obviously was too restrictive.
So I used the AllowUsers directive in sshd_config with an exact list of users and the hosts they come from to restrict ssh logins altogether.
Apart from that the DMZ firewalls should drop all TCP frames to the sshd's listening port which don't originate from legitimate source addresses or belong to established or related connections.
Added to this fencing the bastion host itself
could run a packet filter.
Also, one could have several sshd listening that bind to different IP addresses.
As clusters usually have private inter connect networks for exchange of heartbeat packets one could PermitRootLogins only to the sshd instance that bound to the IC IP,
and PermitRootLogins No to the second sshd that bound to the node's IP.

[Steven E. Protter]

Shalom,

http://www.hpux.ws/?p=19

Better explanation than my post.

Yes the flipping website is back up. Got to be careful not to reassing ownership to mysql database files.

DOH!

SEP