January 2018

S M T W T F S
  123456
78910111213
14151617181920
21222324252627
28293031   

Style Credit

Expand Cut Tags

No cut tags
Thursday, May 19th, 2011 02:45 pm
I mostly work from home. However, due to stupid IP licensing requirements, much of my work has to be done on a machine physically located in my employer's building. This is OK, because I can login to said machine over the Internet using ssh.

But! My work machine (sentinel) is not visible over the public Internet. First I have to ssh into a gateway machine (rydell), and then ssh from rydell into sentinel. I like to open a lot of xterms at once, and so I'd like this process to be as simple as possible: ideally, I'd like to click one button and get an xterm sshed to sentinel and cd'ed to the directory containing the code I'm currently working on.

Oh, there's another wrinkle: rydell doesn't allow passwordless login using the normal ssh public key infrastructure. Instead, you have to use Kerberos. Kerberos is an authentication protocol developed at MIT that utilises zzzzzz...

Sorry, drifted off for a minute there. The key point about Kerberos is that you ask a keyserver for a time-limited session key, which is decrypted locally using your password. This session key is then used to establish encrypted connections to other servers in the same authentication realm. You never have to send your password over the network, and you don't have to distribute your public key to every host you ever want to talk to. So, once I've acquired a session key by typing kinit and then giving it my password, I should be able to log in to any machine on my employer's network (including sentinel) without typing my password again that day. Which is brilliant.

Except sentinel still isn't visible over the public Internet. So I still need to ssh into rydell and then ssh into sentinel from there. Both of these logins are now passwordless, but this is still annoying. Here are some things I've tried to improve the situation:

The simplest thing that could possibly work

pozorvlak@delight:~
0 $ ssh rydell ssh sentinel
Pseudo-terminal will not be allocated because stdin is not a terminal.

Automating the double-login with expect

#!/usr/bin/expect -f
set timeout 30
match_max 100000
spawn ssh rydell
send "\r"
expect "0 "             # prompt
send "ssh sentinel\r"
expect "0 "
send "cde\r"            # cd to work directory
interact
This actually works, right until I open a text editor or other ncurses program, and discover that I can't resize my xterm - or rather, that the resize information is not passed on to my programs.

Using sshuttle

sshuttle is a poor man's VPN written by the author of redo. Using the -H option, it allows you to proxy your DNS requests through the remote server's DNS server. So a simple
sshuttle -H -vvr rydell 0/0
at the beginning of the day allows me to ssh directly from my local machine (delight) to sentinel. But! It asks me for my sodding password every single time I do so. This is not what I wanted.

ssh tunnelling

I am too stupid to make sense of the "tunnelling" section of the ssh manpage, but fortunately some Googling turned up this, which describes exactly the case I want.
pozorvlak@delight:~
0 $ ssh -fN -L 9500:sentinel:22 rydell
pozorvlak@delight:~
0 $ ssh -p 9500 pvlak1@localhost
pvlak1@localhost's password: 
Last login: Thu May 19 14:31:32 2011 from rydell.my.employ.er
pvlak1@sentinel 14:34 ~
0 $ 
Yes, my employer is located in Eritrea, what of it? :-) Anyway, you will note that this suffers from the same problem as the previous attempt: I have to type my password for every login. Plus, if the sshuttle manpage is to be believed, tunnelling ssh over ssh is a bad idea performance-wise.


I notice that I am confused. Specifically, I notice that I have the type of confusion that comes from lacking an appropriate conceptual framework for attacking the problem.

Can anyone help?

Edit: Yes! Marco Fontani pointed out that the -t option to ssh allocates a pseudo-terminal, so ssh -t rydell ssh sentinel Does What I Want. Thanks, Marco! And thanks to everyone else who offered suggestions.

Edit 2: hatfinch and [livejournal.com profile] simont (who you may recognise as the author of the ssh client PuTTY) came up with an alternative solution. My .ssh/config now contains the stanza
Host sentinel
    User pvlak1
    ProxyCommand=ssh rydell nohup nc sentinel 22
    HostName sentinel.my.employ.er
This doesn't require me to type a password for every login, does allow me to resize ncurses apps, and feels slightly snappier than ssh -t rydell ssh sentinel, so that's what I'll be using from now on. Thanks very much!
[identity profile] hamish allan (from livejournal.com)
Thursday, May 19th, 2011 01:56 pm (UTC)
Have you tried, in your ~/.ssh/config:

Host sentinel
User pvlak1
ProxyCommand=ssh rydell nohup nc -w 1 sentinel 22

Thursday, May 19th, 2011 01:59 pm (UTC)
"Write failed: Broken pipe" :-(
Thursday, May 19th, 2011 02:40 pm (UTC)
Do you get a more sensible error message if you ssh into rydell and run the same nc command on the command line?

I was going to suggest a similar approach – ProxyCommand is usually more convenient than running a separate command to set up a port forwarding, unless you're using a client program that doesn't support it or making enough separate connections to the same place for the repeated computational overhead of the SSH setup phase to begin to bite.
Thursday, May 19th, 2011 03:24 pm (UTC)
No error message, but it does terminate after a second. Increasing the timeout in the ProxyCommand setting allows me to connect without error, but I need to type in my password.
Thursday, May 19th, 2011 03:28 pm (UTC)
That sounds like some kind of Kerberos-specific issue, in which ssh is considering your connection to be in some way (that matters to Kerberos) not the same as a 'real' connection direct to sentinel. Hmmm. Does it help to add 'HostName sentinel.the.fully.qualified.domain' to the config section in .ssh/config, in case the problem is that ssh wants to use knowledge about the machine you eventually end up talking to?

(I suppose the other option is that your Kerberos setup is such that your local machine wouldn't be able to do passwordless login to sentinel even if it could reach it directly.)
Thursday, May 19th, 2011 03:36 pm (UTC)
w00t! Yes, that fixes it. Until I leave the terminal idle for ten seconds, whereupon it terminates. I've removed the -w flag, which seems to do the trick.

Thanks very much!
Thursday, May 19th, 2011 03:45 pm (UTC)
Hooray! And also phew, because that was the last suggestion I could think of, and if it hadn't worked I'd have had to declare myself stumped.

Yes, removing -w seems like a good idea to me. Personally I wouldn't have put it there in the first place. On the other hand, if your nc is Debianish rather than upstreamish, you might want to add the extra option "-q0", which causes nc to terminate when its standard input closes (which is the standard means of an SSH connection shutting – they're typically terminated from the client end).
[identity profile] hamish allan (from livejournal.com)
Thursday, May 19th, 2011 04:45 pm (UTC)
Sorry about that. I copied the config (and forgot to remove the -w) for a host I only ever used to tunnel to, whose connectivity was so flaky that I ran the tunnel from a launch agent (so that whenever the connection stalled it would be re-created). Not sure why I had *quite* such a low timeout, though!

Glad you got it all sorted, pozorviak. Thanks for the tip about the Kerberos-specific issue, @simont.
Thursday, May 19th, 2011 02:49 pm (UTC)
You said that rydell didn't allow ssh-keys, but what about sentinel?

Can you open one password-guarded ssh tunnel at the beginning of the day, and then use ssh-keys through the pipe to sentinel for the rest of your work-session?

FWIW, I use a tunnel for my IRC access (local irc client connecting to a persistent bouncer that serves only localhost on my server). I've noticed no performance problems on my desktop, modern laptop, old dell X1 or my HTC Desire[1].

[1] Until it got run over, and stopped performing altogether. But that wasn't SSH's fault.
Thursday, May 19th, 2011 03:27 pm (UTC)
Nope, sentinel definitely doesn't allow ssh-keys. Looking back over my email exchange with support, I see that rydell apparently *does* allow ssh-keys, but this is complicated by the fact that our home directories are held on an AFS share, which handles authorization via kerberos. So I need to be logged in in order to see my .ssh directory, and I need to see my .ssh directory to login with ssh-keys :-) There's apparently a workaround for this (http://www.inf.ed.ac.uk/systems/AFS/sshpubkeys.html), but it results in me being logged in without any access to anything else, so I need to get a kerberos token before I can go any further. Which requires, you've guessed it, typing in my password :-)
(Anonymous)
Thursday, May 19th, 2011 10:17 pm (UTC)
you could just log in once, supplying the -XC switch to your ssh command(s) and open your extra terminal(s) using x-forwarding from the remote host.

so, something like:

pozorvlak@delight:~$ ssh -XC sentinel:22
pozorvlak@sentinel:~$ ssh -XC pvlak1@localhost
pvlak1@sentinel:~$ xterm (repeat as required)

Has the advantage that you can open other stuff easily too.

-mat