sshd configuration help

yavorpap · 04-04-2009, 06:54 PM

I actually have two questions:
#1: how can I make sshd take username/password information from a database rather than the actual Linux users or a file and
#2: is there a way to reroute all commands sent through ssh so that when the user writes "X" as a command in the shell the action done on the server to be "command_handler -command X" or something like it.
As you might have guessed I want to make sshd to work as a server that only pretends to do the commands sent rather than actually doing them.
I have read that it is possible to make a command execute differently by "alias"-ing it in the shell rc file, but how can that be done to all commands?
Last, sorry if I have posted in the wrong category, I'm new here.
Thanks a lot.

saman007uk · 04-05-2009, 07:10 AM

Quote:

#2: is there a way to reroute all commands sent through ssh so that when the user writes "X" as a command in the shell the action done on the server to be "command_handler -command X" or something like it.
As you might have guessed I want to make sshd to work as a server that only pretends to do the commands sent rather than actually doing them.

Write a script/program that takes in user commands, but doesn't do anything. Then make that the shell for those users.

tronayne · 04-05-2009, 07:50 AM

When you generate the public and private key information with ssh-keygen they're stored in your home directory's .ssh sub-directory; those are your "data base." A user on a different server would do the same thing, generating pubic and private keys on a remote machine. Let's say that both you and the other user generated keys with the default RSA authentication so there would be, on both machines, id_rsa and id_rsa.pub files in the ${HOME}/.ssh directories.

The remote user would connect to your server with

Code:

ssh -l username servername

and would be prompted for a password and logged in on your machine as "username."

Now, how to avoid that is pretty simple but is a little confusing the first time out. What you do is copy the id_rsa.pub file from the remove machine to your machine's ${HOME}/.ssh directory to a file named authorized_keys (you can do this with scp)

Code:

cd .ssh
scp remote:/home/.ssh/id_rsa.pub remote
cat remote >> authorized_keys

You use "remote" (the name of the server) so you don't overwrite your own id_rsa.pub file (and if you've got a bunch of remote servers to do, it's handy to have the public files in server-named files so you don't lose track).

You do the same thing on the remote machine, copying "your" id_rsa.pub file to it and adding that to the authorized_keys file there. Do not copy the id_rsa private key file to any other machine; keys are generated on the server for that sever.

Once you've done that, "you" and "remote" can connect without a password prompt.

Repeat the above for every remote server; i.e., "their" id_rsa.pub file copied into "your" authorized_keys file, "your" id_rsa.pub file copied to "their" authorized_keys file.

You can take things one step further if you create a config file in the .ssh directories. Let's say that my machine, fubar, connects to a remote machine, snafu, and I want to run applications on snafu. My config file would look like this

Code:

Host snauf
ForwardX11 yes
Compression yes
Protocol 2,1
User my-user-name

Host *
ForwardX11 no

and, the revers on snafu to get to my machine. Once this done, a remote user simply enters

Code:

ssh fubar

and is connected as "User" (which, of course, does not have to be their log id on their machine, but does have to be the id on this machine).

You might take a look at http://www.linuxjournal.com/article/6602 for some additional information and explanation that may be useful.

Hope this helps some.

yavorpap · 04-05-2009, 04:31 PM

Thanks for the replies