Need help with SSH/Job Control

[Jason Martens]

Hey all,
I have a script that brings our databases down and up every night for backups, and I want to add some commands to start and stop services that depend on the databases before they come down or come up. I used to do this with RSH, but I'm switching to ssh/private key for security reasons. The problem I'm having is that when I attempt to run the command to stop or start the other service over ssh, the ssh command doesn't exit and just hangs around. Currently my setup looks like this.
Command that gets run from the db up/down scripts:
ssh -i ~/.ssh/somekey_rsa username@localhost

Which corresponds to a .ssh/authorized_keys file like this:
command="/run/some/stuff" ssh-rsa publickeyv39vjwef some@user comments

I've tried adding an & to both the authorized_keys command and to the ssh -i command, but neither seems to help. How can I make sure that the command that gets run from the authorized_keys allows the ssh command to exit?

Thanks,
Jason Martens

[Mel Burslan]

Jason,

I have the same problem showing up intermittently on my interactive ssh login sessions, like when I hit ctrl-D, the session does not end but hangs. When you go back intot he same server, you see the session process hanging with "notty" word attached to it.

As I do not know what version of ssh you are running, I can not suggest you to upgrade right of the bat but my new upgraded version reports this :

# what /usr/sbin/sshd
/usr/sbin/sshd:
$HP-UX Secure Shell: sshd.c,v A.03.81.002 2004/07/02 $

and the frequency of this hangs diminished and on some servers totally disappeared after the upgrade.

Also, as a stopgap measure, I have written a small one line script from my master server like this:

ssh $1 "ps -ef | grep notty | grep -v grep | awk {'print \$2'} | xargs kill"

when I call this script with the host name, it goes and kills all the sessions hanging with "notty" word in them. Rogue but effective for my purposes.

Hope this helps

[RAC_1]

Make use of full paths.
Do not use ~/.ssh/somekey_rsa, instead us full path.

[Raj D.]

Hi Jason ,

Try setting up ssh-keygen , and it can run the command directly.

1. # ssh-keygen -t dsa
2. ( Make a directory .ssh , in the server2, under the home directory of the user , if it is not present)
3. Copy the public key (id_dsa.pub) to server2:
# ssh server2 cat '>>' .ssh/authorized-key2 < ~/.ssh/id_dsa.pub
(Need to enter your unix password once)

4.Now you can run command directly from server1.
# ssh server2 " command_here "

This may help you,

Cheers ,
Raj.

[Raj D.]

Sorry , the command has to be run from the particluar user login i.e from $ prompt.

Cheers,

[Jason Martens]

Thanks for the suggestions. This is the current version I'm running:
what /usr/sbin/sshd
/usr/sbin/sshd:
$HP-UX Secure Shell: sshd.c,v A.03.71.000 2003/12/02 $


I already ran the ssh-keygen, which allows me to log in without using a password, and that works fine. It's just that after executing the command directly on the server, the ssh command hangs, and does not exit. How can I avoid that?

[Jason Martens]

I would really like to use the ~/.ssh path, because the command may be run by more than one user. Is using the ~ relative path going to cause it to hang somehow?

[Steven E. Protter]

I have found that to have complete success with ssh jobs one of two things has to be done:

1) Full path
2) set PATH variable in the job

2 was not always needed back in the bad old rsh days.

I would recommend also exchange of public keys between trusted servers.

Also the scripts may need explicit exit commands in them to function correctly.

SEP

[Mel Burslan]

Jason,

3.71 was the version on most of the my boxes prior to upgrade. (Since I was not the one doing the upgrade I can not vouch for all but most I knew were running this version)

So, an upgrade would be beneficial for you as well.

And to address some other suggestions above, this issue does not seem to have anything to do with the command path's or key paths. Something in sshd is making it misinterpret the exit signal.

My experience is mainly with interactive sessions, unlike Jason's. If I run a lot of scripts which do fancy screen stuff but the programmer was not really paying attention to proper esc sequences, My session used to get hung up 90% of the time when I exited out of it. Now, it is not that bad but I still hit a snag here and there. So, my gut feeling is, some esc sequence is messing up the ssh session. I brought it up to the attention of a visiting HP consultant (visit was on a totally different issue) and he searched thru the kmine and could not find any reference to it and told me to take it back to the lab folks. Haven't heard anything back since.

[Matti_Kurkela · Accepted solution]

The reason the ssh command doesn't exit is that some process on the remote host is still hanging on to the connection's pseudo-terminal (pseudo-tty, or pty).

There are two ways to prevent this:

1.) Redirect your remote command's standard input, output and error somewhere else. If you don't need them, redirect to /dev/null. This could be done by changing your "command" option in the authorized_keys file from
command="/run/some/stuff"
to
command="/run/some/stuff /dev/null 2>&1"

2.) Use the -n option of the ssh command.
This tells ssh that we are not going to give any input to the remote program through the ssh connection, so there is no reason to hold the connection open.
Example:
ssh -n -i ~/.ssh/somekey_rsa username@localhost


Wait a second... if you need ssh only to jump from one userid to another on localhost, ssh is a bit of an overkill. You might consider using "sudo" instead. It is available as a part of the Internet Express package on software.hp.com for HP-UX 11.11 and later, and from the HP-UX Porting Archive for older releases (http://hpux.connect.org.uk/ and other mirrors).

To allow the user "backup" to run /run/some/stuff as user "database" with no password asked, you need to configure the sudoers file like this:

backup thishost=(database) NOPASSWD: /run/some/stuff

Then. as a "backup" user, you run this command:
sudo -H -u database /run/some/stuff