Fail to connect after first start about sshportal HOT 11 CLOSED

Happy to help a fellow french open source developer :)
Thanks for taking the time to debug the issue also !

from sshportal.

from sshportal.

@vmarchaud fixed with #26 :)

thank you for your debugging help

from sshportal.

Hi @vmarchaud,

It certainly happens something bad during the initialization; the quick fix is:

• rm sshportal.db; docker rm -f sshportal (cleanup everything)
• start again

Can you help me to debug? I need:

• your sshportal.db file (it's safe if you didn't configure anything with the shell)
• if you can't send me your sshportal.db file, you can give me more info easily with docker rm -f sshportal; docker -d --name=sshportal -v "$(pwd):$(pwd)" -w "$(pwd)" moul/sshportal:latest -v; docker logs sshportal (recreating sshportal in verbose mode on the same sshportal.db file and give me the output logs)

Thank you for your help

from sshportal.

Here is the db : db.zip
I also tried your second point but it failed, i only got in the container log :

sshportal version 1.6.0+dev (c8fb1037621034abc3b4af85c20e8b8bde1fbf69)

And then the container crashed. I got few more logs (docker daemon log) just after i start the container in verbose, don't think thats helpful but in case :

déc. 22 11:13:14 mercury dockerd[9676]: time="2017-12-22T11:13:14.207278688+01:00" level=info msg="No non-localhost DNS nameservers are left in resolv.conf. Using default external servers: [nameserver 8.8.8.8 nameserver 8.8.4.4]"
déc. 22 11:13:14 mercury dockerd[9676]: time="2017-12-22T11:13:14.207343838+01:00" level=info msg="IPv6 enabled; Adding default IPv6 external servers: [nameserver 2001:4860:4860::8888 nameserver 2001:4860:4860::8844]"
déc. 22 11:13:14 mercury dockerd[9676]: time="2017-12-22T11:13:14+01:00" level=info msg="shim docker-containerd-shim started" address="/containerd-shim/moby/44df53e34be297c7571261cc1d46fd02f5306fbbe1aa946eefb4a3fa708486ea/shim.sock" debug
déc. 22 11:13:14 mercury dockerd[9676]: time="2017-12-22T11:13:14.644185733+01:00" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
déc. 22 11:13:14 mercury dockerd[9676]: time="2017-12-22T11:13:14+01:00" level=info msg="shim reaped" id=44df53e34be297c7571261cc1d46fd02f5306fbbe1aa946eefb4a3fa708486ea module="containerd/tasks"

from sshportal.

Thank you,

I started a sshportal using your database, and it worked

$ ssh sshportal  -l invite:iyxu6dQJoVvEpn26
Welcome admin!

Your key is now associated with the user "admin@sshportal"
$ ssh sshportal
    __________ _____           __       __
   / __/ __/ // / _ \___  ____/ /____ _/ /
  _\ \_\ \/ _  / ___/ _ \/ __/ __/ _ '/ /
 /___/___/_//_/_/   \___/_/  \__/\_,_/_/
config>

Can you do an additional test to help me help you :)?

1. docker rm -f sshportal; docker -d --name=sshportal -v "$(pwd):$(pwd)" -w "$(pwd)" moul/sshportal:latest -D; docker logs -f sshportal (same command as in my previous comment but use -D for debug instead of -v for version printing)
2. use the ssh client with verbose output: ssh -vvv localhost -p 2222 -l invite:<token>

And send me the detail if you still have an issue,
thank you for your time

from sshportal.

My pleasure to help you :)

1. https://pastebin.com/AeA39Pz5 : i regenerated a database in case you are wondering why the server private key isnt the same
2. https://pastebin.com/DESjXva1 : i removed few useless verbose log (ssh client telling that it didnt pickup some of my en vars)

I'm guessing that it might come from my ssh client, i will try with some others in the mean time

from sshportal.

The following line shows that sshportal received (and registered) your public ssh key when you connected using the invite token

�[35m(/go/src/github.com/moul/sshportal/main.go:236)�[0m
�[33m[2017-12-22 21:45:05]�[0m  �[36;1m[0.31ms]�[0m  INSERT INTO "user_keys" ("created_at","updated_at","deleted_at","key","authorized_key","user_id","comment") VALUES ('2017-12-22 21:45:05','2017-12-22 21:45:05',NULL,'<binary>','ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDPsB+cBPINCReI5b1LlVe90RrNUgUXledN+2zCNXD/R9/uUADQleRoh4f/zRWK0Nk7GmFxNyUyXGTlACxPn2X5zn1KU1dJtXs2mhJIgoWCLtNnkNwIpisyutFi7HNeVqXVYe/iXTP+TWiQAGxX8ZK4hIFjyY4vHOjML2zivgL3fnHzLrmn8gkXo66aCtexmuX1Xk6ILLj/FAEPOJxZPPr90WhiffDEJD/H0D0VY+pv6rLzZjMUrMy3fK+LcFKVPSdK4jpBpWncIfEmR0FvbMA3paiW5smz0wSivj6gWM1Tx5Vaptx2gx7QYl7+t5phe4qCoRGNGUyJ7aTK0w+9fK23
','1','created by sshportal')  
�[36;31m[1 rows affected or returned ]�[0m

can you try:

• close your shell with ssh client (if not already done)
• start sshportal (if killed)
• connect using the admin user instead of invite:XXXX?

if it works, the problem comes from the invite system that does not return a valid pty, your .ssh/config file probably contains a line I don't have that blocks the client when the PTY request fails

from sshportal.

Same behavior with admin user, the client fail after :

debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: callback done
debug2: channel 0: open confirm rwindow 2097152 rmax 32768
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0

I don't have any ssh client configuration inside my ~/.ssh

However i tried inside a docker container like this (even with a clear db, the connection is refused), is there any thing that i miss to test directly with the ssh client of the container ?

docker run -v /path/to/private/key/:/id_rsa kroniak/ssh-client ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -i /id_rsa 172.18.0.1 -p 2222 -l admin    
Pseudo-terminal will not be allocated because stdin is not a terminal.
Warning: Permanently added '[172.18.0.1]:2222' (RSA) to the list of known hosts.
Permission denied (publickey).

from sshportal.

That's a nice idea to try to run the ssh client from withing docker, here the error is different: Permission denied (publickey).

can you try the invite:xxx user from within docker? (if possible remove your database and start a new sshportal, so we are sure the invite token wasn't used)

Thank you for your patience :)

edit: from your pastebin, I can see that your ssh client loads a global configuration file:

debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *

Can you check that none of these options may be the cause?

from sshportal.

Good catch :)
It was this line : SendEnv LANG LC_* that lead to undefined behavior. The weird things is that i doesn't match any of my env variables :

▶ env | grep LANG   
LANGUAGE=en_US
LANG=en_US.UTF-8
GDM_LANG=en_US

As soon as i remove it, its works correctly so i think you should be able to replicate easily

from sshportal.