Yes, I need to put ssh in a redhat box and canot upgrade its kernel
and/or gcc until I get that running. Long story, but the bottom line
is there are programs we do not know if we can upgrade to begin with.
I got a fairly late version of openssl and the latest version of
openssh. After telling it to configure without selinux, I was able to
get that compiled. I started sshd but I cannot ssh to the machine
even if I do ssh localhost:

[root@localhost /root]# ssh raub@localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
RSA key fingerprint is d2:21:b3:c6:77:86:b1:4a:49:2b:9f:
49:b3:01:23:db.
Are you sure you want to continue connecting (yes/no)? no
Host key verification failed.
[root@localhost /root]# ssh raub@localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
RSA key fingerprint is d2:21:b3:c6:77:86:b1:4a:49:2b:9f:
49:b3:01:23:db.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (RSA) to the list of known
hosts.
raub@localhost's password:
Permission denied, please try again.
raub@localhost's password:

I did not do much to the sshd_config file; I just told it to ignore
ssh 1
and disallow root login (and allow x11 forwading). But, just to see if
I
missed anything, here it is:


#Port 22
#Protocol 2,1
Protocol 2
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# HostKey for protocol version 1
#HostKey /usr/local/etc/ssh_host_key
# HostKeys for protocol version 2
#HostKey /usr/local/etc/ssh_host_rsa_key
#HostKey /usr/local/etc/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys

# For this to work you will also need host keys in
# /usr/local/etc/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
#UsePAM no

#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no

# no default banner path
#Banner /some/path

# override default of no subsystems
Subsystem sftp /usr/local/libexec/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# ForceCommand cvs server

/var/log/messages only tells me I have a failed password:

Aug 16 12:19:07 localhost sshd[22503]: Failed password for raub from
127.0.0.1 port 1102 ssh2

/var/log/secure says nothing.

On 2007-08-16, Mauricio <raubvogel@gmail.com> wrote:
> Yes, I need to put ssh in a redhat box and canot upgrade its kernel
> and/or gcc until I get that running. Long story, but the bottom line
> is there are programs we do not know if we can upgrade to begin with.
> I got a fairly late version of openssl and the latest version of
> openssh. After telling it to configure without selinux, I was able to
> get that compiled. I started sshd but I cannot ssh to the machine
> even if I do ssh localhost:
[...]

I think Redhats of that vintage had MD5 passwords (check the /etc/shadow
file and see if the password strings start with "$1$") but had a crypt
function that didn't natively support it.

If this is the case, you can either enable MD5 password support when
you build OpenSSH ("./configure --with-md5-passwords") or build with
PAM support (and enable it in sshd_config).

Enabling MD5 password support is safe even if you have old-style DES based
passwords or a mix (sshd will pick the right function automatically).

Also, why did you need to explicitly disable selinux? Did the build fail,
or did you have problems at run time?

--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

In article <vdvep4-oiq.ln1@gate.dtucker.net> Darren Tucker
<dtucker@gate.dtucker.net> writes:
>On 2007-08-16, Mauricio <raubvogel@gmail.com> wrote:
>> Yes, I need to put ssh in a redhat box and canot upgrade its kernel
>> and/or gcc until I get that running. Long story, but the bottom line
>> is there are programs we do not know if we can upgrade to begin with.
>> I got a fairly late version of openssl and the latest version of
>> openssh. After telling it to configure without selinux, I was able to
>> get that compiled. I started sshd but I cannot ssh to the machine
>> even if I do ssh localhost:
>[...]
>
>I think Redhats of that vintage had MD5 passwords (check the /etc/shadow
>file and see if the password strings start with "$1$") but had a crypt
>function that didn't natively support it.

No, that has certainly never been the case - but you may still have hit
the nail on the head.:-) The --with-md5-passwords nonsense is OpenSSL's
fault - in older versions it included a crypt() function that only did
DES, and depending on in which order the -l flags were given in the
OpenSSH build, you'd end up with that one instead of the OS-native one.
I think that by default the OpenSSH build would give the flags in the
"wrong" order... In current OpenSSL that function has been renamed, but
I don't recall off-hand what version that happened in, nor does my
crystal ball reveal what "a fairly late version of openssl" might be.

--Per Hedeland
per@hedeland.org

In article <vdvep4-oiq.ln1@gate.dtucker.net> Darren Tucker
<dtucker@gate.dtucker.net> writes:
>On 2007-08-16, Mauricio <raubvogel@gmail.com> wrote:
>> Yes, I need to put ssh in a redhat box and canot upgrade its kernel
>> and/or gcc until I get that running. Long story, but the bottom line
>> is there are programs we do not know if we can upgrade to begin with.
>> I got a fairly late version of openssl and the latest version of
>> openssh. After telling it to configure without selinux, I was able to
>> get that compiled. I started sshd but I cannot ssh to the machine
>> even if I do ssh localhost:
>[...]
>
>I think Redhats of that vintage had MD5 passwords (check the /etc/shadow
>file and see if the password strings start with "$1$") but had a crypt
>function that didn't natively support it.

No, that has certainly never been the case - but you may still have hit
the nail on the head.:-) The --with-md5-passwords nonsense is OpenSSL's
fault - in older versions it included a crypt() function that only did
DES, and depending on in which order the -l flags were given in the
OpenSSH build, you'd end up with that one instead of the OS-native one.
I think that by default the OpenSSH build would give the flags in the
"wrong" order... In current OpenSSL that function has been renamed, but
I don't recall off-hand what version that happened in, nor does my
crystal ball reveal what "a fairly late version of openssl" might be.

--Per Hedeland
per@hedeland.org

On 17 Aug, 19:38, p...@hedeland.org (Per Hedeland) wrote:
> In article <vdvep4-oiq....@gate.dtucker.net> Darren Tucker
>
> <dtuc...@gate.dtucker.net> writes:
> >On 2007-08-16, Mauricio <raubvo...@gmail.com> wrote:
> >> Yes, I need to put ssh in a redhat box and canot upgrade its kernel
> >> and/or gcc until I get that running. Long story, but the bottom line
> >> is there are programs we do not know if we can upgrade to begin with.
> >> I got a fairly late version of openssl and the latest version of
> >> openssh. After telling it to configure without selinux, I was able to
> >> get that compiled. I started sshd but I cannot ssh to the machine
> >> even if I do ssh localhost:
> >[...]
>
> >I think Redhats of that vintage had MD5 passwords (check the /etc/shadow
> >file and see if the password strings start with "$1$") but had a crypt
> >function that didn't natively support it.
>
> No, that has certainly never been the case - but you may still have hit
> the nail on the head.:-) The --with-md5-passwords nonsense is OpenSSL's
> fault - in older versions it included a crypt() function that only did
> DES, and depending on in which order the -l flags were given in the
> OpenSSH build, you'd end up with that one instead of the OS-native one.
> I think that by default the OpenSSH build would give the flags in the
> "wrong" order... In current OpenSSL that function has been renamed, but
> I don't recall off-hand what version that happened in, nor does my
> crystal ball reveal what "a fairly late version of openssl" might be.
>
> --Per Hedeland
> p...@hedeland.org

The ease of going all the way back to RedHat 6.2, which hasn't been
supported by RedHat in *YEARS*, is not high. But if you have to go
that route, can you find FedoraLegacy project archives that may have
patched and working OpenSSH RPM versions of slightly more recent
vintage then those in your old setup?

Frankly, do not expect to be able to simply slap in recent versions of
*anything*. This especially includes packages like OpenSSH that were
not designed for Linux and which are reliant on so many other
components. The work of porting the OpenBSD versions to other
operating systems is not small: it's not fair to ask the developers to
backport it that far, as well.

If you have to do this, why not simply set the RedHat 6.2 in a small
local DMZ, restrict traffic to it for security reasons, and use the
built-in versions of OpenSSH? Then forward port the local systems as
rapidly as possible to a better environment?

And I do sympathize with your issue: way back at RedHat 6.2, I had a
major deployment plannd where the kernel group wanted to continue to
use their antique 2.0 kernel because it had their custom patches in
it, and they couldn't be bothered to separate their patches into clean
diffs against a real 2.0 kernel tree. Insted, they kept claiming they
could backport anything they needed from the newly available 2.4
kernels as needed. As you might guess, we had some profound
disagreements about that approach, especially when I was being told to
find and integrate parallel port versions of hardware instead of using
the now ubiquitous USB devices. It was only when I started bringing in
letters from manufacturers that they had discontinued their parallel
port devices and had no intention of ever making more that I got
leverage to end that practice.

On 17 Aug, 19:38, p...@hedeland.org (Per Hedeland) wrote:
> In article <vdvep4-oiq....@gate.dtucker.net> Darren Tucker
>
> <dtuc...@gate.dtucker.net> writes:
> >On 2007-08-16, Mauricio <raubvo...@gmail.com> wrote:
> >> Yes, I need to put ssh in a redhat box and canot upgrade its kernel
> >> and/or gcc until I get that running. Long story, but the bottom line
> >> is there are programs we do not know if we can upgrade to begin with.
> >> I got a fairly late version of openssl and the latest version of
> >> openssh. After telling it to configure without selinux, I was able to
> >> get that compiled. I started sshd but I cannot ssh to the machine
> >> even if I do ssh localhost:
> >[...]
>
> >I think Redhats of that vintage had MD5 passwords (check the /etc/shadow
> >file and see if the password strings start with "$1$") but had a crypt
> >function that didn't natively support it.
>
> No, that has certainly never been the case - but you may still have hit
> the nail on the head.:-) The --with-md5-passwords nonsense is OpenSSL's
> fault - in older versions it included a crypt() function that only did
> DES, and depending on in which order the -l flags were given in the
> OpenSSH build, you'd end up with that one instead of the OS-native one.
> I think that by default the OpenSSH build would give the flags in the
> "wrong" order... In current OpenSSL that function has been renamed, but
> I don't recall off-hand what version that happened in, nor does my
> crystal ball reveal what "a fairly late version of openssl" might be.
>
> --Per Hedeland
> p...@hedeland.org

The ease of going all the way back to RedHat 6.2, which hasn't been
supported by RedHat in *YEARS*, is not high. But if you have to go
that route, can you find FedoraLegacy project archives that may have
patched and working OpenSSH RPM versions of slightly more recent
vintage then those in your old setup?

Frankly, do not expect to be able to simply slap in recent versions of
*anything*. This especially includes packages like OpenSSH that were
not designed for Linux and which are reliant on so many other
components. The work of porting the OpenBSD versions to other
operating systems is not small: it's not fair to ask the developers to
backport it that far, as well.

If you have to do this, why not simply set the RedHat 6.2 in a small
local DMZ, restrict traffic to it for security reasons, and use the
built-in versions of OpenSSH? Then forward port the local systems as
rapidly as possible to a better environment?

And I do sympathize with your issue: way back at RedHat 6.2, I had a
major deployment plannd where the kernel group wanted to continue to
use their antique 2.0 kernel because it had their custom patches in
it, and they couldn't be bothered to separate their patches into clean
diffs against a real 2.0 kernel tree. Insted, they kept claiming they
could backport anything they needed from the newly available 2.4
kernels as needed. As you might guess, we had some profound
disagreements about that approach, especially when I was being told to
find and integrate parallel port versions of hardware instead of using
the now ubiquitous USB devices. It was only when I started bringing in
letters from manufacturers that they had discontinued their parallel
port devices and had no intention of ever making more that I got
leverage to end that practice.

On 2007-08-19, Nico <nkadel@gmail.com> wrote:
[...]
> Frankly, do not expect to be able to simply slap in recent versions of
> *anything*. This especially includes packages like OpenSSH that were
> not designed for Linux and which are reliant on so many other
> components. The work of porting the OpenBSD versions to other
> operating systems is not small: it's not fair to ask the developers to
> backport it that far, as well.

FWIW, the effort required to port OpenSSH to older Linuxes (or ones
of Redhat 6.2 vintage, anyway) is smaller than the effort to port it
to other platforms. At one point I had it fully functional even
on 2.0 kernel based systems (after working around a bug in descriptor
passing) although that's probably not been tested for a while.

In general, once it's working on a given platform it will usually continue
to work, modulo minor problems like #includes and such. It's rare
that support for platforms is dropped, and it's usually because of some
missing fundamental feature. (The last example of this would probably
be dropping support for compilers that don't have a 64 bit native type
such as "long long", which happened in 3.7x).

--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

On 2007-08-19, Nico <nkadel@gmail.com> wrote:
[...]
> Frankly, do not expect to be able to simply slap in recent versions of
> *anything*. This especially includes packages like OpenSSH that were
> not designed for Linux and which are reliant on so many other
> components. The work of porting the OpenBSD versions to other
> operating systems is not small: it's not fair to ask the developers to
> backport it that far, as well.

FWIW, the effort required to port OpenSSH to older Linuxes (or ones
of Redhat 6.2 vintage, anyway) is smaller than the effort to port it
to other platforms. At one point I had it fully functional even
on 2.0 kernel based systems (after working around a bug in descriptor
passing) although that's probably not been tested for a while.

In general, once it's working on a given platform it will usually continue
to work, modulo minor problems like #includes and such. It's rare
that support for platforms is dropped, and it's usually because of some
missing fundamental feature. (The last example of this would probably
be dropping support for compilers that don't have a 64 bit native type
such as "long long", which happened in 3.7x).

--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.