Debian Etch SSH Problem

[Stiganator]

I have a debian etch install and when I try to ssh in it immediately terminates the connection. I don't even get a chance to type the password. I'm using the .confs that worked from sarge so I don't know what's up. Anyone have a similar problem.

 

[n0cmonkey]

Logs?

ssh -vvv server

/usr/sbin/sshd -dddD if necessary.

 

[Stiganator]

compiling some packages right now, if these don't fix it I'll snag the logs.

 

[DaiShan]

Also, which user are you trying to ssh in as? If you have root logins disabled through SSH and you are attempting to log in using the root account it won't let you in. Try restarting the ssh server via the initscript, if you can't get it working, post your sshd_config and I'll take a look at it.

 

[drag]

I don't think compiling from source is realy the answer here. It's probably just going to make things just that much harder for you to figure out the what is the problem.

I NEVER had any problems with etch. So it's likely that there is problems with the configuration file or some other thing with the system.

I suggest copying your configuration files to a safe place. Then go:

apt-get remove --purge openssh-server

apt-get update
apt-get install openssh-server


This will re-install the original configuration files. When you try to ssh into it now it may complain about having the wrong identification key, since your reinstalling it it may re-generate it. I am not 100% sure, but I think this will happen. So watch out for that.

But baring that you should be able to ssh right into it, no problem.


You also need to check out the log files also. They are there for a reason and the reason is to let you know what is going on with your system. If Openssh is denying a client access for whatever reason it will log this and it will tell you what is going on.

 

[n0cmonkey]

Hell, I'd be recompiling it anyway. Unless you're using Debian unstable (I don't know how etch maps to these other names ) the version of OpenSSH used by Debian is horribly out of date.

 

[Nothinman]

Unless you're using Debian unstable (I don't know how etch maps to these other names ) the version of OpenSSH used by Debian is horribly out of date.

sarge is oldstable, etch is stable, lenny is testing (will be the next stable release) and sid is unstable. And the version in stable may be old but if there were any security issues patches would have been backported to the version in etch.

 

[n0cmonkey]

Originally posted by: Nothinman
<div class="FTQUOTE"><begin quote> Unless you're using Debian unstable (I don't know how etch maps to these other names ) the version of OpenSSH used by Debian is horribly out of date. </end quote></div>

sarge is oldstable, etch is stable, lenny is testing (will be the next stable release) and sid is unstable. And the version in stable may be old but if there were any security issues patches would have been backported to the version in etch.

There are some nice features in the new version.

And hacked up older versions aren't generally supported by the upstream maintainers.

 

[Nothinman]

There are some nice features in the new version.

I don't doubt it but most people likely won't notice and Debian would rather not risk any regressions by packaging up new versions of things into stable all of the time.

And hacked up older versions aren't generally supported by the upstream maintainers.

And that's the point of distribution maintainers.

 

[sciencewhiz]

I didn't have any problem with ssh when upgrading from sarge to etch.

 

[nweaver]

yeah, post your sshd config file. The most common reason I see this is due to keys (I require keys for login) not being loaded/found/specified.

 

[drag]

Originally posted by: n0cmonkey
Hell, I'd be recompiling it anyway. Unless you're using Debian unstable (I don't know how etch maps to these other names ) the version of OpenSSH used by Debian is horribly out of date.

Debian Stable uses version 4.3, the current Openssh release is 4.6.

Doesn't seem that bad. If you need newer version then that then the 'Debian way' would be compiling openssh from unstable via apt-source and such things. The way the package management system is setup is that you can compile from source using it, but not very many people need to do that so it's not that widely used.

This way you can keep things tidy and don't have to worry about things like a security update from debian overwriting your compiled from source version.

It would be nice to have a way to tell the package management system that you've done a paticular package or library yourself completely from scratch and without the use of any package management stuff, but so far nobody has taken care of that problem yet.

 

[Nothinman]

It would be nice to have a way to tell the package management system that you've done a paticular package or library yourself completely from scratch and without the use of any package management stuff, but so far nobody has taken care of that problem yet.

Those are conflicting statements, how could you tell the package management system that you've done something with a package without using the package management stuff? And if you really want to lie to the package manager to satisfy a dependency without using a full package you can use equivs to create a package with just dependency info.

 

[drag]

I ment that you take a plain tarball do the "configure ;make; make install", then checking some box somewere or a command to simply tell the package management system to assume such and such dependancy or package is installed.

Currently you can do something like make a dummy package, but it's a PITA.

 

[n0cmonkey]

Between:

* sshd now allows the enabling and disabling of authentication
methods on a per user, group, host and network basis via the
Match directive in sshd_config.

and

- "hang on exit" when background processes are running at the time
of exit on a ttyful/login session (bugzilla #52)

OpenSSH 4.6 is necessary. That's just between 4.5 and 4.6 and ignores all security fixes. 4.3 is frickin' ancient!

 

[drag]

Well if you consider software release that just over a year old as ancient, then so be it.

I figure not many people want to do a full systme upgrade ever 6 months or so. So as long as security concernes are kept under control then I don't see a problem with it.

But to each their own. Personally I run unstable at home, so for me it's a continous rolling update.. but different purposes have different requirements.

 

[n0cmonkey]

Originally posted by: drag
Well if you consider software release that just over a year old as ancient, then so be it.

I figure not many people want to do a full systme upgrade ever 6 months or so. So as long as security concernes are kept under control then I don't see a problem with it.

But to each their own. Personally I run unstable at home, so for me it's a continous rolling update.. but different purposes have different requirements.

1 year is ancient in internet terms.

Upgrading OpenSSH shouldn't require a full system upgrade, but 6 months is long enough with the old stuff.

 

[Nothinman]

I ment that you take a plain tarball do the "configure ;make; make install", then checking some box somewere or a command to simply tell the package management system to assume such and such dependancy or package is installed.

You could use checkinstall if you want.

Currently you can do something like make a dummy package, but it's a PITA.

equivs looks pretty simple to me.

1 year is ancient in internet terms.

But it's also really short in support terms, look how long RH supports individual versions of their software for. Just because the OpenBSD people don't give a crap about long term support doesn't mean no one else should.

 

[n0cmonkey]

Originally posted by: Nothinman

I ment that you take a plain tarball do the "configure ;make; make install", then checking some box somewere or a command to simply tell the package management system to assume such and such dependancy or package is installed.

You could use checkinstall if you want.

Currently you can do something like make a dummy package, but it's a PITA.

equivs looks pretty simple to me.

1 year is ancient in internet terms.

But it's also really short in support terms, look how long RH supports individual versions of their software for. Just because the OpenBSD people don't give a crap about long term support doesn't mean no one else should.

And I create fresh RPMs for RHEL every time OpenSSH comes out with a new version.

 

[Nothinman]

And I create fresh RPMs for RHEL every time OpenSSH comes out with a new version.

And when you run into a problem RH support will likely tell you to either put their supported versions back and try again or debug it on your own.

 

[n0cmonkey]

Originally posted by: Nothinman

And I create fresh RPMs for RHEL every time OpenSSH comes out with a new version.

And when you run into a problem RH support will likely tell you to either put their supported versions back and try again or debug it on your own.

I haven't needed to call RH support yet, especially about OpenSSH issues. The debugging options are pretty good.

 

[Stiganator]

Turned out our version of LDAP, PAM, and SSH didn't play nice. Reverted back on version of PAM and it worked.