On Wed, Sep 30, 2026 at 11:12:55AM +0100, Stuart Henderson wrote: > On 2026/09/30 09:59, Mikolaj Kucharski wrote: > > Hi. > > > > I'm trying to remove some old IPs from `~/.ssh/known_hosts` file. > > > > $ ssh-keygen -R <ip-addr> > > /home/user123/.ssh/known_hosts:846: invalid line > > # Host <ip-addr> found: line 859 > > # Host <ip-addr> found: line 860 > > # Host <ip-addr> found: line 861 > > /home/user123/.ssh/known_hosts is not a valid known_hosts file. > > Not replacing existing known_hosts file because of errors > > It is expected that lines with unknown algorithm types (here > [email protected]) trigger this in ssh-keygen -R. > It is annoying though.
I see. > (my usage of ssh-keygen -R is usually "ssh-keygen -R user@host" > from <esc> _ to copy in the last word from the ssh command, > "dammit", and edit to remove the username...) I'm using `Host foo` in ~/.ssh/config, so I have on the command line `foo` which doesn't exist in the known_hosts file, so `ssh-keygen -R foo` would not work, hence usage of raw IP address. $ ssh-keygen -R vm2 Host vm2 not found in /home/user124/.ssh/known_hosts However, if you say it's expected to error out with unknown algorithm, then that's fine. > > $ echo $? > > 1 > > > > $ sed -ne '846p' < ~/.ssh/known_hosts | sed -e > > 's/^[^[:blank:]]*/<redacted>/' | tr A-Z . > > <redacted> [email protected] > > .....3.za.1tb..z...0...k.j.1..l.b3.lbn.za.5jb20.....c8emx..yw7u8d.w..v.......iu.crc7.4f.m3xn.eq.n.+.azg.0.a1.y...0smu.8io..f..z.ap45..w...t.v1b.s.wocgy1...6.d..xr9c...1g...a.+.t..8f.3x9h...6..p..03nlg....ve.06y..740c...qlw05k1.440a..0.5jb.3.3./j.8.0./4.htq.r+i....h8z.f.j...w.ly.je.kk..cwe+1w..g.v.4..3l....9mmor.h.q/...lyv6d..+s.o.7l..de+..+2o...i.vo.4.k.w.i.b.9v.1...ey.nhym.7ak.6.jbh.e.+g.3na9.xlz.cy...02k9..a...73.t..gfs7p..3c.h9.7xn.qv.0.c.....n.q../....uq.0l7p.2ypsr7kt.04.kh....../dni...d3qq.bcjj..vj5.9i.3..um1u.m5.hejh.6t3trpwxj.us.sfs..31.ma.ipq.0z61sg.pqg06z.4+.b8.qv..z.po.e.6q3.+..grr.+0...9..y3.e3.4.e.hna.j7a/...t.38g....loj...w.6el.j6fwnle..i0gt28cms...jy....2.y..p+0ob3i9.g.gwrf.x.8.gvcoko3.7...2.n9o.he4rjb/va5...822..696vhrq44.4..3.w.j/1..+..dzyv.7r...pj...tj9..r..kqrr..h.o.i....c4c..6..i0u...6oda.g...oqkx...24..l6....air.0....g..4pd8gwy...u.9.w.w...6./v/.o.a.9..zcyrsd4..24.qg...iw8.h.t.a...g...votd78...0.....w.h1......190.05.e/..n..jkp.jsh.nz.lh.f.v.6.m.5am.41z.qa43z...s.zhn/.h8t.avecu.ih.iwm..f+..wk.zzcpl.mjs./.t.7/.t..wfo.l...hr.g2jqi..4.f.cxrn/gc21.52..fg40..j.dm.l6plec.4u..ux9..ym.0.22r.j.n.c.54ll..wnf..cdh1..l..s.wvab.l....v.5.c+v10/7gc.9..15.o3m..i3...7.zx..61....6h..h..ys2i.p..h.m533..../31.n9....h.41mha350...psv0..7d2...7.7.wlx.9i..2r...h2.x.j.8.0.7.n.....zch.pe1l..o2s2..6eo..tio.7...7wyn.uf/s/3..42b.y.b.l.k9.h.m.z.kn7..7.8eu...c9.f8.qge9i7sehw.kza8rn7m31nc...f..n8.r.9kl.k.3.aidd.kk.94f/gvjj.otw..m4.cwk3..sxy.n+cjo..11v/..+h.3vqd.lxg.v.6j.j.1hxv...y....8yk..1.sq.c8up./.csu.+z.9n....w..a1y..i.nm5x/y.os/..pj...oc6a....drb.3...u.9p..si..3.q.2xn..g.1lif.0..lxh.4m68..quh.p.3b5x....ub.c.k.v...f/mz6..i5yo..7+gea./j.fmk.pd.1g..32+pmdp....qrxgj..qiajferw8a./fuw.+.tru..j.0mb.t4.ffw2.e2x.oi...j..3d..sd7.b/..+7.h..j3.8..74.6.j.tepa.n.j.......l.z4.r.q09x.c.k1.dsnjvvb.gvw.13/.8..qm..s.....j..z..3..e8.pw.+sc1 > > > > Would that be expected behaviour? I understand that > > [email protected] is removed (or renamed) from (in) OpenSSH, > > but not sure does it qualify as a bug. > > > > Unless the line 846 is really malformed? It's typical SSH pubkey line, > > similar to the one in: > > > > /etc/ssh/ssh_host_mldsa44_ed25519_key.pub > > that tr(1) makes it hard to grasp the format of the line and makes > it look like some binary junk, but based on what you say, this chunk is > just a regular b64-encoded string and not malformed > Yes, that is correct, it's a regular b64-encoded string. -- Regards, Mikolaj
