rlogin session timeout

Khannie

I'm at machine A, I start a session on (local lan) machine B with either telnet or rlogin. After some period of inactivity, the session just disappears. Could anyone tell me how to prevent this?

Edit: here's the command I'm using (it's a shortcut)

gnome-terminal -t machineb --execute ssh myusername@machineb

I also tried rlogin instead of ssh (it allowed me to avoid password typing).

Khannie

This warrants a further reply. I have discovered the culprit:

auto-logout
rlogin: connection closed.

Cheeky fecker!

edit: Solution.

niallb

Check your shell environment on machine B.
Look for a variable called "TMOUT".
If you unset it, it won't automatically log you out.
Its value is measured in seconds.

You may need to be root on B to change TMOUT,
as it may be locked globally as part of resource management.
If so, check /etc/profile, /etc/bash_profile, /etc/bashrc,
and the contents of /etc/profile.d depending on distro.
It should be set in there somewhere.

NiallB

WizZard

Also think about setting up ssh with keys instead of using rlogin. Using keys instead of linteractive logins will save you from having to type a password.

Example here: Gentoo

Khannie

Great minds....I tried that earlier today and failed miserably. Followed the instructions to the letter.

flamegrill

keep an eye on the private key file in your local .ssh/ directory. It has to be only readable by your user or it won't work.

Paul

Khannie

here's a directory listing:

[/home/myusername/.ssh]:ll
total 20
-rw-------  1 myusername ireland 229 Dec 20 08:53 authorized_keys
-rw-r--r--  1 myusername ireland  66 Dec  5 12:44 config~
-rw-r--r--  1 myusername ireland  63 Dec  8 14:27 config.bak
-rw-------  1 myusername ireland 963 Dec 20 08:51 id_rsa
-rw-r--r--  1 myusername ireland 229 Dec 20 08:51 id_rsa.pub
-rw-r--r--  1 myusername ireland 697 Dec 20 08:34 known_hosts

I copied "id_rsa.pub" to "authorized_keys" and removed the .config file that I had there (long story). It's on the same network, so the username is the same and home areas point to the same area too.

WizZard

Hmm, let me try this out at home. Can't now as laptop is turned off. Must implement WOL in router one of these days.

niallb

Khannie wrote:

I copied "id_rsa.pub" to "authorized_keys" and removed the .config file that I had there (long story). It's on the same network, so the username is the same and home areas point to the same area too.

Try renaming the file to authorized_keys2.
This is often the default for ssh2 connections.
In addition, I'd recommend you use a dsa key.
ssh-keygen -t dsa

NiallB

Khannie

Tried that niallb. No joy.

My version is:

OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003

Sounds pretty old. Too old perhaps?

niallb

It's an old enough version, but should work fine.
Two things to check:

permissions on id_dsa, id_dsa.pub, and authorized_keys2

Whether or not the sshd on the remote machine permits login with keys.
Dump the active configuration with this command
grep -v -e ^# -e ^$ /etc/ssh/sshd_config
and post it here if the permissions don't fix it.
Depending on distro, your sshd_config may of course be elsewhere, but that's the most likely place.

For fully automated login, the dsa key sould be generated without a passphrase. Access to such a key file is checkmate, so the permissions are important.

NiallB

P.S. Do you have access to the logs on B ?
It should record why it's passing your authentication through to keyboard interactive.
Alternatively, running ssh -v -v -v myusername@B should give you much more information.

Khannie

Hmmmmmm.

Plenty of debug information there.

Here's the important bit:

debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/MYUSERNAME/.ssh/identity ((nil))
debug2: key: /home/MYUSERNAME/.ssh/id_rsa ((nil))
debug2: key: /home/MYUSERNAME/.ssh/id_dsa (0x8ff80b8)
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/MYUSERNAME/.ssh/identity
debug3: no such identity: /home/MYUSERNAME/.ssh/identity
debug1: Trying private key: /home/MYUSERNAME/.ssh/id_rsa
debug3: no such identity: /home/MYUSERNAME/.ssh/id_rsa
debug1: Offering public key: /home/MYUSERNAME/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: userauth_kbdint: disable: no info_req_seen
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred:
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

It seems to be working up to the point that it actually sends the keys, then it falls over and asks for a password. I suppose there's potential that it's disabled in the RHEL client. I'm going to try downloading the source and building a different copy locally.

I lowered permisisons to 444 on all files in the ~/.ssh directory execpt the id_dsa file (400).

Edit: Ok, bumped up the ssh version to: "OpenSSH_4.2p1, OpenSSL 0.9.7a Feb 19 2003". Maybe it's the openssl that's the problem?....digging.....

niallb

Your end is set up OK as far as I can see.

PubkeyAuthentication yes
AuthorizedKeysFile     %h/.ssh/authorized_keys2

will need to be in the sshd_config on B.
What's that file look like (if you have access)?

debug1: Offering public key: /home/n/niallb/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-dss blen 433
debug2: input_userauth_pk_ok: fp e2:64:36:de:ad:be:ef:4f:4e:6a:1c:c4:0e:43:3a:68
debug3: sign_and_send_pubkey
debug1: read PEM private key done: type DSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.

is what you should be getting if the other end is willing to play.

NiallB

Catch_22

**** , ignore below i now see khannies solution link which covers the below

returning to the original question regarding the auto-logout
i suspect this might be the tcsh autologout, any chance your using tcsh ?

its configured by default to logout after 60 minutes of inactivity,

if so setenv autologout=0 in your .tcshrc

c22