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@xxxxxx <garcia_pan@xxxxxx> 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@xxxxxxxxxxxxxx > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@xxxxxxxxxxxxxx > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@xxxxxxxxxxx,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@xxxxxxxxxxx,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. > > - > : send the line "unsubscribe linux-admin" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > - : send the line "unsubscribe linux-admin" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
