# locked out - no login via ssh and tty possible

## Nethermancer

I've "lost contact" to one of my gentoo-boxes:

1. If I try to connect via ssh, nothing happens after I entered my password.

2. A local login is also impossible:

```

gbox login: mars

Password:

Login timed out after 60 seconds.

gbox login:

```

... although I did enter my password.

What could have gone wrong? How can I fix this?

Thanks in advance for any help!

----------

## mach.82

Try to follow the Gentoo Handbook http://www.gentoo.org/doc/en/handbook/index.xml and reset the password:

```
# chroot /mnt/gentoo /bin/bash

# passwd
```

 Goog luck!

----------

## interested1

Nethermancer, this is odd.  Did you recently emerge any login related ebuilds?  If so, did you make sure to run and read through the dispatch-conf diffs?  I've only come across login trouble once with Gentoo and that was after an emerge with login related ebuilds, and I forgot to look through the newly available config files.

Also, mach.82 is right on with the advice: you can get your system back up with the chroot method, yet it would be interesting to know what happened to your system.

----------

## Nethermancer

I resetted the root pw - unfortunately with no effect.

Everything seems to work fine, apart from administrative access.

Maybe some re-emerge could help, I should have all the bin-packages.

Can you give me a list of packages which are login-critical?

I already re-emerged shadow, and did "etc-update" and "env-update" - to no avail.

What are "dispatch-conf diffs"? What do I have to do exactly?

----------

## interested1

Oh, I was just being sloppy in my writing.  What I mean when I said dispatch-conf diffs is a reference to what  dispatch-conf as well as etc-update do as programs.  They facilitate the comparison of the old config file and the new config file via diff --diff is a command line app used to compare line by line two or more different files.  More than just executing a diff on the two config files dispatch-conf and etc-update allow you to have integrated control over the changes to the config files.  For instance providing options such as manual merge of the configs or to overwrite the old config with the new.  I've found that having dispatch-conf call a colorized diff is an easy way to make the file differences easy to read.  Check out this howto if you want to learn about how to colorize.

As for login related ebuilds I am no expert and can only suggest a few that are likely to be related: login, anything with pam login, securetty (not a typo, but tty related).  Yet, a lot of things can be related to logins, for instance:

 *Quote:*   

> No Consistent Naming between DevFS and udev
> 
> Even though our intention is to have a consistent naming scheme between both dynamical device management solutions, sometimes naming differences do occur.
> 
> ...
> ...

  --Gentoo udev guide

Lastly, make sure you use emerge --sync before your updates to make sure that you have the latest ebuilds.

Hope this makes my last post a bit more clear.

----------

## Nethermancer

Until now I just knew etc-update.

Connecting via samba also fails, so it is definately some kind of login process which does not work.

But I do not know where to look for a hint.

I re-emerged "pam" and updated the config file, but it did not help to solve the problem.

```
emerge --update --deep world
```

 ... is currently running - this will take the whole night or even longer (it's a VIA C3 600 Mhz).

If that does not help either, I will give

```
emerge --empty-tree pam
```

 a try.

Any other ideas how to regain access to my gentoo-box?

... apart from a Windoze-solution (re-installation)! By the way, gentoo-2006.1 is out.

I am slowly becoming desperate ... at least my laptop works fine! *g*

----------

## jhmartin

I've seen that behavior when the system was configured for LDAP and the LDAP machine wasn't available / didn't exist. The system had to be rebooted into single user mode to recover it.

----------

## Nethermancer

Thanks for the hint, but I never worked with ldap.

Executing a "deep update" did not change anything, as well as rebuilding pam with "empty-tree".   :Sad: 

I am running out of ideas! Are there any ebuilds apart from "pam" which I should rebuild / are login-relevant?

By the way: Even SMB-connections fail after authentification.

----------

## robdd

Hi there Nethermancer - this sounds horrible ! I hate problems like this. A couple of things you could try..

Can you login using a local account with no password set up at all ? (Not clear if you've tried this yet)

Have you had a look at the system logs in /var/log ? Depends on what your setup is like, but if it's plain vanilla then you could try both a local login and an ssh login or two, then boot off CD or whatever and look in var/log/messages to see if there are any log messages that might give some clue as to what is going on. If you've set up more complex logging then an 'ls -ltr' in the var/log directory will show which log files have changed most recently.

Good Luck   :Smile: 

----------

## Scan-C

Hi!

I got this problem when the build of bash failed in some way. The binary was there but defective and after a rebuild of bash with flags set to mcpu=i386 it worked again.

It's worth a shot but i can't think of why samba shouldn't work when just bash is damaged.

----------

## Nethermancer

I'm glad that there are some guys out there to help me!

This is the verbose output from my laptop (ssh-client):

```
# ssh -vvv 192.168.0.250

OpenSSH_4.3p2, OpenSSL 0.9.7j 04 May 2006

debug1: Reading configuration data /etc/ssh/ssh_config

debug2: ssh_connect: needpriv 0

debug1: Connecting to 192.168.0.250 [192.168.0.250] port 22.

debug1: Connection established.

debug1: permanently_set_uid: 0/0

debug1: identity file /root/.ssh/identity type -1

debug1: identity file /root/.ssh/id_rsa type -1

debug1: identity file /root/.ssh/id_dsa type -1

debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3

debug1: match: OpenSSH_4.3 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_4.3

debug2: fd 3 setting O_NONBLOCK

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

debug2: kex_parse_kexinit: ssh-rsa,ssh-dss

debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr

debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib

debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib

debug2: kex_parse_kexinit:

debug2: kex_parse_kexinit:

debug2: kex_parse_kexinit: first_kex_follows 0

debug2: kex_parse_kexinit: reserved 0

debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

debug2: kex_parse_kexinit: ssh-rsa,ssh-dss

debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr

debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: none,zlib@openssh.com

debug2: kex_parse_kexinit: none,zlib@openssh.com

debug2: kex_parse_kexinit:

debug2: kex_parse_kexinit:

debug2: kex_parse_kexinit: first_kex_follows 0

debug2: kex_parse_kexinit: reserved 0

debug2: mac_init: found hmac-md5

debug1: kex: server->client aes128-cbc hmac-md5 none

debug2: mac_init: found hmac-md5

debug1: kex: client->server aes128-cbc hmac-md5 none

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

debug2: dh_gen_key: priv key bits set: 143/256

debug2: bits set: 524/1024

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts

debug3: check_host_in_hostfile: match line 1

debug1: Host '192.168.0.250' is known and matches the RSA host key.

debug1: Found key in /root/.ssh/known_hosts:1

debug2: bits set: 511/1024

debug1: ssh_rsa_verify: signature correct

debug2: kex_derive_keys

debug2: set_newkeys: mode 1

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug2: set_newkeys: mode 0

debug1: SSH2_MSG_NEWKEYS received

debug1: SSH2_MSG_SERVICE_REQUEST sent

debug2: service_accept: ssh-userauth

debug1: SSH2_MSG_SERVICE_ACCEPT received

debug2: key: /root/.ssh/identity ((nil))

debug2: key: /root/.ssh/id_rsa ((nil))

debug2: key: /root/.ssh/id_dsa ((nil))

debug1: Authentications that can continue: publickey,keyboard-interactive

debug3: start over, passed a different list publickey,keyboard-interactive

debug3: preferred 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: /root/.ssh/identity

debug3: no such identity: /root/.ssh/identity

debug1: Trying private key: /root/.ssh/id_rsa

debug3: no such identity: /root/.ssh/id_rsa

debug1: Trying private key: /root/.ssh/id_dsa

debug3: no such identity: /root/.ssh/id_dsa

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

debug2: input_userauth_info_req

debug2: input_userauth_info_req: num_prompts 1

Password:

debug3: packet_send2: adding 32 (len 26 padlen 6 extra_pad 64)

debug2: input_userauth_info_req

debug2: input_userauth_info_req: num_prompts 0

debug3: packet_send2: adding 48 (len 10 padlen 6 extra_pad 64)

debug1: Authentication succeeded (keyboard-interactive).

debug1: channel 0: new [client-session]

debug3: ssh_session2_open: channel_new: 0

debug2: channel 0: send open

debug1: Entering interactive session.

debug2: callback start

debug2: client_session2_setup: id 0

debug2: channel 0: request pty-req confirm 0

debug3: tty_make_modes: ospeed 38400

debug3: tty_make_modes: ispeed 38400

debug3: tty_make_modes: 1 3

debug3: tty_make_modes: 2 28

debug3: tty_make_modes: 3 127

debug3: tty_make_modes: 4 21

debug3: tty_make_modes: 5 4

debug3: tty_make_modes: 6 0

debug3: tty_make_modes: 7 0

debug3: tty_make_modes: 8 17

debug3: tty_make_modes: 9 19

debug3: tty_make_modes: 10 26

debug3: tty_make_modes: 12 18

debug3: tty_make_modes: 13 23

debug3: tty_make_modes: 14 22

debug3: tty_make_modes: 18 15

debug3: tty_make_modes: 30 0

debug3: tty_make_modes: 31 0

debug3: tty_make_modes: 32 0

debug3: tty_make_modes: 33 0

debug3: tty_make_modes: 34 0

debug3: tty_make_modes: 35 0

debug3: tty_make_modes: 36 1

debug3: tty_make_modes: 37 0

debug3: tty_make_modes: 38 0

debug3: tty_make_modes: 39 0

debug3: tty_make_modes: 40 0

debug3: tty_make_modes: 41 0

debug3: tty_make_modes: 50 1

debug3: tty_make_modes: 51 1

debug3: tty_make_modes: 52 0

debug3: tty_make_modes: 53 1

debug3: tty_make_modes: 54 1

debug3: tty_make_modes: 55 1

debug3: tty_make_modes: 56 0

debug3: tty_make_modes: 57 0

debug3: tty_make_modes: 58 0

debug3: tty_make_modes: 59 1

debug3: tty_make_modes: 60 1

debug3: tty_make_modes: 61 1

debug3: tty_make_modes: 62 0

debug3: tty_make_modes: 70 1

debug3: tty_make_modes: 71 0

debug3: tty_make_modes: 72 1

debug3: tty_make_modes: 73 0

debug3: tty_make_modes: 74 0

debug3: tty_make_modes: 75 0

debug3: tty_make_modes: 90 1

debug3: tty_make_modes: 91 1

debug3: tty_make_modes: 92 0

debug3: tty_make_modes: 93 0

debug2: channel 0: request shell confirm 0

debug2: fd 3 setting TCP_NODELAY

debug2: callback done

debug2: channel 0: open confirm rwindow 0 rmax 32768

debug2: channel 0: rcvd adjust 131072
```

Is there any suspicious information I could have missed?

 *Quote:*   

> Hi there Nethermancer - this sounds horrible ! I hate problems like this.

 

It IS horrible, imagine you have a house with automatic shutter blinds, programmable heating and your dinner is ready - everything is just fine, but ... you cannot enter your house!   :Confused: 

"Humor is the last virtue on the verge of desperation."

However, my sshd_config looks something like this (sorry, I'm too lazy to switch LAN cables again):

```
...

PasswordAuthentication no

PermitEmptyPasswords no

...

UsePAM no

...
```

I created a password-less account. A login attempt looked like this:

```
# ssh fool@gbox

Permission denied (publickey,keyboard-interactive).
```

I did an "emerge --sync && emerge -vuD" a few hours ago, unfortunately there are no updates relating to login-"stuff".

My gbox had an uptime of over 100 days, so it is nearly impossible to determine the responsable package(s)/ebuild(s).

So, what else can I do?

Are there any config files regarding tty's which I should check?

Shall I paste other config files in this thread?

----------

## pharaoh

I'm having this same problem on my server right now.  I started up a screen, began to update Samba (and the few other packages that were required to be updated with it), detached the screen and logged out.  Later on I couldn't login remotely so I figured I'd wait until I got home and try it locally.  It bumps me out locally too, even for root.  I don't even get a password prompt...right after entering a username and hitting enter I get 

```
Permission denied (publickey,keyboard-interactive).
```

I'll boot to CD and find out what's going on and report back.  For the record, I am using hosts.allow & hosts.deny but I never got to run etc-update.  I'm confused what could have possibly affected remote and local logins from updating Samba.

----------

## cobalt

omg i feel your pain. I have this problem now too. I do find that i can login if i hit 'I' for interactive and select '4' for the shell. but that and chroot from the cd are the only ways i can get back in to my system as of right now. the only difference is im not using samba on my box so i couldnt tell u if that was borked as well or not but the local login and ssh login problems are the same. i also noticed once in maintenance mode i couldnt use commands like useradd and passwd. not sure if thats a default behavior for that mode or not. ive done emerge -uDve world several times and ive unmerged pam and shadow and re-emerged them afterwards to still have the problem persist.

----------

## cobalt

so has anyone found any more information on this? i havent been able to resolve it myself nor can i pull any logs for it as metalog doesnt seem to be working correctly now either and isnt logging anything.

well didnt notice untill just now how old this topic is lol.

----------

## bunder

try a revdep-rebuild?

----------

## cobalt

yes just now and heres the output

```
Configuring search environment for revdep-rebuild

Checking reverse dependencies...

Packages containing binaries and libraries broken by a package update

will be emerged.

Collecting system binaries and libraries... done.

  (/root/.revdep-rebuild.1_files)

Collecting complete LD_LIBRARY_PATH... done.

  (/root/.revdep-rebuild.2_ldpath)

Checking dynamic linking consistency...

 done.

  (/root/.revdep-rebuild.3_rebuild)

Assigning files to ebuilds... Nothing to rebuild

Evaluating package order... done.

  (/root/.revdep-rebuild.5_order)

Dynamic linking on your system is consistent... All done.

```

waiting for a file transfer to finish before i reboot the system and try again.

----------

## pharaoh

I haven't had a chance to try anything since the scsi cdrom I have in the box isn't working.  It's not in an ideal area to be worked on, so it's just sitting there hosting my mp3s.

----------

## cobalt

i rebooted after the revdep-rebuild and nothings changed

----------

## bunder

what does your /etc/pam.d/system-auth look like?

cheers

----------

## {BaC}Archer

You might get into the system with the boot CD, chroot, and 'emerge shadow'.  I had a similar problem, and I think that might be your solution.  If it works, don't forget to post your solution, eh?

----------

## bjlockie

```

emerge pam

```

----------

## bunder

 *bjlockie wrote:*   

> 
> 
> ```
> 
> emerge pam
> ...

 

he already did that, wake up.   :Wink: 

----------

## cobalt

ive already emerge shadow and pam several times it doesnt change anything. and as far as what system-auth looks like iunno atm ive already begun to reinstall the system from scratch. kinda got impatient since i need the system working like now.

----------

## bunder

fair enough, let us know if it snags you again.   :Laughing: 

cheers

----------

## pharaoh

Got it working   :Very Happy:   Please see this topic here!  To summarize: don't emerge -u samba, detach your screen, and log out of the box.  The new shadow package has pam-login built in and so it requires pam-login to be removed prior to installation.

EDIT: It should also be noted that this allowed me to login locally but not via ssh.  I updated openssh, etc-update, and everything worked once again!

----------

## Nethermancer

Sorry for this very late reply:

After weeks of testing I decided to install from scratch. Unfortunately, the problem returned about every 2 weeks.

I found out that ddclient was always one of the last entries in the logfiles just before the system stopped reacting.

But the culprit on my system was metalog; I had configured it to log entries for ddclient and shorewall.

Here is the thread that helped me: https://forums.gentoo.org/viewtopic-t-19368-highlight-metalog+hangs.html

I hope this is a help for the people who did not find any solution yet.

----------

