Mailing List Archive

On 04 January, 2013 - Robert Berger wrote:

> Hi,
>
> I try to create something like a central place to configure various
> things around conserver.
>
> First I just would like to have conserver to ssh to various machines,
> but I don't get a prompt.
>
> Here is what I do on Ubuntu 12.04 LTS

<snip/>

> default * {
> # The '&' character is substituted with the console name
> #logfile /var/consoles/&;
> logfile /var/log/conserver/&.log;
> # timestamps every hour with activity and break logging
> timestamp 1hab;
> # include the 'full' default
> include full;
> sslenabled yes;
> sslrequired yes;
> }
>
> console ssh {
> master 192.168.2.132;
> rw *;
> type exec;
> exec ssh 192.168.2.160;
> }

<snip/>

The ssh exec'ed there won't have a local pty, so by default it won't
allocate a remote pty. What you need is to add -tt to ssh to force it to
allocate a remote pty. Also usefull for this type of debugging is to add
some -v's to ssh-cmdline to see whats its actualy doing.

//Anton

--
Anton Lundin +46702-161604
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users

Hi Anton,

On 01/04/2013 12:53 PM, Anton Lundin wrote:
> On 04 January, 2013 - Robert Berger wrote:
>
> <snip/>
>
> The ssh exec'ed there won't have a local pty, so by default it won't
> allocate a remote pty. What you need is to add -tt to ssh to force it to
> allocate a remote pty. Also usefull for this type of debugging is to add
> some -v's to ssh-cmdline to see whats its actualy doing.

As you suggested I did the following:

console ssh {
master 192.168.2.132;
rw *;
type exec;
exec ssh -vvv -tt 192.168.2.160;
}

now ssh.log shows:

[-- Console up -- Fri Jan 4 14:09:16 2013]
OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.2.160 [192.168.2.160] port 22.
debug1: Connection established.
debug1: SELinux support disabled
Could not create directory '/etc/conserver/.ssh'.
debug1: identity file /etc/conserver/.ssh/id_rsa type -1
debug1: identity file /etc/conserver/.ssh/id_rsa-cert type -1
debug1: identity file /etc/conserver/.ssh/id_dsa type -1
debug1: identity file /etc/conserver/.ssh/id_dsa-cert type -1
debug1: identity file /etc/conserver/.ssh/id_ecdsa type -1
debug1: identity file /etc/conserver/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version
OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit:
ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman
-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit:
ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-rsa-cert-v01@ope
nssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-ds
s
debug2: kex_parse_kexinit:
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@
lysator.liu.se
debug2: kex_parse_kexinit:
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@
lysator.liu.se
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,
hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,
hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,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:
ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman
-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit:
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@
lysator.liu.se
debug2: kex_parse_kexinit:
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,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:
ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit:
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit:
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA
a1:64:63:58:4c:a1:71:f9:86:ec:f7:be:f0:06:57:62
The authenticity of host '192.168.2.160 (192.168.2.160)' can't be
established.
ECDSA key fingerprint is a1:64:63:58:4c:a1:71:f9:86:ec:f7:be:f0:06:57:62.
Are you sure you want to continue connecting (yes/no)?

and I still get:

student@vlab2-gateone:/etc/conserver$ console -D -p 3109 ssh
console: DEBUG: [cutil.c:2263] ProbeInterfaces(): ifc_len==64 max_count==2
console: DEBUG: [cutil.c:2318] ProbeInterfaces(): name=lo addr=127.0.0.1
console: DEBUG: [cutil.c:2318] ProbeInterfaces(): name=eth0
addr=192.168.2.132
console: DEBUG: [cutil.c:355] AllocString(): 0x97720d8 created string #3
console: DEBUG: [cutil.c:355] AllocString(): 0x9772178 created string #4
console: DEBUG: [cutil.c:355] AllocString(): 0x97721c0 created string #5
console: DEBUG: [console.c:2477] cmds[1] = call
console: DEBUG: [console.c:2477] cmds[0] = attach
console: DEBUG: [console.c:611] GetPort: hostname=console (console),
ip=192.168.2.132, port=3109
console: DEBUG: [cutil.c:355] AllocString(): 0x9772818 created string #6
console: DEBUG: [cutil.c:355] AllocString(): 0x9772750 created string #7
console: DEBUG: [cutil.c:355] AllocString(): 0x9772768 created string #8
console: DEBUG: [cutil.c:355] AllocString(): 0x9772780 created string #9
console: DEBUG: [console.c:769] ReadReply: `ok^M^J'
console: DEBUG: [cutil.c:355] AllocString(): 0x9772fe8 created string #10
console: DEBUG: [cutil.c:355] AllocString(): 0x9773000 created string #11
console: DEBUG: [cutil.c:355] AllocString(): 0x9773060 created string #12
console: DEBUG: [console.c:769] ReadReply: `encryption required^M^J'
console: DEBUG: [cutil.c:329] DestroyString(): 0x9772818 string
destroyed (count==11)
console: encryption required
console: DEBUG: [cutil.c:329] DestroyString(): 0x97721c0 string
destroyed (count==10)
console: DEBUG: [cutil.c:329] DestroyString(): 0x9773060 string
destroyed (count==9)
console: DEBUG: [cutil.c:329] DestroyString(): 0x9773000 string
destroyed (count==8)
console: DEBUG: [cutil.c:329] DestroyString(): 0x9772fe8 string
destroyed (count==7)
console: DEBUG: [cutil.c:329] DestroyString(): 0x9772780 string
destroyed (count==6)
console: DEBUG: [cutil.c:329] DestroyString(): 0x9772768 string
destroyed (count==5)
console: DEBUG: [cutil.c:329] DestroyString(): 0x9772750 string
destroyed (count==4)
console: DEBUG: [cutil.c:329] DestroyString(): 0x9772178 string
destroyed (count==3)
console: DEBUG: [cutil.c:329] DestroyString(): 0x97720d8 string
destroyed (count==2)
console: DEBUG: [cutil.c:329] DestroyString(): 0x9772020 string
destroyed (count==1)
console: DEBUG: [cutil.c:329] DestroyString(): 0x9772008 string
destroyed (count==0)
student@vlab2-gateone:/etc/conserver$

Maybe the client needs to be rebuilt with crypto support?

student@vlab2-gateone:/etc/conserver$ ldd /usr/local/bin/console
linux-gate.so.1 => (0x00902000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x00e34000)
/lib/ld-linux.so.2 (0x00a63000)

E ignored - encryption not compiled into code

Can I get away without encryption support?

>
> //Anton
>

Regards,

Robert
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users

Not having a local tty could be a problem. What I've done was create a
wrapper that executes the cmd argument.

It is a C program and an example is found if Steven's APUE book.

So my exec line looks like this

exec ptymaker ssh ..... ;

If you are interested int his method I'll put the APUE example in my
Dropbox public and share it.

Chris
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users

Hi Chris,

On 01/04/2013 06:20 PM, Chris Fowler wrote:
> Not having a local tty could be a problem. What I've done was create a
> wrapper that executes the cmd argument.
>
> It is a C program and an example is found if Steven's APUE book.
>
> So my exec line looks like this
>
> exec ptymaker ssh ..... ;
>
> If you are interested int his method I'll put the APUE example in my
> Dropbox public and share it.

Yes of course I'm interested. Let me give it a try.

>
> Chris

Regards,

Robert
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users

Hi,

I compiled console to have also crypto support and in the meantime
that's how far I come:

student@vlab2-gateone:/opt/conserver/conserver-8.1.18/console$ ./console
-vvv -D -p 3109 ssh
console: DEBUG: [cutil.c:2263] ProbeInterfaces(): ifc_len==64 max_count==2
console: DEBUG: [cutil.c:2318] ProbeInterfaces(): name=lo addr=127.0.0.1
console: interface address 127.0.0.1 (lo)
console: DEBUG: [cutil.c:2318] ProbeInterfaces(): name=eth0
addr=192.168.2.132
console: interface address 192.168.2.132 (eth0)
console: DEBUG: [cutil.c:355] AllocString(): 0x8d570f0 created string #3
console: DEBUG: [cutil.c:355] AllocString(): 0x8d57190 created string #4
console: DEBUG: [cutil.c:355] AllocString(): 0x8d571e8 created string #5
console: DEBUG: [console.c:2477] cmds[1] = call
console: DEBUG: [console.c:2477] cmds[0] = attach
console: DEBUG: [console.c:611] GetPort: hostname=console (console),
ip=192.168.2.132, port=3109
console: DEBUG: [cutil.c:355] AllocString(): 0x8d64888 created string #6
console: DEBUG: [cutil.c:355] AllocString(): 0x8d64930 created string #7
console: DEBUG: [cutil.c:355] AllocString(): 0x8d648a0 created string #8
console: DEBUG: [cutil.c:355] AllocString(): 0x8d65d10 created string #9
console: DEBUG: [console.c:769] ReadReply: `ok^M^J'
console: DEBUG: [cutil.c:355] AllocString(): 0x8d65d70 created string #10
console: DEBUG: [console.c:769] ReadReply: `ok^M^J'
console: DEBUG: [console.c:146] About to SSL_connect() on fd 3
console: DEBUG: [console.c:154] SSL Connection: TLSv1/SSLv3 ::
ADH-AES256-SHA
console: DEBUG: [cutil.c:355] AllocString(): 0x8dbe398 created string #11
console: DEBUG: [cutil.c:355] AllocString(): 0x8d78698 created string #12
console: DEBUG: [console.c:769] ReadReply: `passwd? vlab2-gateone^M^J'
console: DEBUG: [cutil.c:355] AllocString(): 0x8e0e170 created string #13
console: DEBUG: [cutil.c:355] AllocString(): 0x8d7aae8 created string #14
Enter student@vlab2-gateone's password:
console: DEBUG: [console.c:769] ReadReply: `invalid password^M^J'
console: invalid password
console: DEBUG: [console.c:611] GetPort: hostname=console (console),
ip=192.168.2.132, port=3109
console: DEBUG: [cutil.c:355] AllocString(): 0x8e0e290 created string #15
console: DEBUG: [console.c:769] ReadReply: `ok^M^J'
console: DEBUG: [console.c:769] ReadReply: `ok^M^J'
console: DEBUG: [console.c:146] About to SSL_connect() on fd 4
console: DEBUG: [console.c:154] SSL Connection: TLSv1/SSLv3 ::
ADH-AES256-SHA
console: DEBUG: [console.c:769] ReadReply: `passwd? vlab2-gateone^M^J'
console: DEBUG: [cutil.c:355] AllocString(): 0x8d7a148 created string #16
Enter student@vlab2-gateone's password:
console: DEBUG: [console.c:769] ReadReply: `invalid password^M^J'
console: invalid password
console: DEBUG: [console.c:611] GetPort: hostname=console (console),
ip=192.168.2.132, port=3109
console: DEBUG: [cutil.c:355] AllocString(): 0x8eaef58 created string #17
console: DEBUG: [console.c:769] ReadReply: `ok^M^J'
console: DEBUG: [console.c:769] ReadReply: `ok^M^J'
console: DEBUG: [console.c:146] About to SSL_connect() on fd 5
console: DEBUG: [console.c:154] SSL Connection: TLSv1/SSLv3 ::
ADH-AES256-SHA
console: DEBUG: [console.c:769] ReadReply: `passwd? vlab2-gateone^M^J'
console: DEBUG: [cutil.c:355] AllocString(): 0x8f4fc50 created string #18
Enter student@vlab2-gateone's password:
console: DEBUG: [console.c:769] ReadReply: `invalid password^M^J'
console: invalid password
console: too many bad passwords for `console'
console: DEBUG: [cutil.c:329] DestroyString(): 0x8eaef58 string
destroyed (count==17)
console: DEBUG: [cutil.c:329] DestroyString(): 0x8d571e8 string
destroyed (count==16)
console: DEBUG: [cutil.c:329] DestroyString(): 0x8f4fc50 string
destroyed (count==15)
console: DEBUG: [cutil.c:329] DestroyString(): 0x8d7a148 string
destroyed (count==14)
console: DEBUG: [cutil.c:329] DestroyString(): 0x8e0e290 string
destroyed (count==13)
console: DEBUG: [cutil.c:329] DestroyString(): 0x8d7aae8 string
destroyed (count==12)
console: DEBUG: [cutil.c:329] DestroyString(): 0x8e0e170 string
destroyed (count==11)
console: DEBUG: [cutil.c:329] DestroyString(): 0x8d78698 string
destroyed (count==10)
console: DEBUG: [cutil.c:329] DestroyString(): 0x8dbe398 string
destroyed (count==9)
console: DEBUG: [cutil.c:329] DestroyString(): 0x8d65d70 string
destroyed (count==8)
console: DEBUG: [cutil.c:329] DestroyString(): 0x8d65d10 string
destroyed (count==7)
console: DEBUG: [cutil.c:329] DestroyString(): 0x8d648a0 string
destroyed (count==6)
console: DEBUG: [cutil.c:329] DestroyString(): 0x8d64930 string
destroyed (count==5)
console: DEBUG: [cutil.c:329] DestroyString(): 0x8d64888 string
destroyed (count==4)
console: DEBUG: [cutil.c:329] DestroyString(): 0x8d57190 string
destroyed (count==3)
console: DEBUG: [cutil.c:329] DestroyString(): 0x8d570f0 string
destroyed (count==2)
console: DEBUG: [cutil.c:329] DestroyString(): 0x8d57020 string
destroyed (count==1)
console: DEBUG: [cutil.c:329] DestroyString(): 0x8d57008 string
destroyed (count==0)

cat /var/log/ssh.log

[-- Console up -- Fri Jan 4 18:28:04 2013]
OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /etc/conserver/.ssh/id_rsa type -1
debug1: identity file /etc/conserver/.ssh/id_rsa-cert type -1
debug1: identity file /etc/conserver/.ssh/id_dsa type -1
debug1: identity file /etc/conserver/.ssh/id_dsa-cert type -1
debug1: identity file /etc/conserver/.ssh/id_ecdsa type -1
debug1: identity file /etc/conserver/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version
OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA
91:1f:32:6a:78:4b:96:d2:c3:54:8d:8b:c5:1e:eb:77
debug1: Host 'localhost' is known and matches the ECDSA host key.
debug1: Found key in /etc/conserver/.ssh/known_hosts:2
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /etc/conserver/.ssh/id_rsa
debug1: Trying private key: /etc/conserver/.ssh/id_dsa
debug1: Trying private key: /etc/conserver/.ssh/id_ecdsa
debug1: Next authentication method: password
student@localhost's password: [-- Console down -- Fri Jan 4 18:29:09 2013]

Regards,

Robert

_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users

Are you running conserver as root? If not, you won't be able to look up the password in the shadow file (directly or via the PAM module). Since you changed the port number to a high-numbered port, I'm guessing you aren't. You can put your username and encrypted password into the conserver.passwd file to get around that. Otherwise, you'll need to run it as root.

Bryan
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users

On Apr 21 10:29, Brandon Stout wrote:
> hello, I am trying to use conserver to connect to serial ports over ssh and
> it is hanging. When I go direct it works fine (i am using Opengear IMX4248):
>
> [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002
...
> default full { rw *; }
> default opengear { type host; portbase 3000; portinc 1; }
> default * {
> logfile /var/log/conserver;
> timestamp 1hab;
> include full;
> master localhost;
> }
> default console01 { include opengear; host console01; }
> console dr01.arista { include console01; port 1; }
> console dr02.arista { include console01; port 2; }
...
> Has anyone gotten this to work using ssh?

I think you need to use the exec host type and setup the right execsubst
to get ssh to use the right port number. The "host" type is just a raw
TCP socket connection.

Nate
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users

thanks Nathan, I actually was trying that right after I sent this email and
added this

default opengear-ssh { type exec; portbase 2000; portinc 1;
exec /usr/bin/ssh -p P -l tsuser H;
execsubst H=hs,P=Pd; }

still not working though with just about nothing useful in the logs.
Doesn't hang but it still doesn't work. Just empty space and no output.


On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz <nstraz@redhat.com> wrote:

> On Apr 21 10:29, Brandon Stout wrote:
> > hello, I am trying to use conserver to connect to serial ports over ssh
> and
> > it is hanging. When I go direct it works fine (i am using Opengear
> IMX4248):
> >
> > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002
> ...
> > default full { rw *; }
> > default opengear { type host; portbase 3000; portinc 1; }
> > default * {
> > logfile /var/log/conserver;
> > timestamp 1hab;
> > include full;
> > master localhost;
> > }
> > default console01 { include opengear; host console01; }
> > console dr01.arista { include console01; port 1; }
> > console dr02.arista { include console01; port 2; }
> ...
> > Has anyone gotten this to work using ssh?
>
> I think you need to use the exec host type and setup the right execsubst
> to get ssh to use the right port number. The "host" type is just a raw
> TCP socket connection.
>
> Nate
> _______________________________________________
> users mailing list
> users@conserver.com
> https://www.conserver.com/mailman/listinfo/users
>



--

brandon

OK... but base 2000 is telnet (with authentication) versus the ssh that you
had tried... is your IM set up to listen on telnet (versus the
unauthenticated telnet on base 6000)?

What do you see in the logs on the IM" Failed connections, I'd guess...

-Z-




On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout <bstout@squareup.com> wrote:

> thanks Nathan, I actually was trying that right after I sent this email
> and added this
>
> default opengear-ssh { type exec; portbase 2000; portinc 1;
> exec /usr/bin/ssh -p P -l tsuser H;
> execsubst H=hs,P=Pd; }
>
> still not working though with just about nothing useful in the logs.
> Doesn't hang but it still doesn't work. Just empty space and no output.
>
>
> On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz <nstraz@redhat.com> wrote:
>
>> On Apr 21 10:29, Brandon Stout wrote:
>> > hello, I am trying to use conserver to connect to serial ports over ssh
>> and
>> > it is hanging. When I go direct it works fine (i am using Opengear
>> IMX4248):
>> >
>> > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002
>> ...
>> > default full { rw *; }
>> > default opengear { type host; portbase 3000; portinc 1; }
>> > default * {
>> > logfile /var/log/conserver;
>> > timestamp 1hab;
>> > include full;
>> > master localhost;
>> > }
>> > default console01 { include opengear; host console01; }
>> > console dr01.arista { include console01; port 1; }
>> > console dr02.arista { include console01; port 2; }
>> ...
>> > Has anyone gotten this to work using ssh?
>>
>> I think you need to use the exec host type and setup the right execsubst
>> to get ssh to use the right port number. The "host" type is just a raw
>> TCP socket connection.
>>
>> Nate
>> _______________________________________________
>> users mailing list
>> users@conserver.com
>> https://www.conserver.com/mailman/listinfo/users
>>
>
>
>
> --
>
> brandon
>
> _______________________________________________
> users mailing list
> users@conserver.com
> https://www.conserver.com/mailman/listinfo/users
>
>


--
Sent from my new iPhone 6 Watch (prototype), see my reviews here!
www.conserver.com/consoles/ -- consoleteam.blogspot.com
- - - - - - - -
www.ncry.org
www.d4tm.org
www.hackerdojo.com

So I actually figured out the problem so now it connects, I get the
password prompt and when I enter it correctly it works. The problem is that
when I disconnect and reconnect, it no longer asks me for a password and
just puts me through to the console. is there some sort of disconnect I
need to do manually to get it to reset and ask for a password? Seems like
it just stays connected once the pw is entered, regardless of someone
exiting.


On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout <bstout@squareup.com> wrote:

> thanks Nathan, I actually was trying that right after I sent this email
> and added this
>
> default opengear-ssh { type exec; portbase 2000; portinc 1;
> exec /usr/bin/ssh -p P -l tsuser H;
> execsubst H=hs,P=Pd; }
>
> still not working though with just about nothing useful in the logs.
> Doesn't hang but it still doesn't work. Just empty space and no output.
>
>
> On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz <nstraz@redhat.com> wrote:
>
>> On Apr 21 10:29, Brandon Stout wrote:
>> > hello, I am trying to use conserver to connect to serial ports over ssh
>> and
>> > it is hanging. When I go direct it works fine (i am using Opengear
>> IMX4248):
>> >
>> > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002
>> ...
>> > default full { rw *; }
>> > default opengear { type host; portbase 3000; portinc 1; }
>> > default * {
>> > logfile /var/log/conserver;
>> > timestamp 1hab;
>> > include full;
>> > master localhost;
>> > }
>> > default console01 { include opengear; host console01; }
>> > console dr01.arista { include console01; port 1; }
>> > console dr02.arista { include console01; port 2; }
>> ...
>> > Has anyone gotten this to work using ssh?
>>
>> I think you need to use the exec host type and setup the right execsubst
>> to get ssh to use the right port number. The "host" type is just a raw
>> TCP socket connection.
>>
>> Nate
>> _______________________________________________
>> users mailing list
>> users@conserver.com
>> https://www.conserver.com/mailman/listinfo/users
>>
>
>
>
> --
>
> brandon
>



--

brandon

Also, how does the conserver.passwd work? When does it use that rather than
the authentication on the Opengear itself? To test, I have the same user on
the Opengear as well as in the conserver.passwd with different passwords to
see where it gets its passwords from. So far it just looks like it is using
the password from the Opengear. I configured conserver with all the
defaults so I am assuming conserver.passwd just needs to exist within the
same directory as conserver.cf. Did I configure something incorrectly or
does there need to be a line in the conserver.cf file to point to where
conserver.passwd exists?


On Mon, Apr 21, 2014 at 11:32 AM, Brandon Stout <bstout@squareup.com> wrote:

> So I actually figured out the problem so now it connects, I get the
> password prompt and when I enter it correctly it works. The problem is that
> when I disconnect and reconnect, it no longer asks me for a password and
> just puts me through to the console. is there some sort of disconnect I
> need to do manually to get it to reset and ask for a password? Seems like
> it just stays connected once the pw is entered, regardless of someone
> exiting.
>
>
> On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout <bstout@squareup.com>wrote:
>
>> thanks Nathan, I actually was trying that right after I sent this email
>> and added this
>>
>> default opengear-ssh { type exec; portbase 2000; portinc 1;
>> exec /usr/bin/ssh -p P -l tsuser H;
>> execsubst H=hs,P=Pd; }
>>
>> still not working though with just about nothing useful in the logs.
>> Doesn't hang but it still doesn't work. Just empty space and no output.
>>
>>
>> On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz <nstraz@redhat.com> wrote:
>>
>>> On Apr 21 10:29, Brandon Stout wrote:
>>> > hello, I am trying to use conserver to connect to serial ports over
>>> ssh and
>>> > it is hanging. When I go direct it works fine (i am using Opengear
>>> IMX4248):
>>> >
>>> > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002
>>> ...
>>> > default full { rw *; }
>>> > default opengear { type host; portbase 3000; portinc 1; }
>>> > default * {
>>> > logfile /var/log/conserver;
>>> > timestamp 1hab;
>>> > include full;
>>> > master localhost;
>>> > }
>>> > default console01 { include opengear; host console01; }
>>> > console dr01.arista { include console01; port 1; }
>>> > console dr02.arista { include console01; port 2; }
>>> ...
>>> > Has anyone gotten this to work using ssh?
>>>
>>> I think you need to use the exec host type and setup the right execsubst
>>> to get ssh to use the right port number. The "host" type is just a raw
>>> TCP socket connection.
>>>
>>> Nate
>>> _______________________________________________
>>> users mailing list
>>> users@conserver.com
>>> https://www.conserver.com/mailman/listinfo/users
>>>
>>
>>
>>
>> --
>>
>> brandon
>>
>
>
>
> --
>
> brandon
>



--

brandon

“Your milage may vary”, but for myself, I’m consoling UNIX servers, so I want their console output to be logged even when noone is connected. To accomplish this, I have a script that will log into the session for me upon initialization of the console, and then stay attached. As you’ve determined, conserver leaves the TCP connection active, so you don’t need to authenticate against the ssh connection again after the initial connection.

I suspect you’re not getting it to use the local/conserver password at all, or else when you first start up, you’d have to enter both, in the correct sequence. One to connect to the established ssh command, then another to ssh to authenticate the network connection.

So, I guess you need to decide whether you want to have the connection drop and reestablish, which is what you seemed to be asking for, or rather want just to get the conserver password prompting working, which I’m not doing, so can’t help with directly.

Thoughts and information that I hope is helpful.

- Chris

On Apr 21, 2014, at 14:38, Brandon Stout <bstout@squareup.com> wrote:

> Also, how does the conserver.passwd work? When does it use that rather than the authentication on the Opengear itself? To test, I have the same user on the Opengear as well as in the conserver.passwd with different passwords to see where it gets its passwords from. So far it just looks like it is using the password from the Opengear. I configured conserver with all the defaults so I am assuming conserver.passwd just needs to exist within the same directory as conserver.cf. Did I configure something incorrectly or does there need to be a line in the conserver.cf file to point to where conserver.passwd exists?
>
>
> On Mon, Apr 21, 2014 at 11:32 AM, Brandon Stout <bstout@squareup.com> wrote:
> So I actually figured out the problem so now it connects, I get the password prompt and when I enter it correctly it works. The problem is that when I disconnect and reconnect, it no longer asks me for a password and just puts me through to the console. is there some sort of disconnect I need to do manually to get it to reset and ask for a password? Seems like it just stays connected once the pw is entered, regardless of someone exiting.
>
>
> On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout <bstout@squareup.com> wrote:
> thanks Nathan, I actually was trying that right after I sent this email and added this
>
> default opengear-ssh { type exec; portbase 2000; portinc 1;
> exec /usr/bin/ssh -p P -l tsuser H;
> execsubst H=hs,P=Pd; }
>
> still not working though with just about nothing useful in the logs. Doesn't hang but it still doesn't work. Just empty space and no output.
>
>
> On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz <nstraz@redhat.com> wrote:
> On Apr 21 10:29, Brandon Stout wrote:
> > hello, I am trying to use conserver to connect to serial ports over ssh and
> > it is hanging. When I go direct it works fine (i am using Opengear IMX4248):
> >
> > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002
> ...
> > default full { rw *; }
> > default opengear { type host; portbase 3000; portinc 1; }
> > default * {
> > logfile /var/log/conserver;
> > timestamp 1hab;
> > include full;
> > master localhost;
> > }
> > default console01 { include opengear; host console01; }
> > console dr01.arista { include console01; port 1; }
> > console dr02.arista { include console01; port 2; }
> ...
> > Has anyone gotten this to work using ssh?
>
> I think you need to use the exec host type and setup the right execsubst
> to get ssh to use the right port number. The "host" type is just a raw
> TCP socket connection.
>
> Nate
> _______________________________________________
> users mailing list
> users@conserver.com
> https://www.conserver.com/mailman/listinfo/users
>
>
>
> --
>
> brandon
>
>
>
> --
>
> brandon
>
>
>
> --
>
> brandon
> _______________________________________________
> users mailing list
> users@conserver.com
> https://www.conserver.com/mailman/listinfo/users


_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users

Thanks for the reply Chris. You are correct, it is not using the
local/conserver password but just the console server (opengear) password. I
actually don't really care which password to use, as long as it asks for a
password anytime someone wants to connect to a console port. It works
correctly if you just ssh to the console via port 30xx. But when using
conserver, it just asks once and that is it. Looking at the logs, it looks
like it conserver tries to login to every port preemptively and keep it
open as opposed to just opening a session when someone asks for it. Is
there a way to change this behavior?


On Mon, Apr 21, 2014 at 12:13 PM, Chris Ross <cross+conserver@distal.com>wrote:

>
> “Your milage may vary”, but for myself, I’m consoling UNIX servers, so I
> want their console output to be logged even when noone is connected. To
> accomplish this, I have a script that will log into the session for me upon
> initialization of the console, and then stay attached. As you’ve
> determined, conserver leaves the TCP connection active, so you don’t need
> to authenticate against the ssh connection again after the initial
> connection.
>
> I suspect you’re not getting it to use the local/conserver password at
> all, or else when you first start up, you’d have to enter both, in the
> correct sequence. One to connect to the established ssh command, then
> another to ssh to authenticate the network connection.
>
> So, I guess you need to decide whether you want to have the connection
> drop and reestablish, which is what you seemed to be asking for, or rather
> want just to get the conserver password prompting working, which I’m not
> doing, so can’t help with directly.
>
> Thoughts and information that I hope is helpful.
>
> - Chris
>
> On Apr 21, 2014, at 14:38, Brandon Stout <bstout@squareup.com> wrote:
>
> > Also, how does the conserver.passwd work? When does it use that rather
> than the authentication on the Opengear itself? To test, I have the same
> user on the Opengear as well as in the conserver.passwd with different
> passwords to see where it gets its passwords from. So far it just looks
> like it is using the password from the Opengear. I configured conserver
> with all the defaults so I am assuming conserver.passwd just needs to exist
> within the same directory as conserver.cf. Did I configure something
> incorrectly or does there need to be a line in the conserver.cf file to
> point to where conserver.passwd exists?
> >
> >
> > On Mon, Apr 21, 2014 at 11:32 AM, Brandon Stout <bstout@squareup.com>
> wrote:
> > So I actually figured out the problem so now it connects, I get the
> password prompt and when I enter it correctly it works. The problem is that
> when I disconnect and reconnect, it no longer asks me for a password and
> just puts me through to the console. is there some sort of disconnect I
> need to do manually to get it to reset and ask for a password? Seems like
> it just stays connected once the pw is entered, regardless of someone
> exiting.
> >
> >
> > On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout <bstout@squareup.com>
> wrote:
> > thanks Nathan, I actually was trying that right after I sent this email
> and added this
> >
> > default opengear-ssh { type exec; portbase 2000; portinc 1;
> > exec /usr/bin/ssh -p P -l tsuser H;
> > execsubst H=hs,P=Pd; }
> >
> > still not working though with just about nothing useful in the logs.
> Doesn't hang but it still doesn't work. Just empty space and no output.
> >
> >
> > On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz <nstraz@redhat.com>
> wrote:
> > On Apr 21 10:29, Brandon Stout wrote:
> > > hello, I am trying to use conserver to connect to serial ports over
> ssh and
> > > it is hanging. When I go direct it works fine (i am using Opengear
> IMX4248):
> > >
> > > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002
> > ...
> > > default full { rw *; }
> > > default opengear { type host; portbase 3000; portinc 1; }
> > > default * {
> > > logfile /var/log/conserver;
> > > timestamp 1hab;
> > > include full;
> > > master localhost;
> > > }
> > > default console01 { include opengear; host console01; }
> > > console dr01.arista { include console01; port 1; }
> > > console dr02.arista { include console01; port 2; }
> > ...
> > > Has anyone gotten this to work using ssh?
> >
> > I think you need to use the exec host type and setup the right execsubst
> > to get ssh to use the right port number. The "host" type is just a raw
> > TCP socket connection.
> >
> > Nate
> > _______________________________________________
> > users mailing list
> > users@conserver.com
> > https://www.conserver.com/mailman/listinfo/users
> >
> >
> >
> > --
> >
> > brandon
> >
> >
> >
> > --
> >
> > brandon
> >
> >
> >
> > --
> >
> > brandon
> > _______________________________________________
> > users mailing list
> > users@conserver.com
> > https://www.conserver.com/mailman/listinfo/users
>
>


--

brandon

I don’t know, I’m afraid. You’re correct that that’s what it does. It’s designed and used as a console logging apparatus, as much as a console access mechanism. As I mentioned, that’s something I require of such a system myself. It’s where all of my console logs live. If you only want it to establish a connect in an on-demand basis, I would be surprised if there _wasn’t_ a way to do that, but I don’t know what it is myself.

Sorry I can’t help directly.

- Chris

On Apr 21, 2014, at 15:25, Brandon Stout <bstout@squareup.com> wrote:

> Thanks for the reply Chris. You are correct, it is not using the local/conserver password but just the console server (opengear) password. I actually don't really care which password to use, as long as it asks for a password anytime someone wants to connect to a console port. It works correctly if you just ssh to the console via port 30xx. But when using conserver, it just asks once and that is it. Looking at the logs, it looks like it conserver tries to login to every port preemptively and keep it open as opposed to just opening a session when someone asks for it. Is there a way to change this behavior?
>
>
> On Mon, Apr 21, 2014 at 12:13 PM, Chris Ross <cross+conserver@distal.com> wrote:
>
> “Your milage may vary”, but for myself, I’m consoling UNIX servers, so I want their console output to be logged even when noone is connected. To accomplish this, I have a script that will log into the session for me upon initialization of the console, and then stay attached. As you’ve determined, conserver leaves the TCP connection active, so you don’t need to authenticate against the ssh connection again after the initial connection.
>
> I suspect you’re not getting it to use the local/conserver password at all, or else when you first start up, you’d have to enter both, in the correct sequence. One to connect to the established ssh command, then another to ssh to authenticate the network connection.
>
> So, I guess you need to decide whether you want to have the connection drop and reestablish, which is what you seemed to be asking for, or rather want just to get the conserver password prompting working, which I’m not doing, so can’t help with directly.
>
> Thoughts and information that I hope is helpful.
>
> - Chris
>
> On Apr 21, 2014, at 14:38, Brandon Stout <bstout@squareup.com> wrote:
>
> > Also, how does the conserver.passwd work? When does it use that rather than the authentication on the Opengear itself? To test, I have the same user on the Opengear as well as in the conserver.passwd with different passwords to see where it gets its passwords from. So far it just looks like it is using the password from the Opengear. I configured conserver with all the defaults so I am assuming conserver.passwd just needs to exist within the same directory as conserver.cf. Did I configure something incorrectly or does there need to be a line in the conserver.cf file to point to where conserver.passwd exists?
> >
> >
> > On Mon, Apr 21, 2014 at 11:32 AM, Brandon Stout <bstout@squareup.com> wrote:
> > So I actually figured out the problem so now it connects, I get the password prompt and when I enter it correctly it works. The problem is that when I disconnect and reconnect, it no longer asks me for a password and just puts me through to the console. is there some sort of disconnect I need to do manually to get it to reset and ask for a password? Seems like it just stays connected once the pw is entered, regardless of someone exiting.
> >
> >
> > On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout <bstout@squareup.com> wrote:
> > thanks Nathan, I actually was trying that right after I sent this email and added this
> >
> > default opengear-ssh { type exec; portbase 2000; portinc 1;
> > exec /usr/bin/ssh -p P -l tsuser H;
> > execsubst H=hs,P=Pd; }
> >
> > still not working though with just about nothing useful in the logs. Doesn't hang but it still doesn't work. Just empty space and no output.
> >
> >
> > On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz <nstraz@redhat.com> wrote:
> > On Apr 21 10:29, Brandon Stout wrote:
> > > hello, I am trying to use conserver to connect to serial ports over ssh and
> > > it is hanging. When I go direct it works fine (i am using Opengear IMX4248):
> > >
> > > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002
> > ...
> > > default full { rw *; }
> > > default opengear { type host; portbase 3000; portinc 1; }
> > > default * {
> > > logfile /var/log/conserver;
> > > timestamp 1hab;
> > > include full;
> > > master localhost;
> > > }
> > > default console01 { include opengear; host console01; }
> > > console dr01.arista { include console01; port 1; }
> > > console dr02.arista { include console01; port 2; }
> > ...
> > > Has anyone gotten this to work using ssh?
> >
> > I think you need to use the exec host type and setup the right execsubst
> > to get ssh to use the right port number. The "host" type is just a raw
> > TCP socket connection.
> >
> > Nate
> > _______________________________________________
> > users mailing list
> > users@conserver.com
> > https://www.conserver.com/mailman/listinfo/users
> >
> >
> >
> > --
> >
> > brandon
> >
> >
> >
> > --
> >
> > brandon
> >
> >
> >
> > --
> >
> > brandon
> > _______________________________________________
> > users mailing list
> > users@conserver.com
> > https://www.conserver.com/mailman/listinfo/users
>
>
>
>
> --
>
> brandon


_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users

No problem, thanks for your knowledge though Chris.


On Mon, Apr 21, 2014 at 12:28 PM, Chris Ross <cross+conserver@distal.com>wrote:

>
> I don’t know, I’m afraid. You’re correct that that’s what it does.
> It’s designed and used as a console logging apparatus, as much as a
> console access mechanism. As I mentioned, that’s something I require of
> such a system myself. It’s where all of my console logs live. If you only
> want it to establish a connect in an on-demand basis, I would be surprised
> if there _wasn’t_ a way to do that, but I don’t know what it is myself.
>
> Sorry I can’t help directly.
>
> - Chris
>
> On Apr 21, 2014, at 15:25, Brandon Stout <bstout@squareup.com> wrote:
>
> > Thanks for the reply Chris. You are correct, it is not using the
> local/conserver password but just the console server (opengear) password. I
> actually don't really care which password to use, as long as it asks for a
> password anytime someone wants to connect to a console port. It works
> correctly if you just ssh to the console via port 30xx. But when using
> conserver, it just asks once and that is it. Looking at the logs, it looks
> like it conserver tries to login to every port preemptively and keep it
> open as opposed to just opening a session when someone asks for it. Is
> there a way to change this behavior?
> >
> >
> > On Mon, Apr 21, 2014 at 12:13 PM, Chris Ross <cross+conserver@distal.com>
> wrote:
> >
> > “Your milage may vary”, but for myself, I’m consoling UNIX servers, so
> I want their console output to be logged even when noone is connected. To
> accomplish this, I have a script that will log into the session for me upon
> initialization of the console, and then stay attached. As you’ve
> determined, conserver leaves the TCP connection active, so you don’t need
> to authenticate against the ssh connection again after the initial
> connection.
> >
> > I suspect you’re not getting it to use the local/conserver password at
> all, or else when you first start up, you’d have to enter both, in the
> correct sequence. One to connect to the established ssh command, then
> another to ssh to authenticate the network connection.
> >
> > So, I guess you need to decide whether you want to have the connection
> drop and reestablish, which is what you seemed to be asking for, or rather
> want just to get the conserver password prompting working, which I’m not
> doing, so can’t help with directly.
> >
> > Thoughts and information that I hope is helpful.
> >
> > - Chris
> >
> > On Apr 21, 2014, at 14:38, Brandon Stout <bstout@squareup.com> wrote:
> >
> > > Also, how does the conserver.passwd work? When does it use that rather
> than the authentication on the Opengear itself? To test, I have the same
> user on the Opengear as well as in the conserver.passwd with different
> passwords to see where it gets its passwords from. So far it just looks
> like it is using the password from the Opengear. I configured conserver
> with all the defaults so I am assuming conserver.passwd just needs to exist
> within the same directory as conserver.cf. Did I configure something
> incorrectly or does there need to be a line in the conserver.cf file to
> point to where conserver.passwd exists?
> > >
> > >
> > > On Mon, Apr 21, 2014 at 11:32 AM, Brandon Stout <bstout@squareup.com>
> wrote:
> > > So I actually figured out the problem so now it connects, I get the
> password prompt and when I enter it correctly it works. The problem is that
> when I disconnect and reconnect, it no longer asks me for a password and
> just puts me through to the console. is there some sort of disconnect I
> need to do manually to get it to reset and ask for a password? Seems like
> it just stays connected once the pw is entered, regardless of someone
> exiting.
> > >
> > >
> > > On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout <bstout@squareup.com>
> wrote:
> > > thanks Nathan, I actually was trying that right after I sent this
> email and added this
> > >
> > > default opengear-ssh { type exec; portbase 2000; portinc 1;
> > > exec /usr/bin/ssh -p P -l tsuser H;
> > > execsubst H=hs,P=Pd; }
> > >
> > > still not working though with just about nothing useful in the logs.
> Doesn't hang but it still doesn't work. Just empty space and no output.
> > >
> > >
> > > On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz <nstraz@redhat.com>
> wrote:
> > > On Apr 21 10:29, Brandon Stout wrote:
> > > > hello, I am trying to use conserver to connect to serial ports over
> ssh and
> > > > it is hanging. When I go direct it works fine (i am using Opengear
> IMX4248):
> > > >
> > > > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002
> > > ...
> > > > default full { rw *; }
> > > > default opengear { type host; portbase 3000; portinc 1; }
> > > > default * {
> > > > logfile /var/log/conserver;
> > > > timestamp 1hab;
> > > > include full;
> > > > master localhost;
> > > > }
> > > > default console01 { include opengear; host console01; }
> > > > console dr01.arista { include console01; port 1; }
> > > > console dr02.arista { include console01; port 2; }
> > > ...
> > > > Has anyone gotten this to work using ssh?
> > >
> > > I think you need to use the exec host type and setup the right
> execsubst
> > > to get ssh to use the right port number. The "host" type is just a raw
> > > TCP socket connection.
> > >
> > > Nate
> > > _______________________________________________
> > > users mailing list
> > > users@conserver.com
> > > https://www.conserver.com/mailman/listinfo/users
> > >
> > >
> > >
> > > --
> > >
> > > brandon
> > >
> > >
> > >
> > > --
> > >
> > > brandon
> > >
> > >
> > >
> > > --
> > >
> > > brandon
> > > _______________________________________________
> > > users mailing list
> > > users@conserver.com
> > > https://www.conserver.com/mailman/listinfo/users
> >
> >
> >
> >
> > --
> >
> > brandon
>
>


--

brandon

On Apr 21 12:25, Brandon Stout wrote:
> Thanks for the reply Chris. You are correct, it is not using the
> local/conserver password but just the console server (opengear) password. I
> actually don't really care which password to use, as long as it asks for a
> password anytime someone wants to connect to a console port.

You want to use "options ondemand."

Nate
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users

Chris Ross is correct... The model of conserver connecting (and then
trying to maintain connection) is built around the model that a sysadmin
wants to capture any messages that a console may cough up (memory error at
0x23484325, root volume at 98%, core dumped, etc.), so that when a system
fails to respond on the network, and you try to use the console only to
find it unresponsive... THEN is when we are glad that we can tail the log
file for that device, and see what was happening! :-)

Once we see the problem, we can then grep the logs for similar machines,
and see if we see any of the early signs of pending failure on similar
devices in our collection. :-)


Using ssh is a way to encrypt the data between the console server and the
conserver host. But, as you scale up (think many dozens of console servers,
and thousands of ports), consider that SSH on each of those connections is
a lot more overhead. Many shops use a dedicated management subnet and use
the telnet option instead.

The conserver.passwd is a good option when you want to give someone
console access, but not give them shell access on your NIS network. By
giving them an account local to your conserver host, and using the local
password file, they can access consoles, and no more.

In one case, where I needed to give contractors access to *some*
consoles, I installed conserver where the contractors had access (rather
than letting them have access to my primary logs), and had this
conserver.passwd;

cat /usr/local/etc/conserver.passwd
# Users can either have a pre-defined account name here,
# or they can refer to an existing shell account...
# for Shell accounts, "*passwd*" means to use their shell passwd
# Or, you can enforce a pre-assigned password, by adding a crypted string
# (this bypasses the shell passwd, forcing them to use the console passwd)
# perl -e 'print crypt("password","Ah")."\n";'
# The "Ah" picks the first two characters of the password, and is the
"salt"
# used for the crypt...
root:
temp_FE:ceOfgr9fefOqNw
# Contractor users must come to their consoles from a CLUSTER_HOST
v-prtent:*passwd*
v-boulder:*passwd*
*any*:*passwd*

Also, "temp_FE" was an account when they needed someone more random to come
in and work on the devices, and we could change that password at will.

Best regards,

-Z-



On Mon, Apr 21, 2014 at 12:25 PM, Brandon Stout <bstout@squareup.com> wrote:

> Thanks for the reply Chris. You are correct, it is not using the
> local/conserver password but just the console server (opengear) password. I
> actually don't really care which password to use, as long as it asks for a
> password anytime someone wants to connect to a console port. It works
> correctly if you just ssh to the console via port 30xx. But when using
> conserver, it just asks once and that is it. Looking at the logs, it looks
> like it conserver tries to login to every port preemptively and keep it
> open as opposed to just opening a session when someone asks for it. Is
> there a way to change this behavior?
>
>
> On Mon, Apr 21, 2014 at 12:13 PM, Chris Ross <cross+conserver@distal.com>wrote:
>
>>
>> “Your milage may vary”, but for myself, I’m consoling UNIX servers, so
>> I want their console output to be logged even when noone is connected. To
>> accomplish this, I have a script that will log into the session for me upon
>> initialization of the console, and then stay attached. As you’ve
>> determined, conserver leaves the TCP connection active, so you don’t need
>> to authenticate against the ssh connection again after the initial
>> connection.
>>
>> I suspect you’re not getting it to use the local/conserver password at
>> all, or else when you first start up, you’d have to enter both, in the
>> correct sequence. One to connect to the established ssh command, then
>> another to ssh to authenticate the network connection.
>>
>> So, I guess you need to decide whether you want to have the connection
>> drop and reestablish, which is what you seemed to be asking for, or rather
>> want just to get the conserver password prompting working, which I’m not
>> doing, so can’t help with directly.
>>
>> Thoughts and information that I hope is helpful.
>>
>> - Chris
>>
>> On Apr 21, 2014, at 14:38, Brandon Stout <bstout@squareup.com> wrote:
>>
>> > Also, how does the conserver.passwd work? When does it use that rather
>> than the authentication on the Opengear itself? To test, I have the same
>> user on the Opengear as well as in the conserver.passwd with different
>> passwords to see where it gets its passwords from. So far it just looks
>> like it is using the password from the Opengear. I configured conserver
>> with all the defaults so I am assuming conserver.passwd just needs to exist
>> within the same directory as conserver.cf. Did I configure something
>> incorrectly or does there need to be a line in the conserver.cf file to
>> point to where conserver.passwd exists?
>> >
>> >
>> > On Mon, Apr 21, 2014 at 11:32 AM, Brandon Stout <bstout@squareup.com>
>> wrote:
>> > So I actually figured out the problem so now it connects, I get the
>> password prompt and when I enter it correctly it works. The problem is that
>> when I disconnect and reconnect, it no longer asks me for a password and
>> just puts me through to the console. is there some sort of disconnect I
>> need to do manually to get it to reset and ask for a password? Seems like
>> it just stays connected once the pw is entered, regardless of someone
>> exiting.
>> >
>> >
>> > On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout <bstout@squareup.com>
>> wrote:
>> > thanks Nathan, I actually was trying that right after I sent this email
>> and added this
>> >
>> > default opengear-ssh { type exec; portbase 2000; portinc 1;
>> > exec /usr/bin/ssh -p P -l tsuser H;
>> > execsubst H=hs,P=Pd; }
>> >
>> > still not working though with just about nothing useful in the logs.
>> Doesn't hang but it still doesn't work. Just empty space and no output.
>> >
>> >
>> > On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz <nstraz@redhat.com>
>> wrote:
>> > On Apr 21 10:29, Brandon Stout wrote:
>> > > hello, I am trying to use conserver to connect to serial ports over
>> ssh and
>> > > it is hanging. When I go direct it works fine (i am using Opengear
>> IMX4248):
>> > >
>> > > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002
>> > ...
>> > > default full { rw *; }
>> > > default opengear { type host; portbase 3000; portinc 1; }
>> > > default * {
>> > > logfile /var/log/conserver;
>> > > timestamp 1hab;
>> > > include full;
>> > > master localhost;
>> > > }
>> > > default console01 { include opengear; host console01; }
>> > > console dr01.arista { include console01; port 1; }
>> > > console dr02.arista { include console01; port 2; }
>> > ...
>> > > Has anyone gotten this to work using ssh?
>> >
>> > I think you need to use the exec host type and setup the right execsubst
>> > to get ssh to use the right port number. The "host" type is just a raw
>> > TCP socket connection.
>> >
>> > Nate
>> > _______________________________________________
>> > users mailing list
>> > users@conserver.com
>> > https://www.conserver.com/mailman/listinfo/users
>> >
>> >
>> >
>> > --
>> >
>> > brandon
>> >
>> >
>> >
>> > --
>> >
>> > brandon
>> >
>> >
>> >
>> > --
>> >
>> > brandon
>> > _______________________________________________
>> > users mailing list
>> > users@conserver.com
>> > https://www.conserver.com/mailman/listinfo/users
>>
>>
>
>
> --
>
> brandon
>
> _______________________________________________
> users mailing list
> users@conserver.com
> https://www.conserver.com/mailman/listinfo/users
>
>


--
Sent from my new iPhone 6 Watch (prototype), see my reviews here!
www.conserver.com/consoles/ -- consoleteam.blogspot.com
- - - - - - - -
www.ncry.org
www.d4tm.org
www.hackerdojo.com

Nathan, that worked. Thanks a bunch.


On Mon, Apr 21, 2014 at 12:42 PM, Nathan Straz <nstraz@redhat.com> wrote:

> On Apr 21 12:25, Brandon Stout wrote:
> > Thanks for the reply Chris. You are correct, it is not using the
> > local/conserver password but just the console server (opengear)
> password. I
> > actually don't really care which password to use, as long as it asks for
> a
> > password anytime someone wants to connect to a console port.
>
> You want to use "options ondemand."
>
> Nate
>



--

brandon

Hey Z,

This all makes sense, thanks for the info. From an conserver.passwd
perspective, is the location and usage of the file need to be called out in
the conserver.cf file or should it automatically use it for authentication?
Right now I have it working being authenticated by the Opengear but want to
test to see if I can get it working using this file. Is there something I
needed to do to get conserver to use the file?

thanks
Brandon


On Mon, Apr 21, 2014 at 1:35 PM, Zonker <consoleteam@gmail.com> wrote:

> Chris Ross is correct... The model of conserver connecting (and then
> trying to maintain connection) is built around the model that a sysadmin
> wants to capture any messages that a console may cough up (memory error at
> 0x23484325, root volume at 98%, core dumped, etc.), so that when a system
> fails to respond on the network, and you try to use the console only to
> find it unresponsive... THEN is when we are glad that we can tail the log
> file for that device, and see what was happening! :-)
>
> Once we see the problem, we can then grep the logs for similar machines,
> and see if we see any of the early signs of pending failure on similar
> devices in our collection. :-)
>
>
> Using ssh is a way to encrypt the data between the console server and
> the conserver host. But, as you scale up (think many dozens of console
> servers, and thousands of ports), consider that SSH on each of those
> connections is a lot more overhead. Many shops use a dedicated management
> subnet and use the telnet option instead.
>
> The conserver.passwd is a good option when you want to give someone
> console access, but not give them shell access on your NIS network. By
> giving them an account local to your conserver host, and using the local
> password file, they can access consoles, and no more.
>
> In one case, where I needed to give contractors access to *some*
> consoles, I installed conserver where the contractors had access (rather
> than letting them have access to my primary logs), and had this
> conserver.passwd;
>
> cat /usr/local/etc/conserver.passwd
> # Users can either have a pre-defined account name here,
> # or they can refer to an existing shell account...
> # for Shell accounts, "*passwd*" means to use their shell passwd
> # Or, you can enforce a pre-assigned password, by adding a crypted string
> # (this bypasses the shell passwd, forcing them to use the console passwd)
> # perl -e 'print crypt("password","Ah")."\n";'
> # The "Ah" picks the first two characters of the password, and is the
> "salt"
> # used for the crypt...
> root:
> temp_FE:ceOfgr9fefOqNw
> # Contractor users must come to their consoles from a CLUSTER_HOST
> v-prtent:*passwd*
> v-boulder:*passwd*
> *any*:*passwd*
>
> Also, "temp_FE" was an account when they needed someone more random to
> come in and work on the devices, and we could change that password at will.
>
> Best regards,
>
> -Z-
>
>
>
> On Mon, Apr 21, 2014 at 12:25 PM, Brandon Stout <bstout@squareup.com>wrote:
>
>> Thanks for the reply Chris. You are correct, it is not using the
>> local/conserver password but just the console server (opengear) password. I
>> actually don't really care which password to use, as long as it asks for a
>> password anytime someone wants to connect to a console port. It works
>> correctly if you just ssh to the console via port 30xx. But when using
>> conserver, it just asks once and that is it. Looking at the logs, it looks
>> like it conserver tries to login to every port preemptively and keep it
>> open as opposed to just opening a session when someone asks for it. Is
>> there a way to change this behavior?
>>
>>
>> On Mon, Apr 21, 2014 at 12:13 PM, Chris Ross <cross+conserver@distal.com>wrote:
>>
>>>
>>> “Your milage may vary”, but for myself, I’m consoling UNIX servers, so
>>> I want their console output to be logged even when noone is connected. To
>>> accomplish this, I have a script that will log into the session for me upon
>>> initialization of the console, and then stay attached. As you’ve
>>> determined, conserver leaves the TCP connection active, so you don’t need
>>> to authenticate against the ssh connection again after the initial
>>> connection.
>>>
>>> I suspect you’re not getting it to use the local/conserver password at
>>> all, or else when you first start up, you’d have to enter both, in the
>>> correct sequence. One to connect to the established ssh command, then
>>> another to ssh to authenticate the network connection.
>>>
>>> So, I guess you need to decide whether you want to have the connection
>>> drop and reestablish, which is what you seemed to be asking for, or rather
>>> want just to get the conserver password prompting working, which I’m not
>>> doing, so can’t help with directly.
>>>
>>> Thoughts and information that I hope is helpful.
>>>
>>> - Chris
>>>
>>> On Apr 21, 2014, at 14:38, Brandon Stout <bstout@squareup.com> wrote:
>>>
>>> > Also, how does the conserver.passwd work? When does it use that rather
>>> than the authentication on the Opengear itself? To test, I have the same
>>> user on the Opengear as well as in the conserver.passwd with different
>>> passwords to see where it gets its passwords from. So far it just looks
>>> like it is using the password from the Opengear. I configured conserver
>>> with all the defaults so I am assuming conserver.passwd just needs to exist
>>> within the same directory as conserver.cf. Did I configure something
>>> incorrectly or does there need to be a line in the conserver.cf file to
>>> point to where conserver.passwd exists?
>>> >
>>> >
>>> > On Mon, Apr 21, 2014 at 11:32 AM, Brandon Stout <bstout@squareup.com>
>>> wrote:
>>> > So I actually figured out the problem so now it connects, I get the
>>> password prompt and when I enter it correctly it works. The problem is that
>>> when I disconnect and reconnect, it no longer asks me for a password and
>>> just puts me through to the console. is there some sort of disconnect I
>>> need to do manually to get it to reset and ask for a password? Seems like
>>> it just stays connected once the pw is entered, regardless of someone
>>> exiting.
>>> >
>>> >
>>> > On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout <bstout@squareup.com>
>>> wrote:
>>> > thanks Nathan, I actually was trying that right after I sent this
>>> email and added this
>>> >
>>> > default opengear-ssh { type exec; portbase 2000; portinc 1;
>>> > exec /usr/bin/ssh -p P -l tsuser H;
>>> > execsubst H=hs,P=Pd; }
>>> >
>>> > still not working though with just about nothing useful in the logs.
>>> Doesn't hang but it still doesn't work. Just empty space and no output.
>>> >
>>> >
>>> > On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz <nstraz@redhat.com>
>>> wrote:
>>> > On Apr 21 10:29, Brandon Stout wrote:
>>> > > hello, I am trying to use conserver to connect to serial ports over
>>> ssh and
>>> > > it is hanging. When I go direct it works fine (i am using Opengear
>>> IMX4248):
>>> > >
>>> > > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002
>>> > ...
>>> > > default full { rw *; }
>>> > > default opengear { type host; portbase 3000; portinc 1; }
>>> > > default * {
>>> > > logfile /var/log/conserver;
>>> > > timestamp 1hab;
>>> > > include full;
>>> > > master localhost;
>>> > > }
>>> > > default console01 { include opengear; host console01; }
>>> > > console dr01.arista { include console01; port 1; }
>>> > > console dr02.arista { include console01; port 2; }
>>> > ...
>>> > > Has anyone gotten this to work using ssh?
>>> >
>>> > I think you need to use the exec host type and setup the right
>>> execsubst
>>> > to get ssh to use the right port number. The "host" type is just a raw
>>> > TCP socket connection.
>>> >
>>> > Nate
>>> > _______________________________________________
>>> > users mailing list
>>> > users@conserver.com
>>> > https://www.conserver.com/mailman/listinfo/users
>>> >
>>> >
>>> >
>>> > --
>>> >
>>> > brandon
>>> >
>>> >
>>> >
>>> > --
>>> >
>>> > brandon
>>> >
>>> >
>>> >
>>> > --
>>> >
>>> > brandon
>>> > _______________________________________________
>>> > users mailing list
>>> > users@conserver.com
>>> > https://www.conserver.com/mailman/listinfo/users
>>>
>>>
>>
>>
>> --
>>
>> brandon
>>
>> _______________________________________________
>> users mailing list
>> users@conserver.com
>> https://www.conserver.com/mailman/listinfo/users
>>
>>
>
>
> --
> Sent from my new iPhone 6 Watch (prototype), see my reviews here!
> www.conserver.com/consoles/ -- consoleteam.blogspot.com
> - - - - - - - -
> www.ncry.org
> www.d4tm.org
> www.hackerdojo.com
>



--

brandon

Try thinking of authentication in the following model...

1) A secure connection from the Conserver host to the console server(s).
(Management net, maybe static routes instead of defaults, SSH if
needed)
- Conserver opens a conenction for every configured port, and
starts logging.
2) User access to the console sessions.
- Maybe the SSH to the conserver, or they have a console client on
their host
- Users "connect" to a given console session... conserver "tees"
them in.
( User types, data goes to the console... device sends data back,
conserver logs it and forwards the data to the user.)

In this model, only Conserver would need to know how to log into the
console server. (I make sure my console servers only allow one connection
per serial port in the reverse-TCP mode. This way, if anyone else know how
to access that port and has the credentials, they would be unable to
connect of Conserver got their first.

Also in this model, users would authenticate on Conserver... either by
SSH to the Conserver host, or with their own conserver client. In the
latter case, the client users need to validate with conserver when they
make the connection, and this would be checked in the conserver.passwd file.

It's been a great model for many types of administration. But, if it's
not for you, perhaps you can share what make your scenario
different/difficult?

Best regards,

-Z- http://www.conserver.com/consoles/

You may find a couple of my older LISA tutorials useful, and you can find
them at
http://www.conserver.com/consoles/Training/published.html



On Mon, Apr 21, 2014 at 2:13 PM, Brandon Stout <bstout@squareup.com> wrote:

> Hey Z,
>
> This all makes sense, thanks for the info. From an conserver.passwd
> perspective, is the location and usage of the file need to be called out in
> the conserver.cf file or should it automatically use it for
> authentication? Right now I have it working being authenticated by the
> Opengear but want to test to see if I can get it working using this file.
> Is there something I needed to do to get conserver to use the file?
>
> thanks
> Brandon
>
>
> On Mon, Apr 21, 2014 at 1:35 PM, Zonker <consoleteam@gmail.com> wrote:
>
>> Chris Ross is correct... The model of conserver connecting (and then
>> trying to maintain connection) is built around the model that a sysadmin
>> wants to capture any messages that a console may cough up (memory error at
>> 0x23484325, root volume at 98%, core dumped, etc.), so that when a system
>> fails to respond on the network, and you try to use the console only to
>> find it unresponsive... THEN is when we are glad that we can tail the log
>> file for that device, and see what was happening! :-)
>>
>> Once we see the problem, we can then grep the logs for similar
>> machines, and see if we see any of the early signs of pending failure on
>> similar devices in our collection. :-)
>>
>>
>> Using ssh is a way to encrypt the data between the console server and
>> the conserver host. But, as you scale up (think many dozens of console
>> servers, and thousands of ports), consider that SSH on each of those
>> connections is a lot more overhead. Many shops use a dedicated management
>> subnet and use the telnet option instead.
>>
>> The conserver.passwd is a good option when you want to give someone
>> console access, but not give them shell access on your NIS network. By
>> giving them an account local to your conserver host, and using the local
>> password file, they can access consoles, and no more.
>>
>> In one case, where I needed to give contractors access to *some*
>> consoles, I installed conserver where the contractors had access (rather
>> than letting them have access to my primary logs), and had this
>> conserver.passwd;
>>
>> cat /usr/local/etc/conserver.passwd
>> # Users can either have a pre-defined account name here,
>> # or they can refer to an existing shell account...
>> # for Shell accounts, "*passwd*" means to use their shell passwd
>> # Or, you can enforce a pre-assigned password, by adding a crypted string
>> # (this bypasses the shell passwd, forcing them to use the console
>> passwd)
>> # perl -e 'print crypt("password","Ah")."\n";'
>> # The "Ah" picks the first two characters of the password, and is the
>> "salt"
>> # used for the crypt...
>> root:
>> temp_FE:ceOfgr9fefOqNw
>> # Contractor users must come to their consoles from a CLUSTER_HOST
>> v-prtent:*passwd*
>> v-boulder:*passwd*
>> *any*:*passwd*
>>
>> Also, "temp_FE" was an account when they needed someone more random to
>> come in and work on the devices, and we could change that password at will.
>>
>> Best regards,
>>
>> -Z-
>>
>>
>>
>> On Mon, Apr 21, 2014 at 12:25 PM, Brandon Stout <bstout@squareup.com>wrote:
>>
>>> Thanks for the reply Chris. You are correct, it is not using the
>>> local/conserver password but just the console server (opengear) password. I
>>> actually don't really care which password to use, as long as it asks for a
>>> password anytime someone wants to connect to a console port. It works
>>> correctly if you just ssh to the console via port 30xx. But when using
>>> conserver, it just asks once and that is it. Looking at the logs, it looks
>>> like it conserver tries to login to every port preemptively and keep it
>>> open as opposed to just opening a session when someone asks for it. Is
>>> there a way to change this behavior?
>>>
>>>
>>> On Mon, Apr 21, 2014 at 12:13 PM, Chris Ross <cross+conserver@distal.com
>>> > wrote:
>>>
>>>>
>>>> “Your milage may vary”, but for myself, I’m consoling UNIX servers,
>>>> so I want their console output to be logged even when noone is connected.
>>>> To accomplish this, I have a script that will log into the session for me
>>>> upon initialization of the console, and then stay attached. As you’ve
>>>> determined, conserver leaves the TCP connection active, so you don’t need
>>>> to authenticate against the ssh connection again after the initial
>>>> connection.
>>>>
>>>> I suspect you’re not getting it to use the local/conserver password
>>>> at all, or else when you first start up, you’d have to enter both, in the
>>>> correct sequence. One to connect to the established ssh command, then
>>>> another to ssh to authenticate the network connection.
>>>>
>>>> So, I guess you need to decide whether you want to have the
>>>> connection drop and reestablish, which is what you seemed to be asking for,
>>>> or rather want just to get the conserver password prompting working, which
>>>> I’m not doing, so can’t help with directly.
>>>>
>>>> Thoughts and information that I hope is helpful.
>>>>
>>>> - Chris
>>>>
>>>> On Apr 21, 2014, at 14:38, Brandon Stout <bstout@squareup.com> wrote:
>>>>
>>>> > Also, how does the conserver.passwd work? When does it use that
>>>> rather than the authentication on the Opengear itself? To test, I have the
>>>> same user on the Opengear as well as in the conserver.passwd with different
>>>> passwords to see where it gets its passwords from. So far it just looks
>>>> like it is using the password from the Opengear. I configured conserver
>>>> with all the defaults so I am assuming conserver.passwd just needs to exist
>>>> within the same directory as conserver.cf. Did I configure something
>>>> incorrectly or does there need to be a line in the conserver.cf file
>>>> to point to where conserver.passwd exists?
>>>> >
>>>> >
>>>> > On Mon, Apr 21, 2014 at 11:32 AM, Brandon Stout <bstout@squareup.com>
>>>> wrote:
>>>> > So I actually figured out the problem so now it connects, I get the
>>>> password prompt and when I enter it correctly it works. The problem is that
>>>> when I disconnect and reconnect, it no longer asks me for a password and
>>>> just puts me through to the console. is there some sort of disconnect I
>>>> need to do manually to get it to reset and ask for a password? Seems like
>>>> it just stays connected once the pw is entered, regardless of someone
>>>> exiting.
>>>> >
>>>> >
>>>> > On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout <bstout@squareup.com>
>>>> wrote:
>>>> > thanks Nathan, I actually was trying that right after I sent this
>>>> email and added this
>>>> >
>>>> > default opengear-ssh { type exec; portbase 2000; portinc 1;
>>>> > exec /usr/bin/ssh -p P -l tsuser H;
>>>> > execsubst H=hs,P=Pd; }
>>>> >
>>>> > still not working though with just about nothing useful in the logs.
>>>> Doesn't hang but it still doesn't work. Just empty space and no output.
>>>> >
>>>> >
>>>> > On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz <nstraz@redhat.com>
>>>> wrote:
>>>> > On Apr 21 10:29, Brandon Stout wrote:
>>>> > > hello, I am trying to use conserver to connect to serial ports over
>>>> ssh and
>>>> > > it is hanging. When I go direct it works fine (i am using Opengear
>>>> IMX4248):
>>>> > >
>>>> > > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002
>>>> > ...
>>>> > > default full { rw *; }
>>>> > > default opengear { type host; portbase 3000; portinc 1; }
>>>> > > default * {
>>>> > > logfile /var/log/conserver;
>>>> > > timestamp 1hab;
>>>> > > include full;
>>>> > > master localhost;
>>>> > > }
>>>> > > default console01 { include opengear; host console01; }
>>>> > > console dr01.arista { include console01; port 1; }
>>>> > > console dr02.arista { include console01; port 2; }
>>>> > ...
>>>> > > Has anyone gotten this to work using ssh?
>>>> >
>>>> > I think you need to use the exec host type and setup the right
>>>> execsubst
>>>> > to get ssh to use the right port number. The "host" type is just a
>>>> raw
>>>> > TCP socket connection.
>>>> >
>>>> > Nate
>>>> > _______________________________________________
>>>> > users mailing list
>>>> > users@conserver.com
>>>> > https://www.conserver.com/mailman/listinfo/users
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> >
>>>> > brandon
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> >
>>>> > brandon
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> >
>>>> > brandon
>>>> > _______________________________________________
>>>> > users mailing list
>>>> > users@conserver.com
>>>> > https://www.conserver.com/mailman/listinfo/users
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> brandon
>>>
>>> _______________________________________________
>>> users mailing list
>>> users@conserver.com
>>> https://www.conserver.com/mailman/listinfo/users
>>>
>>>
>>
>>
>> --
>> Sent from my new iPhone 6 Watch (prototype), see my reviews here!
>> www.conserver.com/consoles/ -- consoleteam.blogspot.com
>> - - - - - - - -
>> www.ncry.org
>> www.d4tm.org
>> www.hackerdojo.com
>>
>
>
>
> --
>
> brandon
>



--
Sent from my new iPhone 6 Watch (prototype), see my reviews here!
www.conserver.com/consoles/ -- consoleteam.blogspot.com
- - - - - - - -
www.ncry.org
www.d4tm.org
www.hackerdojo.com

Hey Z,

This is starting to make a lot more sense. Thanks for the email. It sounds
like I may not be able to use it exactly how I wanted to but I can get by
with local user/pw on the console server if this is the case. I am using
the conserver as both conserver host and conserver client, by which a user
will logon to this host to gain console access only to console servers
configured locally (nothing distributed). The server is also used for other
functions so other users have access to the box who I don't want to have
access to the consoles. I was trying to control access via conserver.passwd
but it sounds like that is only used for conserver clients outside of the
conserver. It seems as though I will just need to create individual
accounts on the console server itself and control access there.

thanks
Brandon


On Mon, Apr 21, 2014 at 3:37 PM, Zonker <consoleteam@gmail.com> wrote:

> Try thinking of authentication in the following model...
>
> 1) A secure connection from the Conserver host to the console server(s).
> (Management net, maybe static routes instead of defaults, SSH if
> needed)
> - Conserver opens a conenction for every configured port, and
> starts logging.
> 2) User access to the console sessions.
> - Maybe the SSH to the conserver, or they have a console client
> on their host
> - Users "connect" to a given console session... conserver "tees"
> them in.
> ( User types, data goes to the console... device sends data back,
> conserver logs it and forwards the data to the user.)
>
> In this model, only Conserver would need to know how to log into the
> console server. (I make sure my console servers only allow one connection
> per serial port in the reverse-TCP mode. This way, if anyone else know how
> to access that port and has the credentials, they would be unable to
> connect of Conserver got their first.
>
> Also in this model, users would authenticate on Conserver... either by
> SSH to the Conserver host, or with their own conserver client. In the
> latter case, the client users need to validate with conserver when they
> make the connection, and this would be checked in the conserver.passwd file.
>
> It's been a great model for many types of administration. But, if it's
> not for you, perhaps you can share what make your scenario
> different/difficult?
>
> Best regards,
>
> -Z- http://www.conserver.com/consoles/
>
> You may find a couple of my older LISA tutorials useful, and you can
> find them at
> http://www.conserver.com/consoles/Training/published.html
>
>
>
> On Mon, Apr 21, 2014 at 2:13 PM, Brandon Stout <bstout@squareup.com>wrote:
>
>> Hey Z,
>>
>> This all makes sense, thanks for the info. From an conserver.passwd
>> perspective, is the location and usage of the file need to be called out in
>> the conserver.cf file or should it automatically use it for
>> authentication? Right now I have it working being authenticated by the
>> Opengear but want to test to see if I can get it working using this file.
>> Is there something I needed to do to get conserver to use the file?
>>
>> thanks
>> Brandon
>>
>>
>> On Mon, Apr 21, 2014 at 1:35 PM, Zonker <consoleteam@gmail.com> wrote:
>>
>>> Chris Ross is correct... The model of conserver connecting (and then
>>> trying to maintain connection) is built around the model that a sysadmin
>>> wants to capture any messages that a console may cough up (memory error at
>>> 0x23484325, root volume at 98%, core dumped, etc.), so that when a system
>>> fails to respond on the network, and you try to use the console only to
>>> find it unresponsive... THEN is when we are glad that we can tail the log
>>> file for that device, and see what was happening! :-)
>>>
>>> Once we see the problem, we can then grep the logs for similar
>>> machines, and see if we see any of the early signs of pending failure on
>>> similar devices in our collection. :-)
>>>
>>>
>>> Using ssh is a way to encrypt the data between the console server and
>>> the conserver host. But, as you scale up (think many dozens of console
>>> servers, and thousands of ports), consider that SSH on each of those
>>> connections is a lot more overhead. Many shops use a dedicated management
>>> subnet and use the telnet option instead.
>>>
>>> The conserver.passwd is a good option when you want to give someone
>>> console access, but not give them shell access on your NIS network. By
>>> giving them an account local to your conserver host, and using the local
>>> password file, they can access consoles, and no more.
>>>
>>> In one case, where I needed to give contractors access to *some*
>>> consoles, I installed conserver where the contractors had access (rather
>>> than letting them have access to my primary logs), and had this
>>> conserver.passwd;
>>>
>>> cat /usr/local/etc/conserver.passwd
>>> # Users can either have a pre-defined account name here,
>>> # or they can refer to an existing shell account...
>>> # for Shell accounts, "*passwd*" means to use their shell passwd
>>> # Or, you can enforce a pre-assigned password, by adding a crypted string
>>> # (this bypasses the shell passwd, forcing them to use the console
>>> passwd)
>>> # perl -e 'print crypt("password","Ah")."\n";'
>>> # The "Ah" picks the first two characters of the password, and is the
>>> "salt"
>>> # used for the crypt...
>>> root:
>>> temp_FE:ceOfgr9fefOqNw
>>> # Contractor users must come to their consoles from a CLUSTER_HOST
>>> v-prtent:*passwd*
>>> v-boulder:*passwd*
>>> *any*:*passwd*
>>>
>>> Also, "temp_FE" was an account when they needed someone more random to
>>> come in and work on the devices, and we could change that password at will.
>>>
>>> Best regards,
>>>
>>> -Z-
>>>
>>>
>>>
>>> On Mon, Apr 21, 2014 at 12:25 PM, Brandon Stout <bstout@squareup.com>wrote:
>>>
>>>> Thanks for the reply Chris. You are correct, it is not using the
>>>> local/conserver password but just the console server (opengear) password. I
>>>> actually don't really care which password to use, as long as it asks for a
>>>> password anytime someone wants to connect to a console port. It works
>>>> correctly if you just ssh to the console via port 30xx. But when using
>>>> conserver, it just asks once and that is it. Looking at the logs, it looks
>>>> like it conserver tries to login to every port preemptively and keep it
>>>> open as opposed to just opening a session when someone asks for it. Is
>>>> there a way to change this behavior?
>>>>
>>>>
>>>> On Mon, Apr 21, 2014 at 12:13 PM, Chris Ross <
>>>> cross+conserver@distal.com> wrote:
>>>>
>>>>>
>>>>> “Your milage may vary”, but for myself, I’m consoling UNIX servers,
>>>>> so I want their console output to be logged even when noone is connected.
>>>>> To accomplish this, I have a script that will log into the session for me
>>>>> upon initialization of the console, and then stay attached. As you’ve
>>>>> determined, conserver leaves the TCP connection active, so you don’t need
>>>>> to authenticate against the ssh connection again after the initial
>>>>> connection.
>>>>>
>>>>> I suspect you’re not getting it to use the local/conserver password
>>>>> at all, or else when you first start up, you’d have to enter both, in the
>>>>> correct sequence. One to connect to the established ssh command, then
>>>>> another to ssh to authenticate the network connection.
>>>>>
>>>>> So, I guess you need to decide whether you want to have the
>>>>> connection drop and reestablish, which is what you seemed to be asking for,
>>>>> or rather want just to get the conserver password prompting working, which
>>>>> I’m not doing, so can’t help with directly.
>>>>>
>>>>> Thoughts and information that I hope is helpful.
>>>>>
>>>>> - Chris
>>>>>
>>>>> On Apr 21, 2014, at 14:38, Brandon Stout <bstout@squareup.com> wrote:
>>>>>
>>>>> > Also, how does the conserver.passwd work? When does it use that
>>>>> rather than the authentication on the Opengear itself? To test, I have the
>>>>> same user on the Opengear as well as in the conserver.passwd with different
>>>>> passwords to see where it gets its passwords from. So far it just looks
>>>>> like it is using the password from the Opengear. I configured conserver
>>>>> with all the defaults so I am assuming conserver.passwd just needs to exist
>>>>> within the same directory as conserver.cf. Did I configure something
>>>>> incorrectly or does there need to be a line in the conserver.cf file
>>>>> to point to where conserver.passwd exists?
>>>>> >
>>>>> >
>>>>> > On Mon, Apr 21, 2014 at 11:32 AM, Brandon Stout <bstout@squareup.com>
>>>>> wrote:
>>>>> > So I actually figured out the problem so now it connects, I get the
>>>>> password prompt and when I enter it correctly it works. The problem is that
>>>>> when I disconnect and reconnect, it no longer asks me for a password and
>>>>> just puts me through to the console. is there some sort of disconnect I
>>>>> need to do manually to get it to reset and ask for a password? Seems like
>>>>> it just stays connected once the pw is entered, regardless of someone
>>>>> exiting.
>>>>> >
>>>>> >
>>>>> > On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout <bstout@squareup.com>
>>>>> wrote:
>>>>> > thanks Nathan, I actually was trying that right after I sent this
>>>>> email and added this
>>>>> >
>>>>> > default opengear-ssh { type exec; portbase 2000; portinc 1;
>>>>> > exec /usr/bin/ssh -p P -l tsuser H;
>>>>> > execsubst H=hs,P=Pd; }
>>>>> >
>>>>> > still not working though with just about nothing useful in the logs.
>>>>> Doesn't hang but it still doesn't work. Just empty space and no output.
>>>>> >
>>>>> >
>>>>> > On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz <nstraz@redhat.com>
>>>>> wrote:
>>>>> > On Apr 21 10:29, Brandon Stout wrote:
>>>>> > > hello, I am trying to use conserver to connect to serial ports
>>>>> over ssh and
>>>>> > > it is hanging. When I go direct it works fine (i am using Opengear
>>>>> IMX4248):
>>>>> > >
>>>>> > > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002
>>>>> > ...
>>>>> > > default full { rw *; }
>>>>> > > default opengear { type host; portbase 3000; portinc 1; }
>>>>> > > default * {
>>>>> > > logfile /var/log/conserver;
>>>>> > > timestamp 1hab;
>>>>> > > include full;
>>>>> > > master localhost;
>>>>> > > }
>>>>> > > default console01 { include opengear; host console01; }
>>>>> > > console dr01.arista { include console01; port 1; }
>>>>> > > console dr02.arista { include console01; port 2; }
>>>>> > ...
>>>>> > > Has anyone gotten this to work using ssh?
>>>>> >
>>>>> > I think you need to use the exec host type and setup the right
>>>>> execsubst
>>>>> > to get ssh to use the right port number. The "host" type is just a
>>>>> raw
>>>>> > TCP socket connection.
>>>>> >
>>>>> > Nate
>>>>> > _______________________________________________
>>>>> > users mailing list
>>>>> > users@conserver.com
>>>>> > https://www.conserver.com/mailman/listinfo/users
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> >
>>>>> > brandon
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> >
>>>>> > brandon
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> >
>>>>> > brandon
>>>>> > _______________________________________________
>>>>> > users mailing list
>>>>> > users@conserver.com
>>>>> > https://www.conserver.com/mailman/listinfo/users
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> brandon
>>>>
>>>> _______________________________________________
>>>> users mailing list
>>>> users@conserver.com
>>>> https://www.conserver.com/mailman/listinfo/users
>>>>
>>>>
>>>
>>>
>>> --
>>> Sent from my new iPhone 6 Watch (prototype), see my reviews here!
>>> www.conserver.com/consoles/ -- consoleteam.blogspot.com
>>> - - - - - - - -
>>> www.ncry.org
>>> www.d4tm.org
>>> www.hackerdojo.com
>>>
>>
>>
>>
>> --
>>
>> brandon
>>
>
>
>
> --
> Sent from my new iPhone 6 Watch (prototype), see my reviews here!
> www.conserver.com/consoles/ -- consoleteam.blogspot.com
> - - - - - - - -
> www.ncry.org
> www.d4tm.org
> www.hackerdojo.com
>



--

brandon

There is a lot of good features that come from using the model I
describe, especially if you may need to scale-up the deployment later.

If you can afford the time, try to get through the two LISA presentations
from 2002. (It's free... :-) If they don't entice you, going directly to
the console server may be good enough for your needs.

Best regards,

-Z-



On Mon, Apr 21, 2014 at 3:57 PM, Brandon Stout <bstout@squareup.com> wrote:

> Hey Z,
>
> This is starting to make a lot more sense. Thanks for the email. It sounds
> like I may not be able to use it exactly how I wanted to but I can get by
> with local user/pw on the console server if this is the case. I am using
> the conserver as both conserver host and conserver client, by which a user
> will logon to this host to gain console access only to console servers
> configured locally (nothing distributed). The server is also used for other
> functions so other users have access to the box who I don't want to have
> access to the consoles. I was trying to control access via conserver.passwd
> but it sounds like that is only used for conserver clients outside of the
> conserver. It seems as though I will just need to create individual
> accounts on the console server itself and control access there.
>
> thanks
> Brandon
>
>
> On Mon, Apr 21, 2014 at 3:37 PM, Zonker <consoleteam@gmail.com> wrote:
>
>> Try thinking of authentication in the following model...
>>
>> 1) A secure connection from the Conserver host to the console
>> server(s).
>> (Management net, maybe static routes instead of defaults, SSH if
>> needed)
>> - Conserver opens a conenction for every configured port, and
>> starts logging.
>> 2) User access to the console sessions.
>> - Maybe the SSH to the conserver, or they have a console client
>> on their host
>> - Users "connect" to a given console session... conserver "tees"
>> them in.
>> ( User types, data goes to the console... device sends data back,
>> conserver logs it and forwards the data to the user.)
>>
>> In this model, only Conserver would need to know how to log into the
>> console server. (I make sure my console servers only allow one connection
>> per serial port in the reverse-TCP mode. This way, if anyone else know how
>> to access that port and has the credentials, they would be unable to
>> connect of Conserver got their first.
>>
>> Also in this model, users would authenticate on Conserver... either by
>> SSH to the Conserver host, or with their own conserver client. In the
>> latter case, the client users need to validate with conserver when they
>> make the connection, and this would be checked in the conserver.passwd file.
>>
>> It's been a great model for many types of administration. But, if it's
>> not for you, perhaps you can share what make your scenario
>> different/difficult?
>>
>> Best regards,
>>
>> -Z- http://www.conserver.com/consoles/
>>
>> You may find a couple of my older LISA tutorials useful, and you can
>> find them at
>> http://www.conserver.com/consoles/Training/published.html
>>
>>
>>
>> On Mon, Apr 21, 2014 at 2:13 PM, Brandon Stout <bstout@squareup.com>wrote:
>>
>>> Hey Z,
>>>
>>> This all makes sense, thanks for the info. From an conserver.passwd
>>> perspective, is the location and usage of the file need to be called out in
>>> the conserver.cf file or should it automatically use it for
>>> authentication? Right now I have it working being authenticated by the
>>> Opengear but want to test to see if I can get it working using this file.
>>> Is there something I needed to do to get conserver to use the file?
>>>
>>> thanks
>>> Brandon
>>>
>>>
>>> On Mon, Apr 21, 2014 at 1:35 PM, Zonker <consoleteam@gmail.com> wrote:
>>>
>>>> Chris Ross is correct... The model of conserver connecting (and then
>>>> trying to maintain connection) is built around the model that a sysadmin
>>>> wants to capture any messages that a console may cough up (memory error at
>>>> 0x23484325, root volume at 98%, core dumped, etc.), so that when a system
>>>> fails to respond on the network, and you try to use the console only to
>>>> find it unresponsive... THEN is when we are glad that we can tail the log
>>>> file for that device, and see what was happening! :-)
>>>>
>>>> Once we see the problem, we can then grep the logs for similar
>>>> machines, and see if we see any of the early signs of pending failure on
>>>> similar devices in our collection. :-)
>>>>
>>>>
>>>> Using ssh is a way to encrypt the data between the console server and
>>>> the conserver host. But, as you scale up (think many dozens of console
>>>> servers, and thousands of ports), consider that SSH on each of those
>>>> connections is a lot more overhead. Many shops use a dedicated management
>>>> subnet and use the telnet option instead.
>>>>
>>>> The conserver.passwd is a good option when you want to give someone
>>>> console access, but not give them shell access on your NIS network. By
>>>> giving them an account local to your conserver host, and using the local
>>>> password file, they can access consoles, and no more.
>>>>
>>>> In one case, where I needed to give contractors access to *some*
>>>> consoles, I installed conserver where the contractors had access (rather
>>>> than letting them have access to my primary logs), and had this
>>>> conserver.passwd;
>>>>
>>>> cat /usr/local/etc/conserver.passwd
>>>> # Users can either have a pre-defined account name here,
>>>> # or they can refer to an existing shell account...
>>>> # for Shell accounts, "*passwd*" means to use their shell passwd
>>>> # Or, you can enforce a pre-assigned password, by adding a crypted
>>>> string
>>>> # (this bypasses the shell passwd, forcing them to use the console
>>>> passwd)
>>>> # perl -e 'print crypt("password","Ah")."\n";'
>>>> # The "Ah" picks the first two characters of the password, and is the
>>>> "salt"
>>>> # used for the crypt...
>>>> root:
>>>> temp_FE:ceOfgr9fefOqNw
>>>> # Contractor users must come to their consoles from a CLUSTER_HOST
>>>> v-prtent:*passwd*
>>>> v-boulder:*passwd*
>>>> *any*:*passwd*
>>>>
>>>> Also, "temp_FE" was an account when they needed someone more random to
>>>> come in and work on the devices, and we could change that password at will.
>>>>
>>>> Best regards,
>>>>
>>>> -Z-
>>>>
>>>>
>>>>
>>>> On Mon, Apr 21, 2014 at 12:25 PM, Brandon Stout <bstout@squareup.com>wrote:
>>>>
>>>>> Thanks for the reply Chris. You are correct, it is not using the
>>>>> local/conserver password but just the console server (opengear) password. I
>>>>> actually don't really care which password to use, as long as it asks for a
>>>>> password anytime someone wants to connect to a console port. It works
>>>>> correctly if you just ssh to the console via port 30xx. But when using
>>>>> conserver, it just asks once and that is it. Looking at the logs, it looks
>>>>> like it conserver tries to login to every port preemptively and keep it
>>>>> open as opposed to just opening a session when someone asks for it. Is
>>>>> there a way to change this behavior?
>>>>>
>>>>>
>>>>> On Mon, Apr 21, 2014 at 12:13 PM, Chris Ross <
>>>>> cross+conserver@distal.com> wrote:
>>>>>
>>>>>>
>>>>>> “Your milage may vary”, but for myself, I’m consoling UNIX servers,
>>>>>> so I want their console output to be logged even when noone is connected.
>>>>>> To accomplish this, I have a script that will log into the session for me
>>>>>> upon initialization of the console, and then stay attached. As you’ve
>>>>>> determined, conserver leaves the TCP connection active, so you don’t need
>>>>>> to authenticate against the ssh connection again after the initial
>>>>>> connection.
>>>>>>
>>>>>> I suspect you’re not getting it to use the local/conserver password
>>>>>> at all, or else when you first start up, you’d have to enter both, in the
>>>>>> correct sequence. One to connect to the established ssh command, then
>>>>>> another to ssh to authenticate the network connection.
>>>>>>
>>>>>> So, I guess you need to decide whether you want to have the
>>>>>> connection drop and reestablish, which is what you seemed to be asking for,
>>>>>> or rather want just to get the conserver password prompting working, which
>>>>>> I’m not doing, so can’t help with directly.
>>>>>>
>>>>>> Thoughts and information that I hope is helpful.
>>>>>>
>>>>>> - Chris
>>>>>>
>>>>>> On Apr 21, 2014, at 14:38, Brandon Stout <bstout@squareup.com> wrote:
>>>>>>
>>>>>> > Also, how does the conserver.passwd work? When does it use that
>>>>>> rather than the authentication on the Opengear itself? To test, I have the
>>>>>> same user on the Opengear as well as in the conserver.passwd with different
>>>>>> passwords to see where it gets its passwords from. So far it just looks
>>>>>> like it is using the password from the Opengear. I configured conserver
>>>>>> with all the defaults so I am assuming conserver.passwd just needs to exist
>>>>>> within the same directory as conserver.cf. Did I configure something
>>>>>> incorrectly or does there need to be a line in the conserver.cf file
>>>>>> to point to where conserver.passwd exists?
>>>>>> >
>>>>>> >
>>>>>> > On Mon, Apr 21, 2014 at 11:32 AM, Brandon Stout <
>>>>>> bstout@squareup.com> wrote:
>>>>>> > So I actually figured out the problem so now it connects, I get the
>>>>>> password prompt and when I enter it correctly it works. The problem is that
>>>>>> when I disconnect and reconnect, it no longer asks me for a password and
>>>>>> just puts me through to the console. is there some sort of disconnect I
>>>>>> need to do manually to get it to reset and ask for a password? Seems like
>>>>>> it just stays connected once the pw is entered, regardless of someone
>>>>>> exiting.
>>>>>> >
>>>>>> >
>>>>>> > On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout <
>>>>>> bstout@squareup.com> wrote:
>>>>>> > thanks Nathan, I actually was trying that right after I sent this
>>>>>> email and added this
>>>>>> >
>>>>>> > default opengear-ssh { type exec; portbase 2000; portinc 1;
>>>>>> > exec /usr/bin/ssh -p P -l tsuser H;
>>>>>> > execsubst H=hs,P=Pd; }
>>>>>> >
>>>>>> > still not working though with just about nothing useful in the
>>>>>> logs. Doesn't hang but it still doesn't work. Just empty space and no
>>>>>> output.
>>>>>> >
>>>>>> >
>>>>>> > On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz <nstraz@redhat.com>
>>>>>> wrote:
>>>>>> > On Apr 21 10:29, Brandon Stout wrote:
>>>>>> > > hello, I am trying to use conserver to connect to serial ports
>>>>>> over ssh and
>>>>>> > > it is hanging. When I go direct it works fine (i am using
>>>>>> Opengear IMX4248):
>>>>>> > >
>>>>>> > > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002
>>>>>> > ...
>>>>>> > > default full { rw *; }
>>>>>> > > default opengear { type host; portbase 3000; portinc 1; }
>>>>>> > > default * {
>>>>>> > > logfile /var/log/conserver;
>>>>>> > > timestamp 1hab;
>>>>>> > > include full;
>>>>>> > > master localhost;
>>>>>> > > }
>>>>>> > > default console01 { include opengear; host console01; }
>>>>>> > > console dr01.arista { include console01; port 1; }
>>>>>> > > console dr02.arista { include console01; port 2; }
>>>>>> > ...
>>>>>> > > Has anyone gotten this to work using ssh?
>>>>>> >
>>>>>> > I think you need to use the exec host type and setup the right
>>>>>> execsubst
>>>>>> > to get ssh to use the right port number. The "host" type is just a
>>>>>> raw
>>>>>> > TCP socket connection.
>>>>>> >
>>>>>> > Nate
>>>>>> > _______________________________________________
>>>>>> > users mailing list
>>>>>> > users@conserver.com
>>>>>> > https://www.conserver.com/mailman/listinfo/users
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > --
>>>>>> >
>>>>>> > brandon
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > --
>>>>>> >
>>>>>> > brandon
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > --
>>>>>> >
>>>>>> > brandon
>>>>>> > _______________________________________________
>>>>>> > users mailing list
>>>>>> > users@conserver.com
>>>>>> > https://www.conserver.com/mailman/listinfo/users
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> brandon
>>>>>
>>>>> _______________________________________________
>>>>> users mailing list
>>>>> users@conserver.com
>>>>> https://www.conserver.com/mailman/listinfo/users
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Sent from my new iPhone 6 Watch (prototype), see my reviews here!
>>>> www.conserver.com/consoles/ -- consoleteam.blogspot.com
>>>> - - - - - - - -
>>>> www.ncry.org
>>>> www.d4tm.org
>>>> www.hackerdojo.com
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> brandon
>>>
>>
>>
>>
>> --
>> Sent from my new iPhone 6 Watch (prototype), see my reviews here!
>> www.conserver.com/consoles/ -- consoleteam.blogspot.com
>> - - - - - - - -
>> www.ncry.org
>> www.d4tm.org
>> www.hackerdojo.com
>>
>
>
>
> --
>
> brandon
>



--
Sent from my new iPhone 6 Watch (prototype), see my reviews here!
www.conserver.com/consoles/ -- consoleteam.blogspot.com
- - - - - - - -
www.ncry.org
www.d4tm.org
www.hackerdojo.com