-   Linux - Server (
-   -   ssh and sftp fails. (

mmcc0912 03-17-2010 06:12 PM

ssh and sftp fails.
Linux Green here, forgive me for leaving anything out.

I was asked to create a trust between two nodes. I did a base-line test first to get the result, expecting failure. It came back with "host key verification failed", seemed expected. I added the .pub to the user on the remote host and tried again, but still failed. This is expected to be with sftp. Kicked over to ssh and it came back with the same thing. Long story as short as possible, I can't ssh to any host from this box, "host key verification failed". If I run ssh with the StrictHostKeyChecking=no it is able to add it to the known_hosts before failing, it wouldn't do that otherwise. When using this option, it comes back with:
Permission denied (publickey,gssapi-with-mic,password).

I ran 'sftp -vv user@host' and the ending results came back with:
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug2: no key of type 0 for host
debug2: no key of type 2 for host
Host key verification failed.
Couldn't read packet: Connection reset by peer

I've gotten a thanks from google trying to look into it and find things to try but finding sparse and repetative information. sftp issues in batch mode, but that doesn't apply. Nothing showing as to why ssh can't be done from the box at all without error.

What am I missing as to why it's trying to force a login and not just say, hey, what's the password for root? I haven't changed anything and have never seen this in my few short years with Linux.

Linux localhost 2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:21 EST 2007 i686 athlon i386 GNU/Linux
Red Hat Enterprise Linux Server release 5 (Tikanga)


smoker 03-17-2010 06:36 PM

How did you add the public key ?
To which file ?

chrism01 03-18-2010 04:50 AM


what's the password for root?
Usually PermitRootLogin is set to no in server sshd_config. Post your server sshd_config.

mmcc0912 03-18-2010 11:59 AM

The posting of the key info was more of the purpose for working on this box and what my intentions were. I am most purplexed as to why I can't just ssh from it to another box.

Here is the sshd_config:

# $OpenBSD: sshd_config,v 1.73 2005/12/06 22:38:28 reyk Exp $

# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.

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

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

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

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

# Authentication:

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

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys2

# For this to work you will also need host keys in /etc/ssh/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
PasswordAuthentication yes

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

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

# GSSAPI options
#GSSAPIAuthentication no
GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
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 mechanism.
# Depending on your PAM configuration, this may bypass the setting of
# PasswordAuthentication, PermitEmptyPasswords, and
# "PermitRootLogin without-password". If you just want the PAM account and
# session checks to run without PAM authentication, then enable this but set
# ChallengeResponseAuthentication=no
#UsePAM no
UsePAM yes

# Accept locale-related environment variables
#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
#ShowPatchLevel no
#UseDNS yes
#PidFile /var/run/
#MaxStartups 10
#PermitTunnel no

# no default banner path
#Banner /some/path

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

mmcc0912 03-18-2010 12:30 PM

It also made me think, the ssh connections from this box to another, is this helpful? The ssh_config:

# $OpenBSD: ssh_config,v 1.21 2005/12/06 22:38:27 reyk Exp $

# This is the ssh client system-wide configuration file. See
# ssh_config(5) for more information. This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
# 1. command line options
# 2. user-specific file
# 3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options. For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

# Host *
# ForwardAgent no
# ForwardX11 no
# RhostsRSAAuthentication no
RSAAuthentication yes
# PasswordAuthentication yes
HostbasedAuthentication yes
BatchMode yes
# CheckHostIP yes
# AddressFamily any
# ConnectTimeout 0
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_rsa
IdentityFile ~/.ssh/id_dsa
# Port 22
Protocol 2,1
# Cipher 3des
# Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
# EscapeChar ~
# Tunnel no
# TunnelDevice any:any
# PermitLocalCommand no
Host *
GSSAPIAuthentication yes
# If this option is set to yes then remote X11 clients will have full access
# to the original X11 display. As virtually no X11 client supports the untrusted
# mode correctly we set this to yes.
ForwardX11Trusted yes
# Send locale-related environment variables

mmcc0912 03-18-2010 06:07 PM

Everything in a debug seems good but I've been searching around on the last part and still no avail.

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
Host key verification failed.

I'm still digging but if anyone has any other thoughts, please pass over...

More detailed:

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: 131/256
debug2: bits set: 507/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: filename /etc/ssh/ssh_known_hosts
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug2: no key of type 0 for host
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts2
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts2
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug2: no key of type 2 for host
Host key verification failed.

jwl17330536 03-19-2010 11:19 AM

I'm confused.. You provided both the ssh_config and sshd_config

Where does the actual problem lie? Can you try to test the connection to another device?

For example:

host01: # ssh host02 (fail)
host01: # ssh someotherhost (success)

This would tell me that the problem lies on the 'receiving' end and I need to look at the sshd_config file from host02...

RaelOM 03-19-2010 11:47 AM

What is the exact command you are running? Your local sshd_config looks fine.

You're trying to setup a trust relationship? So you did the keygen already and placed the RSA/DSA key in the authorized_keys file on the remote host? The .ssh directory is owned and group owned by the user you are connecting to and the permissions are 700 on the .ssh directory? The authorized_keys file needs the same ownership/group ownership as well and needs permissions 600.


/root/.ssh root:root 0700
/root/.ssh/authorized_keys root:root 0600

tredegar 03-19-2010 12:20 PM

Here's a good guide to setting up and using ssh with key-based authentication.

mmcc0912 03-19-2010 12:37 PM

From ssh_config:
BatchMode yes

This was the problem.

The argument must be yes or no. If set to yes, passphrase/password querying will be disabled. This option is useful in scripts and other batch jobs where you have no user to supply the password.

mmcc0912 03-19-2010 01:22 PM

Just noticed the responses that I hadn't seen today.

It was a problem of ssh from the node. It was the task to setup the keys for sftp trust that got me into this node for the first time. I thank everyone for the brain busting help ! Now on to learning how to create trusts...

tredegar 03-19-2010 02:47 PM

Pleased you have made some progress with configuring ssh.

I was asked to create a trust between two nodes. [SNIP].... Now on to learning how to create trusts...
I didn't understand this, so search-engined it.

It looks like you may be trying to implement Ripple Protocol.

If so, please be aware that the Ripple Project is "currently dormant" as of July 2009.

I'd also like to suggest that you need to be very careful here, if you are playing with "financial transaction projects" when you are perhaps a new linux user.

For example, I would not like you to have your fingers badly burnt if you have inadvertently set up ssh or sftp incorrectly. There are many other security considerations as well.

I tend to leave "financial transaction software" to the Big Guns, who have the resources (and no doubt, insurance) to support this sort of activity.

You may, of course, be contracted by some major financial institution, but in which case, why are you asking questions here on LQ?

Additionally, the movement of currency between parties in different, or indeed the same, countries is likely to be highly regulated. Attempting to do this in a relatively anonymous manner is likely to attract the attention of the various regulatory authorities ( Internet-search money laundering )

Perhaps my searches have led me astray, and I have made too many assumptions.

In which case, my apologies, and please explain "Now on to learning how to create trusts...".

WiZaxx 03-20-2010 10:00 PM

SFTP: Fatal error
This has nothing do do with the post, but it helped me figure out what I was doing wrong.


mmcc0912 03-22-2010 09:40 AM

The purpose of the box is for Aventx and automation with Oracle. They use sftp for picking up internal data to process. I apologize for some confusion in my explaining the flow of things rather than just the issue of ssh doesn't work outbound.

Yes, I'm new'ish to Linux, understand a good amount but missing the super user depth of the OS.

Thanks everyone for even just listening... It took me a *stuff* ton of searching to see what the issue was. Hopefully there is helpful information in here. I have found some good stuff on this site and hope to continue with everyone in my journeys of the Linux world.

tredegar 03-22-2010 03:52 PM

Thanks for the follow-up.

ssh can be difficult to set up for a good reason: Because you are using ssh rather than telnet, ssh assumes you want a secure connection. It does basic checks to see if you have left anything accidentally open. If so, it will fail to connect on the premise that no connection is better than establishing an insecure connection that you thought was "secure".

All times are GMT -5. The time now is 02:26 AM.