Re: SSH problem

[Jamie Border <jborder@gmail.com>]

Pedro

You could consider an alternative:

Machine 'C' forwards SSH traffic from 'A' to 'B' (and 'B' to 'A' ? You
didn't say)

This could be accomplished using iptables.  Should you need advice on
exact configuration, mail me off-list and I will help.

This would mean:

1) You do not have the 'SSH-in-SSH' situation, as you currently do

2) You have the same (or better) security.  Better because a
port-forward-only box with no access other than physical will always
be more secure than a box with open services.

3) If you want to give a user access to a machine, you have to
explicitly give him/her an account on it.  This gives better auditing
(but may not be what you want)

4) Your users will be less confused


IPTables assistance:

1) http://iptables-tutorial.frozentux.net/iptables-tutorial.html

2) google for 'iptables nat'


Have fun!

Jamie


On Wed, 16 Feb 2005 15:52:21 +0100, garcia_pan@tsm.es <garcia_pan@tsm.es> wrote:
> Hi all
> 
> I have a machine with RHEL 3 WS. This machine has two network interfaces,
> each one in a different network, one for office work and another for
> development work.
> 
> Since I don't want to enable access between both network but in special
> cases, this machine is providing ssh service, and I am planning to use it
> as "jump machine": An user access to the Jump Machine using ssh and then in
> the shell the users must connect using ssh to the development machine. More
> clearly:
> 
> A is the office machine
> B is the development machine
> C is the jump machine
> 
> U is the user (defined in both B and C)
> 
> The schema:
> 
> A -> (ssh) -> C -> (ssh) -> B
> 
> Well:
> If U is root all is going fine.
> If U is for instance "pedro" (My test user), the connection between A and C
> is correct, but I am not able to connect to B.
> If I connect form C to B (accessing directly to A console) this behaviour
> is also observed.
> 
> I copied the known_hosts under "/root/.ssh" to "/home/pedro/.ssh", and
> chowned this file to user "pedro" group "pedro" (As defined in
> /etc/passwd).
> 
> I didn't generated enither DSA nor RSA keys because I want a password
> connection for each user
> 
> When trying to connect from C to B I get an:
> 
> Permission denied, please try again.
> Permission denied, please try again.
> Permission denied (publickey)
> 
> At the end of this mail please see the -vvv trace for this connection try,
> but... any idea?
> 
> Thanks you in advance,
>       Pedro.
> 
> [pedro@C]$ ssh pedro@B -vvv
> OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090701f
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Applying options for *
> debug1: Rhosts Authentication disabled, originating port will not be
> trusted.
> debug2: ssh_connect: needpriv 0
> debug1: Connecting to B [B] port 22.
> debug1: Connection established.
> debug1: identity file /home/pedro/.ssh/identity type -1
> debug1: identity file /home/pedro/.ssh/id_rsa type -1
> debug1: identity file /home/pedro/.ssh/id_dsa type -1
> debug1: Remote protocol version 2.0, remote software version 3.0.1 SSH
> Secure Shell
> debug1: match: 3.0.1 SSH Secure Shell pat 3.0.*
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_3.6.1p2
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug2: kex_parse_kexinit:
> diffie-hellman-group-exchange-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,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
> debug2: kex_parse_kexinit:
> aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
> 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
> debug2: kex_parse_kexinit: none,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-group1-sha1
> debug2: kex_parse_kexinit: ssh-dss
> debug2: kex_parse_kexinit:
> aes128-cbc,3des-cbc,blowfish-cbc,twofish128-cbc,twofish-cbc,arcfour,cast128-cbc,aes192-cbc,aes256-cbc,twofish192-cbc,twofish256-cbc
> debug2: kex_parse_kexinit:
> aes128-cbc,3des-cbc,blowfish-cbc,twofish128-cbc,twofish-cbc,arcfour,cast128-cbc,aes192-cbc,aes256-cbc,twofish192-cbc,twofish256-cbc
> debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,none
> debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,none
> debug2: kex_parse_kexinit: none,zlib
> debug2: kex_parse_kexinit: none,zlib
> 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
> debug2: dh_gen_key: priv key bits set: 121/256
> debug2: bits set: 505/1024
> debug1: sending SSH2_MSG_KEXDH_INIT
> debug1: expecting SSH2_MSG_KEXDH_REPLY
> debug3: check_host_in_hostfile: filename /home/pedro/.ssh/known_hosts
> debug3: check_host_in_hostfile: match line 1
> debug1: Host 'B' is known and matches the DSA host key.
> debug1: Found key in /home/pedro/.ssh/known_hosts:1
> debug2: bits set: 499/1024
> debug1: ssh_dss_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
> debug1: Authentications that can continue: publickey,password
> debug3: start over, passed a different list publickey,password
> 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: /home/pedro/.ssh/identity
> debug3: no such identity: /home/pedro/.ssh/identity
> debug1: Trying private key: /home/pedro/.ssh/id_rsa
> debug3: no such identity: /home/pedro/.ssh/id_rsa
> debug1: Trying private key: /home/pedro/.ssh/id_dsa
> debug3: no such identity: /home/pedro/.ssh/id_dsa
> debug2: we did not send a packet, disable method
> debug3: authmethod_lookup password
> debug3: remaining preferred: ,password
> debug3: authmethod_is_enabled password
> debug1: Next authentication method: password
> debug3: packet_send2: adding 64 (len 50 padlen 14 extra_pad 64)
> debug2: we sent a password packet, wait for reply
> debug1: Authentications that can continue: publickey,password
> Permission denied, please try again.
> debug3: packet_send2: adding 64 (len 50 padlen 14 extra_pad 64)
> debug2: we sent a password packet, wait for reply
> debug1: Authentications that can continue: publickey,password
> Permission denied, please try again.
> debug3: packet_send2: adding 64 (len 50 padlen 14 extra_pad 64)
> debug2: we sent a password packet, wait for reply
> debug1: Authentications that can continue: publickey
> debug3: start over, passed a different list publickey
> debug3: preferred publickey,keyboard-interactive,password
> debug3: authmethod_lookup publickey
> debug3: remaining preferred: keyboard-interactive,password
> debug1: No more authentication methods to try.
> Permission denied (publickey).
> debug1: Calling cleanup 0x8062c30(0x0)
> 
> --
> Este mensaje puede contener información confidencial y/o privilegiada.
> Si Vd. no es el destinatario de este mensaje o ha recibido este mensaje
> por error, por favor, informe inmediatamente al emisor y destruya este
> mensaje. Está estrictamente prohibido por la legislación vigente
> realizar sin autorización cualquier copia, revelación o distribución de
> este mensaje. Las opiniones expresadas en este correo son las de su
> autor y Telefónica Móviles España, S.A. no se responsabiliza de su
> contenido.
> 
> This e-mail may contain confidential and/or privileged information.
> If you are not the intended recipient (or have received this e-mail
> in error), please notify the sender immediately and destroy this
> e-mail. Any unauthorised copying, disclosure or distribution of the
> material in this e-mail is strictly forbidden by current legislation.
> The points of view expressed in this e-mail are solely those of the
> author and may not necessarily be from, or supported by, the company.
> Telefonica Moviles S.A. neither assumes obligations nor accepts
> liability for the content of this e-mail, unless that information is
> subsequently confirmed by writing by a duly authorised representative.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-admin" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html